Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

From: [email-masked]
Date: Mon, 11 Oct 2010 07:30:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
	Author(s)       : B. Huang, et al.
	Filename        : draft-ietf-behave-v4v6-bih-00.txt
	Pages           : 25
	Date            : 2010-10-11

This document describes the "Bump-In-the-Host" (BIH), a host based
protocol translation mechanism that allows a subset of applications
supporting only one IP address family to communicate with peers that
are reachable or supporting only the other address family.

This specification addresses scenarios where a host is provided dual
stack or IPv6 only network connectivity.  In the dual stack network
case, single address family applications in the host sometime will
communicate directly with other hosts using the different address
family.  In the case of IPv6 only network or IPv6 only destination,
IPv4 originated communications have to be translated into IPv6.  The
BIH makes the IPv4 applications think they talk to IPv4 peers and
hence hides the IPv6 from those applications.

Acknowledgement of previous work

This document is an update to and directly derivative from Kazuaki
TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and
from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and
Erik Nordmark's [RFC3338], which similarly provides a dual stack host
means to communicate with other IPv6 host using existing IPv4
appliations.  This document combines and updates both [RFC2767] and
[RFC3338].

The changes in this document reflect five components

1.  Supporting IPv6 only network connections

2.  IPv4 address pool use private address instead of the

unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255)

3.  Extending ENR and address mapper to operate differently

4.  Adding an alternative way to implement the ENR

5.  Going for standards track instead of experimental/

informational

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: <[email-masked]>
Date: Wed, 13 Oct 2010 12:57:20 +0200

Hi all,

Please provide comments & improvement ideas to the BIH document just uploaded.

I have two particular question in my mind that were also touched at Maastrich meeting: what IPv4 addresses should be used and what if a real IPv4 interface starts during BIH operation?

The discussions I was involved in seemed to point to using RFC1918 addresses, as those are the only ones recognized by legacy apps to be private and NATted. Possible IANA allocated new dedicated addresses would be handled as public addresses and hence might prevent/delay applications to use NAT traversal tools.

If RFC1918 addresses are used, then which part of the address space? An address would be needed for local Ipv4 address(es?), and for the pool of addresses that would be dynamically and internally used to represent IPv6 destinations in the IPv4 domain. 

If the host is strictly single-homed to IPv6-only access the used RFC1918 addresses could probably be any. However, a host may move or otherwise start in the fly a real IPv4 interface using RFC1918 addressing that could conflict with the addresses used by BIH (both host address and addresses received via DNS or other rendezvous tools). One option is to disconnect the BIH interface/connections right at the moment real IPv4 interface starts. Second option is to try to manage both real and ongoing BIH IPv4 communications in parallel (new connections should use the real IPv4). In the latter case the BIH should probably use RFC1918 addresses most unlikely to conflict with the addresses used by possible real IPv4 interfaces. Third option is to leave this problem out of the document and leave it for implementations to tackle.

I am trying to obtain statistics revealing what RFC1918 spaces are least/most utilized in the field, but that information may not be obtained or is received some time next spring (I have two sources that may provide this). If you have such knowledge already please let us know.

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext [email-masked]
> Sent: 11. lokakuuta 2010 17:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
> 
> BIH makes the IPv4 applications think they talk to IPv4 peers and hence
> hides the IPv6 from those applications.
> 
> TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and from
> Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik
> Nordmark's [RFC3338], which similarly provides a dual stack host means
> to communicate with other IPv6 host using existing IPv4 appliations.
> This document combines and updates both [RFC2767] and [RFC3338].
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Oct 2010 17:14:18 -0700

> Behalf Of [email-masked]
> Sent: Wednesday, October 13, 2010 3:57 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
> 
> Hi all,
> 
> I have two particular question in my mind that were also touched at
> Maastrich meeting: what IPv4 addresses should be used and what if a
> real IPv4 interface starts during BIH operation?
> 
> The discussions I was involved in seemed to point to using RFC1918
> addresses, as those are the only ones recognized by legacy apps to be
> private and NATted. Possible IANA allocated new dedicated addresses
> would be handled as public addresses and hence might prevent/delay
> applications to use NAT traversal tools.
> 
> If RFC1918 addresses are used, then which part of the address space? An
> address would be needed for local Ipv4 address(es?),

For what purpose?

> and for the pool
> of addresses that would be dynamically and internally used to represent
> IPv6 destinations in the IPv4 domain.

The complexity with IPv4->IPv6 translation is destroying mappings; there
is no good way to determine when a mapping should be destroyed.  Destroying
a mapping prematurely causes the application to connect to the wrong
destination.  Using a large IPv4 address space is the best way to avoid
the chance of prematurely destroying a mapping.

I just ran tcpdump and visited a bunch of websites -- a bunch sites I 
would normally visit in a day.  It caused me to connect to 172 distinct 
IPv4 servers.  Multiply that by 10x for safety (some people visit far
more sites in a day) is 1720 IP addresses.  Let's round that down to 
1024.  1024 different addresses can be represented in IPv4 using 
a /22.  So, I believe a /22 could safely represent a day's worth of 
Internet access to IPv6 hosts.  This assumes a lot, of course; we
might want a /21 or something even shorter to be safer.  Based on
that analysis, any of the prefixes defined in RFC1918 are short
enough to work.

> If the host is strictly single-homed to IPv6-only access the used
> RFC1918 addresses could probably be any. However, a host may move or
> otherwise start in the fly a real IPv4 interface using RFC1918
> addressing that could conflict with the addresses used by BIH (both
> host address and addresses received via DNS or other rendezvous tools).
> One option is to disconnect the BIH interface/connections right at the
> moment real IPv4 interface starts. Second option is to try to manage
> both real and ongoing BIH IPv4 communications in parallel (new
> connections should use the real IPv4). In the latter case the BIH
> should probably use RFC1918 addresses most unlikely to conflict with
> the addresses used by possible real IPv4 interfaces. Third option is to
> leave this problem out of the document and leave it for implementations
> to tackle.
> 
> I am trying to obtain statistics revealing what RFC1918 spaces are
> least/most utilized in the field, but that information may not be
> obtained or is received some time next spring (I have two sources that
> may provide this). If you have such knowledge already please let us
> know.

I don't.  But I bet a beer that 172.16.0.0/12 is the least used because 
it  isn't as big as 10/8, and 192.168.0.0/16 is ubiquitous with
residential NATs.

Have you considered, and discarded, using 127.0.0.0/8?

-d

> from
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Oct 2010 00:17:30 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]

My personal opinions below.

> 
> I have two particular question in my mind that were also touched at Maastrich
> meeting: what IPv4 addresses should be used and what if a real IPv4 interface
> starts during BIH operation?
> 
> The discussions I was involved in seemed to point to using RFC1918 addresses,
> as those are the only ones recognized by legacy apps to be private and NATted.
> Possible IANA allocated new dedicated addresses would be handled as public
> addresses and hence might prevent/delay applications to use NAT traversal
> tools.
> 
> address would be needed for local Ipv4 address(es?), and for the pool of
> addresses that would be dynamically and internally used to represent IPv6
> destinations in the IPv4 domain.
> 
> If the host is strictly single-homed to IPv6-only access the used RFC1918
> addresses could probably be any. 

Right, anything in RFC 1918.

> However, a host may move or otherwise start
> in the fly a real IPv4 interface using RFC1918 addressing that could conflict with
> the addresses used by BIH (both host address and addresses received via DNS or
> other rendezvous tools). One option is to disconnect the BIH
> interface/connections right at the moment real IPv4 interface starts. Second
> option is to try to manage both real and ongoing BIH IPv4 communications in
> parallel (new connections should use the real IPv4). In the latter case the BIH
> should probably use RFC1918 addresses most unlikely to conflict with the
> addresses used by possible real IPv4 interfaces. Third option is to leave this
> problem out of the document and leave it for implementations to tackle.

I'd be okay with either the first option (disconnect) or the third option (up to 
implementation).

Trying to manage both seems like a near impossible task, akin to being multihomed
to two RFC 1918 networks (unrelated to translation), which seems best to not
try to tackle given the impossibility of having any good answer for a general case.
It's possible to be ok in very constrained circumstances (e.g., a handset that's
only capable of working in a single ISP and hence can guarantee no conflict), and
so at the moment my preference would be leave it up to the implementation,
after explaining the issue. 

> 
> I am trying to obtain statistics revealing what RFC1918 spaces are least/most
> utilized in the field, but that information may not be obtained or is received
> some time next spring (I have two sources that may provide this). If you have
> such knowledge already please let us know.

Net 10 is widely used in enterprises.
192.168.x is widely used in home gateways, for various values of x.
A good partial survey is at http://www.wifi-forum.com/wf/showthread.php?t=42607
I know 172 is used, but not sure it's very common.

-Dave

> > from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Oct 2010 17:32:51 -0700

> Please provide comments & improvement ideas to the BIH document just

In Section 2.3,
http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-00#section-2.3
there is a figure that shows three situations:

        Application | Network  | ENR behaviour
        query       | response |
        ------------+----------+---------------------
           A        |   A      |  <return A record>
           A        |   AAAA   |  <synthesize A record>
           A        |  A/AAAA  |  <return A record>

                   Figure 3: ENR behaviour illustration

however, the text in Section 2.3 only describes the middle situation (only
an AAAA record) and the last situation (both A and AAAA).  What happens in
the first situation (only an A record)?

-d

---

From: <[email-masked]>
Date: Thu, 14 Oct 2010 09:08:15 +0200

Hi,

> > address would be needed for local Ipv4 address(es?),

In the Bump-in-the-Stack model host would have a virtual interface that needs to show some address on it.

In both BIH and BIA models applications can call getsockname() that must return the locally bound address. Probably applications use this to determine if their connection is using private addressing.

Probably single IPv4 address is enough, but it might be safer to allow few (e.g. if host has multiple IPv6 addresses simultaneously in use for which BIH maps connections).

The local address should also be from different subnet as the synthetic destinations addresses.. 

> the chance of prematurely destroying a mapping.

Agree.

> that analysis, any of the prefixes defined in RFC1918 are short

Thank you. That sounds reasonable, even though all browsers seem to be IPv6-capable and would not be BIH-users. Probably the legacy IPv4-only apps would not contact that many destinations (but assumptions are mothers of all f**kups, I know:)

> it  isn't as big as 10/8, and 192.168.0.0/16 is ubiquitous with

So maybe something like: 172.21.80.0/20 could do as first serious proposal (adding bit pattern 01010101)?

Binary: 10101100 00010101 01010000 00000000
Hex:	  AC       15	  50       00

Allows 4096 destinations.

The source address could then be from... 172.21.112.0/30?

> Have you considered, and discarded, using 127.0.0.0/8?

If we think it is safest to play within RFC1918 scope to ensure application compatibility, wouldn't loopback usage be kind of dangerous? I have to admit I don't know if applications make checks against such destination addresses or not. 

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 14 Oct 2010 09:31:21 +0200

Hi,

> the

I realized the application would have to forget the destination's IPv4 address at the moment of disconnect. Only if the application at the moment of connection re-establishment repeats the name query can ENR return a new non-conflicting IPv4 address.. Maybe some corners just have to be left in the dark.

This also makes me think if for the fallback case the BIH should be documented to have at least two separate IPv4 subnets from 172.16/12 domain.. or the fallback actually from net-10 space.

> Trying to manage both seems like a near impossible task, akin to being
> multihomed to two RFC 1918 networks (unrelated to translation), 

Fully agree! One big host benefit of moving to IPv6 indeed is simplification of multihoming situations..

> which seems best
> to not

I will to draft something on this.

> I know 172 is used, but not sure it's very common.

Thanks, see my reply to Dan as well.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 14 Oct 2010 09:52:21 +0200

Right, how about adding something like:
--
If only an A record is available it will be passed unmodified to the application so that the application learns a record exists for the destination. However, the application will not be able to use the address for communications if the host is in an IPv6-only access network. If the application tries to send data to such an IPv4 address destination unreachable/host unreachable error will be returned.
--

E.g. then the application could given "no route to server" error to the user instead of "no server".

Best regards,

Teemu

> From: ext Dan Wing [mailto:[email-masked]]
> Sent: 14. lokakuuta 2010 03:33
> To: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]
> Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Oct 2010 14:40:50 +0000

> Of [email-masked]
[...]

Agree.

[...]

> If we think it is safest to play within RFC1918 scope to ensure application
> compatibility, wouldn't loopback usage be kind of dangerous? I have to admit I
> don't know if applications make checks against such destination addresses or
> not.

I can confirm 127/8 is not usable for this purpose.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Oct 2010 07:52:17 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 14, 2010 12:08 AM
> To: [email-masked]; [email-masked]
> > > If RFC1918 addresses are used, then which part of the address
> space?
> > An

Ok.  How about using 169.*?

> In both BIH and BIA models applications can call getsockname() that
> must return the locally bound address. Probably applications use this
> to determine if their connection is using private addressing.
> 
> Probably single IPv4 address is enough, but it might be safer to allow
> few (e.g. if host has multiple IPv6 addresses simultaneously in use for
> which BIH maps connections).

My head just exploded at that thought.

> Thank you. That sounds reasonable, even though all browsers seem to be
> IPv6-capable and would not be BIH-users. Probably the legacy IPv4-only
> apps would not contact that many destinations (but assumptions are
> mothers of all f**kups, I know:)

Plan for success.

> If we think it is safest to play within RFC1918 scope to ensure
> application compatibility, wouldn't loopback usage be kind of
> dangerous? I have to admit I don't know if applications make checks
> against such destination addresses or not.

I don't know if applications check 127/8.  I doubt it.  

There must be a secret list of these legacy IPv4 applications.  Test 
a few?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Oct 2010 07:56:21 -0700

> Sent: Thursday, October 14, 2010 12:52 AM
> If only an A record is available it will be passed unmodified to the
> application so that the application learns a record exists for the
> destination. However, the application will not be able to use the
> address for communications if the host is in an IPv6-only access
> network. If the application tries to send data to such an IPv4 address
> destination unreachable/host unreachable error will be returned.
> --
> 

Sounds good.  Thanks.

-d

> > > Please provide comments & improvement ideas to the BIH document
> just
> > > uploaded.
> >
> > In Section 2.3,
> > an AAAA record) and the last situation (both A and AAAA).  What
> happens
> > in

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Oct 2010 14:57:36 +0000

> Of Dan Wing
> Sent: Thursday, October 14, 2010 7:52 AM
> To: [email-masked]; [email-masked]

The local addresses and remote addresses should be on different
subnets.  169.254.* is all one subnet and currently means it's local-only, 
not NAT'ed.  So I don't think that's appropriate either.

[...]
> I don't know if applications check 127/8.  I doubt it.

You can't use 127/8.

-Dave

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Oct 2010 11:44:18 -0700

Folks,

A document on IPv6 transition [1] I was reading proposes to combine BIH with NAT64 to support IPv4 applications on an IPv6 only host connecting to an IPv4 server as follows: "The BIH in the host translates the IPv4 application's packets into IPv6 and the NAT64 translates IPv6 packets into IPv4 and vice versa." 

This is an example of double NAT46 and NAT64 translation that I thought we were not recommending neither working on -- the BIH work item is supposed to fulfill the following scenario:

  * An IPv4 application running on an IPv6-only connected host to the
  IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for
  packets in uni- or bi-directional flows that are initiated from an
  IPv4 host towards an IPv6 host.  The translator function is embedded
  in the IPv4 host. 

Thus, wondering if we shouldn't add to the draft an applicability statement recommending against the use of BIH technologies together with NAT64 to support scenarios where an IPv4 application on an IPv6-only connected host talks to an IPv4 server, since I thought the recommended IETF approach to support such scenarios is encapsulation, as opposed to double translation. 

--julien   

[1] http://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_81_Prague/Docs/S2-105121.zip

> Behalf Of [email-masked]
> Sent: Monday, October 11, 2010 7:30 AM

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 15 Oct 2010 16:17:58 -0400

I had passed Teemu an abandoned draft about a translator I worked on 
about 5 years ago.  It was similar to the BIH, although in an external 
box rather than on host, the draft called this Bump-in-the-Wire (BIW).  
We felt that IPv4 pass-through was an essential feature to avoid such 
double translation.  We assumed native routing of the IPv4 packets 
through a dual-stack network, but encapsulation would be needed if the 
host has only an IPv6 address.

Should BIH include an IPv4 pass-through?

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 22:37:19 +0200

Julien,

The draft contains already statements such as:
--
   This includes essentially all DNS using legacy
   client-server model applications, which are agnostic on IP address
   family used by the destination, but not other classes of
   applications.
--
and
--
5. Considerations due ALG requirements

   No ALG functionality is specified herein as ALG design is generally
   not encouraged for host based translation and as BIH is intended for
   applications not including IP addresses in protocol payloads.
--
and
--
   In order to support communication between IPv4 applications and the
   target IPv6 hosts, pooled IPv4 addresses will be assigned through the
   extension name resolver.

   The BIH can be used whenever an IPv4-only application needs to
   communicate with an IPv6 peer, independently of the address families
   supported by the access network.  Hence the access network can be
   IPv6-only or dual-stack capable.
--
and
--
          Mapping table | Access    | Peer   | Created
          entry for     |link type  | support| address mapping
       -------------------+-------------+-------------------------------
       (1) real IPv4    |IPv4 or DS | v4     | < no mapping needed >
       (2) real IPv6    |IPv6 or DS | v6     | < no mapping needed >
       (3) real IPv4    |IPv6       | v4 & v6| real IPv4 -> real IPv6
       (4) real IPv6    |IPv4       | v4 & v6| < out of scope >
       (5) local IPv4   |IPv6 or DS | v6     | local IPv4 -> real IPv6
       (6) local IPv6   |IPv4 or DS | v4     | < out of scope >
       (7) real IPv4    |IPv6       | v4     | < out of scope >
       (8) real IPv6    |IPv4       | v6     | < out of scope >
--
and
--
   (7) The scenario where the resolver gets only an 'A' record for the
   target host name for application's 'A' request on IPv6 only access
   network is out of scope.
--

Your concern seems to be for case 7, right? That case is out of scope, and I think it is written many times already on the draft.

Best regards,

Teemu

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of ext Laganier, Julien [[email-masked]]
Sent: Friday, October 15, 2010 9:44 PM
To: [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Folks,

--julien

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 22:47:13 +0200

Hi,

The goal of BIH is that an IPv4-only application that does not require ALG can be made to talk to a server reachable only over IPv6.

Hence the BIH would be used in IPv6-only access or in dual-stack access if the server is not reachable via IPv4.

If the application is IPv4-only, host is on dual-stack or IPv4-only access, and server is dual-stack or IPv4-only reachable, then BIH is not used. This is case 1 of the following table:

I'll look if this could be clarified for -01.

Best regards,

Teemu
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of ext Ed Jankiewicz [[email-masked]]
Sent: Friday, October 15, 2010 11:17 PM
To: [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

---

From: Dave Thaler <[email-masked]>
Date: Fri, 15 Oct 2010 21:12:37 +0000

> Of Laganier, Julien
> Sent: Friday, October 15, 2010 11:44 AM
> To: [email-masked]
> A document on IPv6 transition [1] I was reading proposes to combine BIH with
> NAT64 to support IPv4 applications on an IPv6 only host connecting to an IPv4
> server as follows: "The BIH in the host translates the IPv4 application's packets
> into IPv6 and the NAT64 translates IPv6 packets into IPv4 and vice versa."
> 
> This is an example of double NAT46 and NAT64 translation that I thought we
> were not recommending neither working on -- the BIH work item is supposed to
> fulfill the following scenario:
> 
> Thus, wondering if we shouldn't add to the draft an applicability statement
> recommending against the use of BIH technologies together with NAT64 to
> support scenarios where an IPv4 application on an IPv6-only connected host
> talks to an IPv4 server, since I thought the recommended IETF approach to
> support such scenarios is encapsulation, as opposed to double translation.
> 
> --julien
> 

I agree there ought to be text in the draft saying that a BIH host is a 
dual-stack host.   Of course that doesn't mean that host can 
guarantee it will have an IPv4 address configured from the network,
just like a non-BIH dual-stack host can't guarantee that either.

-Dave

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 15 Oct 2010 14:17:06 -0700

Teemu,

> The draft contains already statements such as:

[...] cutting through most of the statements [...]

> Your concern seems to be for case 7, right? That case is out of scope,
> and I think it is written many times already on the draft.

I am a bit confused by this table...  My concern is:

    1- a v4-only application on an host attached to an IPv6-only network 
       wants to communicate with a v4-only server v4.example.com behinds
       a NAT64. The application request name to address resolution for
       v4.example.com.

    2- BIH-ENR  queries for A and AAAA record to the DNS, which turns out
       to be a DNS64.

    3- There are no AAAA RR for v4.example.com, thus DNS64 synthesizes a
       AAAA record based on the A RR. DNS64 returns both the A and 
       synthesized AAAA RR to BIH-ENR.

    4- BIH-ENR receives both A and synthesized AAAA, and request mapping
       from A to synthesized AAAA, and returns A to application.

    5- application connect to A, which is translated into a TCP connection
       over IPv6 towards the synthesized AAAA. That TCP connection over
       IPv6 is translated back to IPv4, towards the A at the NAT64. I.e. we
       have double translation.

That seems to be case #3 of your table when NAT64 and DNS64 are deployed in 
the v6-only access. It implies double translation, which I think we should 
recommend against, because encapsulation is the technically correct approach 
in that case. That would need to be in an applicability statement at the 
beginning of the draft, e.g., 

                     "BIH SHOULD NOT be used with NAT64."

[ as to the "out-of-scope" wording, it isn't sufficient IMHO. Not telling 
  someone how to do something isn't quite the same as telling that person 
  to not do something.                                                    ]

--julien

---

From: Dave Thaler <[email-masked]>
Date: Fri, 15 Oct 2010 21:19:05 +0000

> Sent: Friday, October 15, 2010 1:47 PM

> To: [email-masked]; [email-masked]

> The goal of BIH is that an IPv4-only application that does not require ALG can be

> made to talk to a server reachable only over IPv6.

> Hence the BIH would be used in IPv6-only access or in dual-stack access if the

> server is not reachable via IPv4.

And the draft says in section 2.3:

        query       | response |

The last row means the BIH component is never used (no synthesis) when an

A record is returned in DNS.

-Dave

> If the application is IPv4-only, host is on dual-stack or IPv4-only access, and

> server is dual-stack or IPv4-only reachable, then BIH is not used. This is case 1 of

> the following table:

> From: [email-masked] [[email-masked]] On Behalf Of ext

> Ed Jankiewicz [[email-masked]]

>   I had passed Teemu an abandoned draft about a translator I worked on about 5

> years ago.  It was similar to the BIH, although in an external box rather than on

> host, the draft called this Bump-in-the-Wire (BIW).

> We felt that IPv4 pass-through was an essential feature to avoid such double

> translation.  We assumed native routing of the IPv4 packets through a dual-stack

> network, but encapsulation would be needed if the host has only an IPv6

> address.

> > [1]

> > http://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_81_Prague/Docs/S2-105121.zip

> >> A New Internet-Draft is available from the on-line Internet-Drafts

> >> directories.

> >> This draft is a work item of the Behavior Engineering for Hindrance

> >> Avoidance Working Group of the IETF.

> >> means to communicate with other IPv6 host using existing IPv4 appliations.

> > [email-masked]<mailto:[email-masked]>

> Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards

> Engineering Branch

> 732-389-1003 or  [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 23:28:09 +0200

Dave,

I don't fully agree on "BIH is never used".

The third row describes Extension Name Resolver behavior regarding what address is given to application. The document further clarifies:
--
   If both A and AAAA record are available in the IPv6 only network, ENR
   does not require address mapper to assign IPv4 address, but instead
   asks address mapper to store relationship between the A and AAAA
   records, and then directly passes the received A record to the IPv4
   application.
--

I.e. if the host has an IPv4 address configured from the network, then "IPv4 pass-through" takes place, but if the host has only an IPv6 address configured, then according to current text BIH will do translation between IPv4 and IPv6. I.e. application thinks it sends to global IPv4 address of the destination (as ENR passed A record unmodified), but BIH anyways translates that to the global IPv6 address of the destination.

Best regards,

Teemu 
________________________________________
From: ext Dave Thaler [[email-masked]]
Sent: Saturday, October 16, 2010 12:19 AM
To: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]; [email-masked]
Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

        query       | response |

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 15 Oct 2010 21:30:04 +0000

> Sent: Friday, October 15, 2010 2:28 PM
> To: Dave Thaler; [email-masked]; [email-masked]

Yes, I meant BIH-ENR is never used, sorry.

> 
> The third row describes Extension Name Resolver behavior regarding what
> address is given to application. The document further clarifies:
> --
> I.e. if the host has an IPv4 address configured from the network, then "IPv4
> pass-through" takes place, but if the host has only an IPv6 address configured,
> then according to current text BIH will do translation between IPv4 and IPv6. I.e.
> application thinks it sends to global IPv4 address of the destination (as ENR
> passed A record unmodified), but BIH anyways translates that to the global IPv6
> address of the destination.

Yes, I understand and agree.   Hopefully that was clearer from my other email.

-Dave

---

From: Jan Melen <[email-masked]>
Date: Sat, 16 Oct 2010 09:21:32 +0300

Hi Teemu,

I think that the introduction needs to elaborate a bit of scoping (to be more strict) where the BIH is applicable. Currently the introduction IMHO doesn't discuss enough of the applicability and thus you should add there something in the lines that BIH should not be used when both peers are dual-stacked or both peers are supporting the same address family even if there is network segments that have different address families in between. BIH is only applicable for scenarios where IPv4-only application contacts a IPv6-only server with end-to-end IPv6-connectivity. 

Additionally you might consider adding some pointers for the reader to look in to tunneling solutions when it comes to delivering IPvX over IPvY networks to IPvX host.

  Regards,
      Jan

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 08:47:37 +0200

Hi Jan, all,

What I'm bit hesitant is to add lots of system architecture considerations into this document. I would like to keep BIH document small and to describe just a component behavior and what it can and cannot do (e.g. ALG issues). Then architecture descriptions, be it node design, 3GPP, WiMAX, BBF, whatever, use or don't use components to build systems. 

After all, there are no disclaimers in DS-Lite, 6a44, 6RD, 6to4, Teredo etc that they are not applicable in those networks that do not allow tunneling because of difficulties tunneling causes for policy and charging control systems..

But of course we work based on WG consensus:) Hence I try to clarify this a bit as it seems to be WG desire.

One question for you, though: if both ends are dual-stack, access network (or some segment) is IPv6-only and tunneling services are not provided for hosts: do you think BIH should be used to provide some connectivity, or rather have no connectivity at all? For me it sounds difficult to mandate deployment of IPv4-over-IPv6 tunneling endpoint capability to all servers, and there are access networks that refuse to provide tunneling due PCC issues.

Best regards,

Teemu

________________________________________
From: ext Jan Melen [[email-masked]]
Sent: Saturday, October 16, 2010 9:21 AM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hi Teemu,

  Regards,
      Jan

---

From: Jan Melen <[email-masked]>
Date: Sat, 16 Oct 2010 14:11:10 +0300

Hi Teemu,

> But of course we work based on WG consensus:) Hence I try to clarify this a bit as it seems to be WG desire.

Ok . Just as a clarification I wouldn't expect this document to be defining anything on behalf of other SDOs but I would expect that when IETF itself is working on transition guidelines (draft-arkko-ipv6-transition-guidelines) the default assumption should be that all the work done by IETF should follow those guidelines. If that is not the case why would IETF in the first place produce a document recommending that transition should be done using approaches a, b, and c and at the same time different WGs would be producing documents proposing methods d, e, f, ...

> One question for you, though: if both ends are dual-stack, access network (or some segment) is IPv6-only and tunneling services are not provided for hosts: do you think BIH should be used to provid…

First of all, connectivity providers of course have interest to provide as good connectivity as possible both on v4 and on v6 and thus they have asked for guidelines how to do the transition smoothly and IETF as well as other SDOs are working on that quite heavily as we can see even from this discussion. Secondly, if after all this providers decide not follow the guidelines given then most likely there will be some consequences from that decision. What I would not expect is that there would exist a patch method that tries to patch things when someone has knowingly chosen to do things differently than what is recommended. If we will go on the path of patching things then I don't see the end of patching different approaches as there will always be new approaches which will need yet another set of patch methods. Feel free to disagree if you think that there should not be a limit on number of solutions defined and we should continue inventing new ones?

  Regards,
     Jan

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 13:51:48 +0200

Hi,

I see the transition guidelines document already says:"Another example regarding the preference to employ tunneling instead of double translation will be discussed later in this document."

Maybe the transition guidelines document should then take the stand on double translation instead? After all, BIH is not double translation nor full transition scenario. BIH is a way to make IPv4-only application to talk to server reachable only via IPv6. A point solution. The document already states:
--
   This includes essentially all DNS using legacy
   client-server model applications, which are agnostic on IP address
   family used by the destination, but not other classes of
   applications.
--

BIH is nothing new really, either, but rather an update to bump-in-the-stack and bump-in-the API RFCs (fixing broken details and merging documents). 

By the way, if you increase granularity and replace "hosts" with "application" on this (from the guidelines document):
--
   o  There is a requirement that hosts in the IPv4-only domain access
      servers or peers in the IPv6-only domain and vice versa.
--
You will end up with requirement for BIH. The IPv4-only domain just happens to exist only within a host. 

Maybe draft-behave-v4v6-bih should be added to the reference list of section 4.4 of draft-arkko-ipv6-transition-guidelines amongside NAT64?

Aren't all these transition discussions we are having in IETF just patches after industry failed to deploy the dual-stack early enough? And there doesn't seem to be an end to these patches (I'm about to study what the 6a44 is about..).

The best way to end the flow of new transition tools is to actually deploy IPv6 in wide-scale and get the ball rolling... and I'm glad to see it is actually happening:-)

Best regards,

Teemu
________________________________________
From: ext Jan Melen [[email-masked]]
Sent: Saturday, October 16, 2010 2:11 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hi Teemu,

  Regards,
     Jan

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Oct 2010 15:18:27 +0000

> Sent: Friday, October 15, 2010 11:48 PM
> To: [email-masked]
> What I'm bit hesitant is to add lots of system architecture considerations into
> this document. I would like to keep BIH document small and to describe just a
> component behavior and what it can and cannot do (e.g. ALG issues). Then
> architecture descriptions, be it node design, 3GPP, WiMAX, BBF, whatever, use
> or don't use components to build systems.
> 
> After all, there are no disclaimers in DS-Lite, 6a44, 6RD, 6to4, Teredo etc that
> they are not applicable in those networks that do not allow tunneling because of
> difficulties tunneling causes for policy and charging control systems..
> 
> One question for you, though: if both ends are dual-stack, access network (or
> some segment) is IPv6-only and tunneling services are not provided for hosts: do
> you think BIH should be used to provide some connectivity, or rather have no
> connectivity at all? For me it sounds difficult to mandate deployment of IPv4-
> over-IPv6 tunneling endpoint capability to all servers, and there are access
> networks that refuse to provide tunneling due PCC issues.

Our current charter page states this:

>  in the IPv4 host

And

> Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only 
> applications to access IPv6-only servers (std)

Note that it states "IPv6-only servers" and "to the IPv6 Internet".

If the destination is IPv4 capable (A record returned by DNS), then that's
out of scope of this milestone and charter item.   Hence the WG draft 
should not attempt to solve this case, as the IETF will not do a standards
track solution for this per our current charter.  Any such discussion
should be in a separate non-WG draft.

-Dave

> I think that the introduction needs to elaborate a bit of scoping (to be more
> strict) where the BIH is applicable. Currently the introduction IMHO doesn't
> discuss enough of the applicability and thus you should add there something in
> the lines that BIH should not be used when both peers are dual-stacked or both
> peers are supporting the same address family even if there is network segments
> that have different address families in between. BIH is only applicable for
> scenarios where IPv4-only application contacts a IPv6-only server with end-to-
> end IPv6-connectivity.
> 
> Additionally you might consider adding some pointers for the reader to look in
> to tunneling solutions when it comes to delivering IPvX over IPvY networks to
> IPvX host.
> 
>   Regards,
>       Jan
> 
> > The goal of BIH is that an IPv4-only application that does not require ALG can
> be made to talk to a server reachable only over IPv6.
> >
> > From: [email-masked] [[email-masked]] On Behalf Of
> > ext Ed Jankiewicz [[email-masked]]
> >> A document on IPv6 transition [1] I was reading proposes to combine BIH
> with NAT64 to support IPv4 applications on an IPv6 only host connecting to an
> IPv4 server as follows: "The BIH in the host translates the IPv4 application's
> packets into IPv6 and the NAT64 translates IPv6 packets into IPv4 and vice
> versa."
> >>
> >>> Erik Nordmark's [RFC3338], which similarly provides a dual stack
> >>> host means to communicate with other IPv6 host using existing IPv4
> appliations.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 16 Oct 2010 09:14:03 -0700

> should be in a separate non-WG draft.

I agree with others that say the draft should explicitly address this
case in question.

To the BIH host, real IPv4-only servers appear to be IPv6-only via the NAT64.

Cameron

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 19:20:49 +0200

So are you essentially saying the BIH module should spend explicit effort to determine it is running in the desired scenario?

1) Test whether A record exist in addition to AAAA and if yes give an error to app. IPv4-only app would be allowed to talk only to server that has only AAAA record. Communication to dual-stack enabled servers would be not allowed - even if host has only IPv6 connectivity...

2) Test whether the received AAAA record is actually synthesized and if yes, give an error to app. (Synthesized AAAA means there is A record in existence, even if for any reason was not received by BIH).

But why? Wouldn't the communications fail anyway if the app is not of the supported class (e.g. an app that requires ALG)?

Shouldn't the BIH component just make the best effort attempt of IPv4->IPv6 translation, send the packet out, and then see if the network can actually deliver? 

Best regards,

Teemu

________________________________________
From: ext Cameron Byrne [[email-masked]]
Sent: Saturday, October 16, 2010 7:14 PM
To: Dave Thaler
Cc: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 16 Oct 2010 11:01:33 -0700

> Shouldn't the BIH component just make the best effort attempt of IPv4->IPv6 translation, send the packet out, and then see if the network can actually deliver?

I do not support NAT464 as a standard.

And from what i think you are saying, BIH is a tool for NAT464.

My interpretation of the charter is that NAT464 is not in scope.

The use case for what i believe the chart to say is an IPv4-only web
browser connecting over an IPv6-only network to reach an IPv6-only web
server.

I think Jan is asking that the charter directly constrains the
applicability of BIH. and the draft should reflect that.

Cameron

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Oct 2010 18:07:10 +0000

> From: Cameron Byrne [mailto:[email-masked]]
> Sent: Saturday, October 16, 2010 9:14 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]
> >> What I'm bit hesitant is to add lots of system architecture
> >> considerations into this document. I would like to keep BIH document
> >> small and to describe just a component behavior and what it can and
> >> cannot do (e.g. ALG issues). Then architecture descriptions, be it
> >> node design, 3GPP, WiMAX, BBF, whatever, use or don't use components to
> build systems.
> >>
> >> After all, there are no disclaimers in DS-Lite, 6a44, 6RD, 6to4,
> >> Teredo etc that they are not applicable in those networks that do not
> >> allow tunneling because of difficulties tunneling causes for policy and
> charging control systems..
> >>
> >> One question for you, though: if both ends are dual-stack, access
> >> network (or some segment) is IPv6-only and tunneling services are not
> >> provided for hosts: do you think BIH should be used to provide some
> >> connectivity, or rather have no connectivity at all? For me it sounds
> >> difficult to mandate deployment of IPv4-
> >> over-IPv6 tunneling endpoint capability to all servers, and there are
> >> access networks that refuse to provide tunneling due PCC issues.
> >
> > If the destination is IPv4 capable (A record returned by DNS), then
> > that's out of scope of this milestone and charter item.   Hence the WG
> > draft should not attempt to solve this case, as the IETF will not do a
> > standards track solution for this per our current charter.  Any such
> > discussion should be in a separate non-WG draft.
> 
> I agree with others that say the draft should explicitly address this case in
> question.
> 

No, they appear to be dual-stack servers because the DNS64 still returns the
A record.  See draft-ietf-behave-dns64 section 5.3.3.

-Dave

> >> strict) where the BIH is applicable. Currently the introduction IMHO
> >> doesn't discuss enough of the applicability and thus you should add
> >> there something in the lines that BIH should not be used when both
> >> peers are dual-stacked or both peers are supporting the same address
> >> family even if there is network segments that have different address
> >> families in between. BIH is only applicable for scenarios where
> >> IPv4-only application contacts a IPv6-only server with end-to- end IPv6-
> connectivity.
> >>
> >> Additionally you might consider adding some pointers for the reader
> >> to look in to tunneling solutions when it comes to delivering IPvX
> >> over IPvY networks to IPvX host.
> >>
> >>   Regards,
> >>       Jan
> >>
> >> server is dual-stack or IPv4-only reachable, then BIH is not used.
> >> This is case 1 of the following table:
> >> > --
> >> > From: [email-masked] [[email-masked]] On Behalf
> >> > Of ext Ed Jankiewicz [[email-masked]]
> >> >  I had passed Teemu an abandoned draft about a translator I worked
> >> > on about 5 years ago.  It was similar to the BIH, although in an
> >> > external box rather than on host, the draft called this Bump-in-the-Wire
> (BIW).
> >> > We felt that IPv4 pass-through was an essential feature to avoid
> >> > such double translation.  We assumed native routing of the IPv4
> >> > packets through a dual-stack network, but encapsulation would be
> >> > needed if the host has only an IPv6 address.
> >> >
> >> IPv4 server as follows: "The BIH in the host translates the IPv4
> >> application's packets into IPv6 and the NAT64 translates IPv6 packets
> >> into IPv4 and vice versa."
> >> >>
> >> were not recommending neither working on -- the BIH work item is
> >> supposed to fulfill the following scenario:
> >> >>
> >> recommending against the use of BIH technologies together with NAT64
> >> to support scenarios where an IPv4 application on an IPv6-only
> >> connected host talks to an IPv4 server, since I thought the
> >> recommended IETF approach to support such scenarios is encapsulation, as
> opposed to double translation.
> >> >>
> >> >> --julien
> >> >>
> >> >> [1]
> >> >> http://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_81_Prague/Docs/S2-
> 105121
> >> >> .zi
> >> >> p
> >> >>
> >> >>> This draft is a work item of the Behavior Engineering for
> >> >>> Hindrance Avoidance Working Group of the IETF.
> >> >>>
> >> >>>
> >> >>> This document describes the "Bump-In-the-Host" (BIH), a host
> >> >>> based protocol translation mechanism that allows a subset of
> >> >>> applications supporting only one IP address family to communicate
> >> >>> with peers that are reachable or supporting only the other address
> family.
> >> >>>
> >> >>> This specification addresses scenarios where a host is provided
> >> >>> dual stack or IPv6 only network connectivity.  In the dual stack
> >> >>> network case, single address family applications in the host
> >> >>> sometime will communicate directly with other hosts using the
> >> >>> different address family.  In the case of IPv6 only network or
> >> >>> IPv6 only destination,
> >> >>> IPv4 originated communications have to be translated into IPv6.
> >> >>> The BIH makes the IPv4 applications think they talk to IPv4 peers
> >> >>> and hence hides the IPv6 from those applications.
> >> >>>
> >> >>> This document is an update to and directly derivative from
> >> >>> Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI
> >> >>> [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim,
> >> >>> Alain Durand, and Erik Nordmark's [RFC3338], which similarly
> >> >>> provides a dual stack host means to communicate with other IPv6
> >> >>> host using existing IPv4
> >> appliations.
> >> >>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-00
> >> >>> .tx
> >> >>> t
> >> >>>
> >> > Fort Monmouth Branch Office - IPv6 Research Supporting DISA
> >> > Standards Engineering Branch

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Oct 2010 18:16:10 +0000

> Sent: Saturday, October 16, 2010 10:21 AM
> To: [email-masked]; Dave Thaler
> Cc: [email-masked]
> So are you essentially saying the BIH module should spend explicit effort to
> determine it is running in the desired scenario?
>
> 1) Test whether A record exist in addition to AAAA and if yes give an error to
> app. IPv4-only app would be allowed to talk only to server that has only AAAA
> record.

No, getaddrinfo() would return a failure only if the host has no IPv4 connectivity,
AND the AI_ADDRCONFIG flag was set by the caller.  See RFC 3493 section 6.1.
Note it doesn't say anything about the behavior of gethostbyname() so an
implementation would have to choose whether that function logically has
AI_ADDRCONFIG set or not.

> Communication to dual-stack enabled servers would be not allowed -
> even if host has only IPv6 connectivity...

Not quite.  Communication would not be allowed *via BIH*.
Communication may still be allowed via some other mechanism, e.g.,
DS-lite.  But that's not the job of the doc in this WG.

>
> 2) Test whether the received AAAA record is actually synthesized and if yes, give
> an error to app. (Synthesized AAAA means there is A record in existence, even if
> for any reason was not received by BIH).

This one doesn't seem necessary to me.

-Dave

>
> But why? Wouldn't the communications fail anyway if the app is not of the
> supported class (e.g. an app that requires ALG)?
>
> Shouldn't the BIH component just make the best effort attempt of IPv4->IPv6
> translation, send the packet out, and then see if the network can actually
> deliver?
>
> Best regards,
>
> Teemu
>
> > should not attempt to solve this case, as the IETF will not do a

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 21:02:35 +0200

Hi,

So the consensus is that IPv4-only "web browser" could connect through BIH to IPv6-only ipv6.google.com, but not to dual-stack enabled www.google.com, because www.google.com happens to have IPv4 address in addition to IPv6?

If so, I try to find a way to write that down, but I don't understand why that would not be allowed. Packet-wise the scenario is exactly the same: IPv4->IPv6 in a host and rest IPv6.

I do understand concerns for NAT464, but not really why the above example is not ok.

So... If the real requirement is to enforce NAT464 avoidance, could the BIH maybe use e.g. draft-korhonen-edns0-synthesis-flag-01 to find out if the address is synthetic or not, and if not then allow communication through?

Best regards,

Teemu
________________________________________
From: ext Cameron Byrne [[email-masked]]
Sent: Saturday, October 16, 2010 9:01 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Cameron

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Oct 2010 19:08:00 +0000

> Sent: Saturday, October 16, 2010 12:03 PM
> To: [email-masked]
> Cc: Dave Thaler; [email-masked]
> So the consensus is that IPv4-only "web browser" could connect through BIH to
> IPv6-only ipv6.google.com, but not to dual-stack enabled www.google.com,
> because www.google.com happens to have IPv4 address in addition to IPv6?

Not *through BIH*.

>
> If so, I try to find a way to write that down, but I don't understand why that
> would not be allowed. Packet-wise the scenario is exactly the same: IPv4->IPv6
> in a host and rest IPv6.
>
> So... If the real requirement is to enforce NAT464 avoidance, could the BIH
> maybe use e.g. draft-korhonen-edns0-synthesis-flag-01 to find out if the address
> is synthetic or not, and if not then allow communication through?

Not needed, as far as I can tell.  All that's needed is to see whether an A
record was returned.

-Dave

> record. Communication to dual-stack enabled servers would be not allowed -
> > 2) Test whether the received AAAA record is actually synthesized and if yes,
> give an error to app. (Synthesized AAAA means there is A record in existence,
> even if for any reason was not received by BIH).
> >
> The use case for what i believe the chart to say is an IPv4-only web browser
> connecting over an IPv6-only network to reach an IPv6-only web server.
>
> I think Jan is asking that the charter directly constrains the applicability of BIH.
> and the draft should reflect that.
>
> Cameron
>
>
> > Best regards,
> >
> > Teemu
> >
> >>> Teredo etc that they are not applicable in those networks that do
> >>> not allow tunneling because of difficulties tunneling causes for policy and
> >>> network (or some segment) is IPv6-only and tunneling services are
> >>> not provided for hosts: do you think BIH should be used to provide
> >>> some connectivity, or rather have no connectivity at all? For me it
> >>> sounds difficult to mandate deployment of IPv4-
> >>> over-IPv6 tunneling endpoint capability to all servers, and there
> >>> are access networks that refuse to provide tunneling due PCC issues.
> >>
> >>> application's packets into IPv6 and the NAT64 translates IPv6
> >>> packets into IPv4 and vice versa."
> >>> >>
> 10512
> >>> >> 1.zi
> >>> >>> From: [email-masked] [mailto:[email-masked]]
> >>> >>> On Behalf Of [email-masked]
> >>> >>> applications supporting only one IP address family to
> >>> >>> communicate with peers that are reachable or supporting only the
> other address family.
> >>> >>>
> >>> >>> The BIH makes the IPv4 applications think they talk to IPv4
> >>> >>> peers and hence hides the IPv6 from those applications.
> >>> >>>
> >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-0
> >>> >>> 0.tx
> >>> >>> t
> >>> >>>
> >>> >>> implementation to automatically retrieve the ASCII version of
> >>> >>> the Internet-Draft.

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 21:15:07 +0200

Hi,

Cellular network operators (as a community) have systematically rejected host based tunneling solutions, e.g. DS-Lite. The traffic must go native.

At least several do like IPv6-only with NAT64, though. Maybe more in the future as transition progresses.

Now BIH could make an IPv4-only application running on a host in said IPv6/NAT64 network contact the content server over IPv6.

As it happens, different instances of the same IPv4-only application may be running on other hosts that may be in IPv4-only networks.

Now the content server is in trouble, as if it is IPv4-only it cannot provide content for application instances running on hosts in IPv6/NAT64 accesses (NAT464 not allowed - this I understand). Switching to IPv6-only provides content for application instances in hosts in IPv6/NAT64 networks, but now apps in IPv4-only accesses are left in cold (the network operators of "legacy" IPv4-only networks unlikely install NAT46s very soon). Dual-stack operation of content server would make everyone happy, but that does not happen to be allowed (and I don't understand why this is not allowed).

Best regards,

Teemu

________________________________________
From: ext Dave Thaler [[email-masked]]
Sent: Saturday, October 16, 2010 9:16 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]
Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Sat, 16 Oct 2010 19:20:15 +0000

> Sent: Saturday, October 16, 2010 12:15 PM
> To: Dave Thaler
> Cellular network operators (as a community) have systematically rejected host
> based tunneling solutions, e.g. DS-Lite. The traffic must go native.

It's unfortunate that operators have rejected solutions that work for all applications
(translation doesn't).  The current IETF consensus is to only standardize such
solutions.   You're welcome to try to change that consensus, but right now
our WG constrains what we can do in this WG.

As I stated during the rechartering discussion, it appears that such operators would
need a tunneling-with-header-compression scheme that doesn't currently exist,
but that would presumably belong in softwires rather than behave.

-Dave

> Now BIH could make an IPv4-only application running on a host in said
> IPv6/NAT64 network contact the content server over IPv6.
>
> As it happens, different instances of the same IPv4-only application may be
> running on other hosts that may be in IPv4-only networks.
>
> Now the content server is in trouble, as if it is IPv4-only it cannot provide
> content for application instances running on hosts in IPv6/NAT64 accesses
> (NAT464 not allowed - this I understand). Switching to IPv6-only provides
> content for application instances in hosts in IPv6/NAT64 networks, but now apps
> in IPv4-only accesses are left in cold (the network operators of "legacy" IPv4-
> only networks unlikely install NAT46s very soon). Dual-stack operation of
> content server would make everyone happy, but that does not happen to be
> allowed (and I don't understand why this is not allowed).
>
> Best regards,
>
> Teemu
>
>
> > So are you essentially saying the BIH module should spend explicit
> > effort to determine it is running in the desired scenario?
> >
> > 1) Test whether A record exist in addition to AAAA and if yes give an
> > error to app. IPv4-only app would be allowed to talk only to server
> > that has only AAAA record.
>
> Communication may still be allowed via some other mechanism, e.g., DS-lite.
> But that's not the job of the doc in this WG.
>
> >
> > 2) Test whether the received AAAA record is actually synthesized and
> > if yes, give an error to app. (Synthesized AAAA means there is A
> > record in existence, even if for any reason was not received by BIH).
>
> > But why? Wouldn't the communications fail anyway if the app is not of
> > the supported class (e.g. an app that requires ALG)?
> >
> > Shouldn't the BIH component just make the best effort attempt of
> > IPv4->IPv6 translation, send the packet out, and then see if the
> > network can actually deliver?
> >
> > Best regards,
> >
> > Teemu
> >
> > >> considerations into this document. I would like to keep BIH
> > >> document small and to describe just a component behavior and what
> > >> it can and cannot do (e.g. ALG issues). Then architecture
> > >> descriptions, be it node design, 3GPP, WiMAX, BBF, whatever, use or
> > >> don't use components to
> > build systems.
> > >>
> > >> But of course we work based on WG consensus:) Hence I try to
> > >> clarify this a bit as it seems to be WG desire.
> > >>
> > >> strict) where the BIH is applicable. Currently the introduction
> > >> IMHO doesn't discuss enough of the applicability and thus you
> > >> should add there something in the lines that BIH should not be used
> > >> when both peers are dual-stacked or both peers are supporting the
> > >> same address family even if there is network segments that have
> > >> different address families in between. BIH is only applicable for
> > >> scenarios where IPv4-only application contacts a IPv6-only server
> > >> with end-to- end IPv6-
> > connectivity.
> > >>
> > >> >  I had passed Teemu an abandoned draft about a translator I
> > >> > worked on about 5 years ago.  It was similar to the BIH, although
> > >> > in an external box rather than on host, the draft called this
> > >> > Bump-in-the-Wire
> > (BIW).
> > >> recommending against the use of BIH technologies together with
> > >> NAT64 to support scenarios where an IPv4 application on an
> > >> IPv6-only connected host talks to an IPv4 server, since I thought
> > >> the recommended IETF approach to support such scenarios is
> > >> encapsulation, as
> > >> >>> communicate with peers that are reachable or supporting only
> > >> >>> the other address
> > family.
> > >> >>>
> > >> >>> dual stack or IPv6 only network connectivity.  In the dual
> > >> >>> stack network case, single address family applications in the
> > >> >>> host sometime will communicate directly with other hosts using
> > >> >>> the different address family.  In the case of IPv6 only network
> > >> >>> or
> > >> >>> IPv6 only destination,
> > >> >>> Below is the data which will enable a MIME compliant mail
> > >> >>> reader implementation to automatically retrieve the ASCII
> > >> >>> version of the Internet-Draft.
> > >> > Ed Jankiewicz - SRI International Fort Monmouth Branch Office -
> > >> > IPv6 Research Supporting DISA Standards Engineering Branch

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 21:41:16 +0200

The consensus was formed after NAT64 was finalized?-)

I read the charter's "IPv6-only" as "effectively IPv6-only from the BIH-enabled node point of view".

Like I said, it would make it easier to edit the document if I would understand why it is better for IPv4-only browser to fail than connect through BIH, using IPv6, to dual-stack enabled web server (in a scenario where the BIH enabled host just does not have IPV4-connectivity). I can of course edit strict text in, but knowing why would make it more fun.

The header overhead is not a real problem, and AFAIK ROHC does compress IP-in-IP tunnel headers away just fine (from the most resource constrained link). The problem is that the policy and charging control, QoS, and about everything is based on assumption that various decisions can be made based on the outermost header.

Best regards,

Teemu

Sent: Saturday, October 16, 2010 10:20 PM

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Oct 2010 09:28:28 +1300

Hi Teemu,

> The header overhead is not a real problem, and AFAIK ROHC does compress IP-in-IP tunnel headers away just fine (from the most resource constrained link). The problem is that the policy and charging…

So what? All that means is that a client that chooses to tunnel gets
best effort service inside the tunnel, and the operator still gets to
apply its policy, charging and QOS to the packets that it sees.
Let's make BIH work for the case it's good for.

   Brian

---

From: <[email-masked]>
Date: Sat, 16 Oct 2010 23:15:37 +0200

Hi,

That's what I and some others tried to say as well:) Use IPv6 for the traffic needing special handling and put the rest in IPv4-in-IPv6.

Anyhow, lots of emails for this Saturday. I will try to fetch the key themes out of all these emails and do -01 by mid next week.

Best regards,

Teemu
________________________________________
From: ext Brian E Carpenter [[email-masked]]
Sent: Saturday, October 16, 2010 11:28 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Hi Teemu,

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2010 23:37:31 +0300

I agree with others who have stated that this document should recommend 
against using double translation. We have been quite clear about that in 
the IETF and even elsewhere that its undesirable. And when we approved 
the new charter for BEHAVE, while we wanted to enable BITS/BITW 
specification, it was not the idea at least as far as I understood to 
start specifying double translation.

So please make sure that the draft focuses on the case where an 
IPv4-only application wants to contact an IPv6-only server, and put all 
other cases out of scope. Including "IPv6-only network".

I don't think you have to describe all the reasons and all the bad 
configurations in your document though. 
Draft-arkko-ipv6-transition-guidelines has a little bit text about this, 
and I could add more, or we could develop an entirely new document about 
that topic. Just make sure that it says clear these things are not 
recommend and that they are out of scope, and do not build technical 
support for them in your mechanisms.

(But I have not yet had a change to read your new version. I will do so. 
Thanks for turning a new version so quickly.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2010 23:45:21 +0300

Dave, Teemu,

> (translation doesn't).

For background, the issue isn't so much what translation or tunneling 
can do. The issue is that the situation is quite different from fixed 
networks, where you typically have intervening routers and links that 
are unable to take IPv6. On cellular that part is quite easy due to the 
already existing mobility tunnels, just turn it on, most products 
support it, underlying network doesn't even know it, etc. There are 
plenty of other issues of course, and one of the biggest ones is host 
support. Adding more software requirements to hosts does not make that 
problem go away, it makes it become worse.

But we're diverging from the topics of this working group... sorry.

Jari

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 23:37:34 +0200

Hi,

Agree with you otherwise (and tried to improve in -01), but please let me repeat what is my exact problem: it is perfectly ok to state (and it is stated in -01) that a system and a host should use encapsulation in the case the network between endpoints is IPv6-only, but I don't agree on the proposal that BIH should actively refuse doing protocol translation attempt in the case the host *is* in IPv6-only access and destination just happens to have A record as well.

I.e. if the destination is effectively IPv6-only from the host point of view and the host happens to be in an unfortunate situation of not having native IPv4 (even encapsulated) available, I think the BIH should be allowed to do the translation and not to be artificially limited. 

What some people propose, i.e. not do translation if a destination has A record, is about building *additional checks* regarding whether a host translation is allowed by IETF policy. That does not sound right way of doing things for me.

My proposal is to recommend against double translation, recommend using encapsulation when peers are IPv4-enabled, but not build artificial policy controls for BIH to guess whether it is allowed translation with a particular destination or not. The tool should be as simple as possible, and use of a tool should be controlled by other means.

Best regards,

Teemu
 
________________________________________
From: ext Jari Arkko [[email-masked]]
Sent: Tuesday, October 19, 2010 11:37 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-00.txt

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 20 Oct 2010 17:16:07 -0700

[email-masked] wrote:
> cannot do (e.g. ALG issues). Then architecture descriptions, be it node
> design, 3GPP, WiMAX, BBF, whatever, use or don't use components to
> build systems.

And as the original component designer, it is the duty of the IETF to provide adequate recommendations on how to use or _not_ to use these components. 

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 21 Oct 2010 09:37:18 -0700

Hi Teemu,

Thanks for updating the draft so quickly. 

>From your message below I think we're now in agreement -- I originally proposed to have an applicability statement recommending against use of BIH together with NAT64 (i.e., double translation), as opposed to additional protocol mechanisms that would prevent use of BIH when there is a NAT64.

I still have some comments on the second paragraph of the introduction. Looking at the first sentence:

   Bump-In-the-Host is not recommended to be used in double translation
   scenarios if the server is dual-stack enabled. 

I think it should be changed to clearly embody the essence of our charter, and then explicitly recommend against combination of BIH with NAT64:

*  Bump-In-the-Host is to be used when an IPv4 application needs to 
*  communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used 
*  together with NAT64 when the server has IPv4 connectivity.

Then the second and third sentences of the paragraph:

                                                      The class of IPv4
   -only applications the described host-based protocol translation
   solution provides Internet connectivity over IPv6-only network access
   includes those applications that use DNS for IP address resolution
   and that do not embed IP address literals in protocol payloads.  This
   includes essentially all DNS using legacy client-server model
   applications, which are agnostic on IP address family used by the
   destination, but not other classes of applications.  The transition
   towards IPv6-only Internet is made easier by decreasing number of key
   applications that must be updated to IPv6.

would IMHO read better as:

*                                         The described host-based protocol 
*  translation solution provides Internet connectivity over IPv6-only network
*  accesses to the class of IPv4-only applications that use DNS for IP address
*  resolution and that do not embed IP address literals in protocol payloads.  
*  This essentially includes all legacy client-server applications using the DNS
*  which are agnostic to the IP address family used by the destination. 

Best,

--julien

> Sent: Tuesday, October 19, 2010 2:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Agree with you otherwise (and tried to improve in -01), but please let
> me repeat what is my exact problem: it is perfectly ok to state (and it
> is stated in -01) that a system and a host should use encapsulation in
> the case the network between endpoints is IPv6-only, but I don't agree
> on the proposal that BIH should actively refuse doing protocol
> translation attempt in the case the host *is* in IPv6-only access and
> destination just happens to have A record as well.
> 
> I.e. if the destination is effectively IPv6-only from the host point of
> view and the host happens to be in an unfortunate situation of not
> having native IPv4 (even encapsulated) available, I think the BIH
> should be allowed to do the translation and not to be artificially
> limited.
> 
> What some people propose, i.e. not do translation if a destination has
> A record, is about building *additional checks* regarding whether a
> host translation is allowed by IETF policy. That does not sound right
> way of doing things for me.
> 
> My proposal is to recommend against double translation, recommend using
> encapsulation when peers are IPv4-enabled, but not build artificial
> policy controls for BIH to guess whether it is allowed translation with
> a particular destination or not. The tool should be as simple as
> possible, and use of a tool should be controlled by other means.
> 
> Best regards,
> 
> Teemu
>

---

From: Hui Deng <[email-masked]>
Date: Sun, 24 Oct 2010 11:28:01 +0800

Hi Julien,

Thanks for your comments,
Inline please,
2010/10/22 Laganier, Julien <[email-masked]>

> From your message below I think we're now in agreement -- I originally
> proposed to have an applicability statement recommending against use of BIH
> together with NAT64 (i.e., double translation), as opposed to additional
> protocol mechanisms that would prevent use of BIH when there is a NAT64.
>
> I think it should be changed to clearly embody the essence of our charter,
> and then explicitly recommend against combination of BIH with NAT64:
>

We authors have already agreed to add the wording above to meet the IETF's
expectation.
What I feel is that double translation does have wider coverage than NAT64,
it can
also means stateless translation. Your proposed wording is quite narrow and
vague.
Also what if the server has dual stack connectivity.  We don't want to go
into that detail each
description about different scenarios. Lastly, this document is more like
host side technology,
not about network side, IETF is a technology specification other than
man-made plictics specification.

> *  which are agnostic to the IP address family used by the destination.
We are fine with this,

Thanks

-Hui

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 25 Oct 2010 10:09:26 -0700

> > proposed to have an applicability statement recommending against use of
> > BIH together with NAT64 (i.e., double translation), as opposed to 
> > additional protocol mechanisms that would prevent use of BIH when there 
> > is a NAT64.
> >
> We authors have already agreed to add the wording above to meet the IETF's expectation.
> What I feel is that double translation does have wider coverage than NAT64, it can 
> also means stateless translation. Your proposed wording is quite narrow and vague.

I am not sure if you find my wording too specific, or too vague. These are opposites in my understanding.

I wasn't trying to imply anything in terms of state{less,full}ness of the translation in recommending against its use together with BIH. If you think that double translation (wider, less specific) is more appropriate to be recommended against, we can certainly do that:

*  Bump-In-the-Host is to be used when an IPv4 application needs to
*  communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used
*  network-side IP translation (e.g., NAT64) when the server has IPv4 
*  connectivity because it implies double translation.

> Also what if the server has dual stack connectivity.  We don't want to go into that detail each 
> description about different scenarios. 

Well then we disagree: the WG is chartered to develop a specific mechanism that applies to a specific usecase, thus that should certainly be captured in the document describing the mechanism. An analogy: every medication comes with guidelines of when to use it, and when NOT to use it. 

>                                            Lastly, this document is more like host side technology,
> not about network side, IETF is a technology specification other than man-made plictics specification.
 
I don't know what that means. Specifications are certainly man-made.

--julien

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 21:55:43 +0200

> *  connectivity because it implies double translation.

Julien, is the above text your propose one that from your point of view covers this idea? I mean based on that, it is technically ok to use BIH when the server is dual-stacked, if just the packet is not translated again to IPv4, but transported as IPv6 to the server?

>From my point of view the mere existence of an IPv4 address on a dual-stack server does not imply double translation - how could it? The BIH host emits IPv6 packet with global source and destination addresses - it does not even traverse through protocol translator.

> Well then we disagree: the WG is chartered to develop a specific
> mechanism that applies to a specific usecase, thus that should
> certainly be captured in the document describing the mechanism. An
> analogy: every medication comes with guidelines of when to use it, and
> when NOT to use it.

The use case that is targeted should definitely be captured. But I fail to see IETF documents capturing very many use cases they are not designed for? After all, many tools find home in uses other than the original intent. I guess even IP was designed for other stuff than what is used nowadays.

And even the medicine usually comes with "consult your doctor (especially if you start feeling symptoms)" recommendation. And most often the dosage must be prescript by a doctor. This is especially true with medicines that have both pros and cons in them.. The transition tools are all solutions with pros and cons, as we all know..

Best regards,

Teemu

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 29 Oct 2010 12:29:32 -0700

Hi Teemu,

Sorry for the delay...

[email-masked] wrote:
> Julien, is the above text your propose one that from your point of view
> covers this idea? I mean based on that, it is technically ok to use BIH
> when the server is dual-stacked, if just the packet is not translated
> again to IPv4, but transported as IPv6 to the server?
> 
> From my point of view the mere existence of an IPv4 address on a dual-
> stack server does not imply double translation - how could it? The BIH
> host emits IPv6 packet with global source and destination addresses -
> it does not even traverse through protocol translator.

Hmm... Maybe I got confused. My only point is that I want this specification
to recommend against combining the technology therein described with NAT64, as
had been and still is being proposed outside the IETF.

So about this: 

 *  Bump-In-the-Host is to be used when an IPv4 application needs to
 *  communicate with an IPv6 server. Bump-In-the-Host SHOULD not be used
 *  together with network-side IP translation (e.g., NAT64.)

?

> > > Also what if the server has dual stack connectivity.  We don't want
> > > to go into that detail each description about different scenarios.
> >
> > analogy: every medication comes with guidelines of when to use it,
> > and when NOT to use it.
> 
> The use case that is targeted should definitely be captured. But I fail
> to see IETF documents capturing very many use cases they are not
> designed for? After all, many tools find home in uses other than the
> original intent. I guess even IP was designed for other stuff than what
> is used nowadays.

While you can certainly find supporting examples of tools used for purpose
other than originally designed for, I can certainly find plenty of real-world
examples where things are clearly labeled with all-uppercase "DO NOT USE
FOR <insert possibly harmful usage here>", or "FOR <insert original and harmless
usage here> ONLY". 

E.g., a hand sanitizer bottle I have in front of me says "FOR EXTERNAL USE ONLY."

I can also find examples of things not being labeled with recommendation against
harmful use that leads to actual harm, e.g., bleach in a drinking glass on a
kitchen countertop, kids around and no adult. [ true story ] 

So all in all I see no reason why we should not recommend a use when we know it
is harmful.

--julien

---

From: Jan Melen <[email-masked]>
Date: Fri, 29 Oct 2010 23:52:26 +0300

Hi Teemu and Julien,

Sorry from my side that I have been tuned off from the discussion for a while...

> *  together with network-side IP translation (e.g., NAT64.)

I agree with Julien that we need to be very clear on what we are recommending both for and against. Maybe this has not been the way we have worked earlier (personally I would disagree with that statement) but it is really what the outside world looks for. There is a real need for somebody to say that this thing X is good for this but if you use with this there will be problems. Certainly, there still will be people who will do anyhow against the recommendations but as majority still would like to be good citizens I think it is worthwhile giving them good guidance rather than opposite. So I'm in favor putting a clear statement as Julien suggests.

   Regards,
     Jan