Subject: RE: WG last call on NAT-PT to Experimental

From: "Bound, Jim" <[email-masked]>
Date: Sun, 13 Mar 2005 13:56:26 -0500

Fully agree with Fred with one caveat.  IPv6 dominant does not mean IPv4 does not exist but that IPv6 has been on purpose chosen to be used and IPv4 is there on all nodes but not being used on a specific network. IPv6 only and IPv6 dominant need differentiation. from us as a community. Thus the question is the edge dual IP?  If it is maybe tunnels can be used at the edges which DSTM suggests as one operational suggestion.  But if the pool of available v4 addresses is depleted by a site that must communicate with IPv4 network/apps/nodes/et al then no other choice exists that I can see?  The other case is when there are really IPv6 only stack devices with no IPv4 available at all on the node that has to access legacy IPv4 services and in that case no choice again.  Also I am pointing people in industry to the NAP draft which I think is par excellent discussion of getting what you need from a NAT networking philosophy in many cases with IPv6.

NAP above == draft-vandevelde-v6ops-nap-01.txt just in case....

/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Baker Fred
> Sent: Friday, March 11, 2005 9:27 AM
> To: Rémi Després
> Cc: Pekka Savola; Elwyn Davies; v6ops
> Subject: Re: WG last call on NAT-PT to Experimental
> 
> Speaking for my politically-incorrect self, I agree that 
> translation is 
> a reality whether anyone likes it or not.
> 
> I don't think too much in terms of "during the transition period", as 
> that period is likely to last for the remainder of my lifetime, with 
> many networks putting IPv6 off until there is strong economic 
> incentive 
> to change, and some percentage of networks being IPv6-dominant (using 
> Jim Bound's term) pretty early and some being IPv6-only in the 
> not-too-distant-future. To me it is simply this: from any given place 
> (which is a question of network connectivity and 
> interconnectivity) and 
> at any given time, folks are reachable by IPv4, IPv6, or both. To the 
> extent that there exist folks who are reachable only via IPv4 
> and folks 
> reachable only via IPv6, communication will be limited if 
> there is not 
> ability to translate. Companies are *very* likely to find translation 
> at their DMZ a practical alternative to wide IPv6 deployment within 
> themselves while the number of companies that one is forced 
> to use that 
> to get to is nominal.
> 
> That said, as this draft says, tunnel encapsulation is a more 
> end2end-freindly approach where it is applicable, and dual stack 
> implementation is obviously to be preferred for any currently-IPv4 
> network.
> 
> 
> On Mar 10, 2005, at 5:29 AM, Rémi Després wrote:
> 
> >> This is a working group last call on publishing "Reasons to Move 
> >> NAT-PT to
> >> Experimental" (draft-ietf-v6ops-natpt-to-exprmntl-00.txt) as an
> >> Informational RFC.
> >>
> >> Please send any substantive comments on the list.  The deadline for
> >> comments is in about two weeks, 24th March.
> >
> >  1. The technical content of this document [1] is thorough, well 
> > explained,
> > AFIKT completely accurate, and IMHO invaluable.
> >
> >  2. Yet, the document incidentally suggests that no form of  
> > Translation
> > from v6 to v4 will need being standardized for the v4-v6 coexistence
> > period.
> >
> >     I believe this should be avoided, and could easily be so .
> >
> >
> >    A. Why should the door remain open for some form of  v6 to v4
> > translation?
> >
> >         -  During the coexistence period some v4-only hosts will 
> > remain,
> > both in some v4-routing-only sites and in some mixed v4-v6-routing 
> > ones.
> >         -  For some of these v4-only hosts, capability of being 
> > callable by
> > some remote client(s) , e.g. in HTTP, will be neded, for real 
> > applications.
> > (Stating that these hosts should all become dual-stack would not be 
> > user
> > friendly as we wish to promote transition to v6 by means of 
> > coexistence!).
> >         -  V6-capable clients, be they without global v4 addresses, 
> > should
> > be able to reach such hosts as servers. (A 128-bit called 
> address is 
> > enough
> > to designate a server, wherever this one is in the v4-v6 Internet.)
> >         -  Two approaches then remain :
> >             .    Some form of DSTM where the calling client 
> borrows a
> > temporary global v4-address, and encapsulates v4 in v6 along an 
> > appropriate
> > v6 path.
> >                      Its main limitation is the complexity 
> involved, in
> > particular to manage pools of temporary global v4-addresses in 
> > specialized
> > servers.
> >                      Its main advantage is transparency to all v4
> > applications.
> >             .   Some form of  NAT (or NAPT), say "NAT-6to4", at the 
> > called
> > host site entrance, converting the v6-adresse of calling clients to 
> > local
> > v4-adresses.
> >                      Its main limitation is that only NATv4 
> compatible
> > applications are supported (but there are many, all HTTP based ones
> > in particular).
> >                      Its main advantage is simplicity (no 
> concern with
> > global v4-addresses, and well understood, and widely implemented,
> > management of the life-times of NAT provided addresses).
> >
> >
> >  B. How could some form of  v6 to v4 translationt still be 
> envisaged in
> > view of problems raised in [1]?
> >          -  Problems raised in 1 concern ; (1) 
> Incompatibilities with 
> > IP
> > Fragmentation ; (2) ALGs complexity and shortcomings ; (3)  
> > Restrictions
> > imposed on applications.
> >          -  Fragmentation and ALGs are not needeed to satisfy the
> > requirement of A. They can be explicitely excluded of the detailed
> > specification of NAT-6to4.
> >          -  Applicability of NAT-6to4 can be explicitely 
> restricted to
> > applications which don't exchange IP addresses at appliction layer.
> >
> >
> > CONCLUSION:
> >
> > If there is some support for this analysis, I am ready to work with 
> > authors
> > of [1] on minor short term amendments to their document, 
> and also to 
> > work
> > more generally with whoever is interested in progress on 
> this subject.
> >
> > Regards,
> >
> >
> > Rémi
> >
> 
>

---

From: Baker Fred <[email-masked]>
Date: Sun, 13 Mar 2005 17:13:13 -0500

On Mar 13, 2005, at 1:56 PM, Bound, Jim wrote:
> IPv6 dominant does not mean IPv4 does not exist but that IPv6 has been 
> on purpose chosen to be used and IPv4 is there on all nodes but not 
> being used on a specific network. IPv6 only and IPv6 dominant need 
> differentiation from us as a community. Thus the question is the edge 
> dual IP?

Of course.

The principal use of IPv4 in an otherwise IPv6 network is generally 
supporting applications that have not made the transition yet, I 
suspect.  I know of some networks (CNGI for example) that are proposing 
to use a combination of IPv4 and IPv6 within the backbone for various 
purposes, but only offer an IPv6 edge. You allude to a period in which 
companies have parts of their infrastructure addressed using IPv4 and 
parts not. While that is a possible scenario, I doubt its importance - 
that will be solved using IPv4 NAT.

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 Mar 2005 11:54:11 +0100

>You allude to a period in which

Le me describe differently important applications which, in my
understanding,  justify that "some v6-to-v4 translation schemes"  be still
proposed by the IETF fort he v4-v6 coexistence period.

- IPv6, it's a revolution, brings us back in the simple world where any
device, anywhere, can have an IP address, advertise it in the DNS, and can
have packets routed efficiently to it.
- Some v4 devices, like small cameras or various sensors, if installed in
private sites are today restricted to be called only from within these
private sites. (If there is only one such device in a user site, or if all
port of the application are known and can be individually translated, this
restriction can be avoided using some v4NATs with their Port Forwarding
option, but this, although being useful in a number of practical cases,  is
too limited and complex to be the kind of clean and general solution people
would like to use on a large sccale.
- If such a v4 device is in a site where both v4 and v6 routings are
available, a v6 address could advatageously be given to it. Its content
would logically include:  the device site v6-prefix (for efficient routing
toward the site);  the device intra-site  v4-address (for device
identification, and for efficient routing within the site); some indication
that the device is v4 only (for the site-entrance-node to decide whether to
perform v6-v4 translationor not).
- With such an address, and implementing at site entrance a stateful
v6-to-v4 translation, the considered v4-only device becomes reachable from
anywhere, subject only to v6 connectivity being available at calling hosts.
(If  needed, firewall protections at site entrance may apply to these
connections as they do to end-to-end v6 connections).
- Such  stateful v6-to-v4 translation can remain much simpler than the
general NAT-PT model (and has to, in view of
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-00.txt )
    .   No support of fragmentation is needed. (IPv6 already assumes that
all usable paths support MTUs of 1280 + enough octets for any realistic
number of encapsulatng headers.)
    .   No support of Application-Level-Gateways is needed, not even for
DNS. (The calling hosts get v6 addresses from the v6-DNS, and these
addresses contain all the v4 information needed at the v4-device site
entrance.
    .   No  support of applications which exchange IP addresses as data is
needed (the solution is useful enough if not extended to applications which
today cannot be reached via v4-NATs at global v4-addresses.

(An earlier look at the the subject is available in sec. 4.3 of
http://perso.wanadoo.fr/remi.despres/4to6.htm, but please note that the
address format proposed in the document, having unneeded drawbacks pointed
out during private discussions, should be considered as obsolete.)

The PROPOSAL then is that,  after NAT-PT has been deprecated to
experimental, some work  on v6-to-v4 translation MAYcontinue.
The goal is that applications involving of a number of  legacy devices can
take advantage of IPv6 being deployed inCustomer-Edge devices and in the
DNS.

RD

---

From: Baker Fred <[email-masked]>
Date: Mon, 14 Mar 2005 06:20:02 -0500

> experimental, some work  on v6-to-v4 translation MAYcontinue.

My question is "what is hard about that".

Any translator has all the issues of NAT, and is *not* going to try to 
insert units of 12 bytes into application data, or making IPSEC work. 
Therefore, this doesn't begin to work for any application that has a 
hard time traversing a v4-v4 NAT.

Having limited ourselves to those applications for which it works 
without changing application data, there are four requirements:
  - that DNS be made to work (the far device is only advertising an A or 
MX record; we need to set up relevant state and advertise a AAAA record 
referencing the translator)
  - that the assigned IPv6 address correlate with the IPv4 address+port 
in question (let me think hard, I'll bet the IPv4 address+port get 
embedded in the IPv6 address)
  - that the router not be required to re-assemble datagrams (use Path 
MTU, MSS modification, etc to effect this)
  - TCP/UDP/SCTP works (adjust the transport checksum appropriately)

I'm not opposed to necessary work being done, but I'm not so sure what 
work needs to *be* done. We seem to have a lot of transition efforts 
around, but there must be a way to bring them together into a single 
simple solution. Bring us that one simple path, and then we'll talk.

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 Mar 2005 16:43:37 +0100

Thanks for your remarks.

My impression is that you are thinking of a different case.

The v6-to-v4 translation I am after concerns:
 -  called v4 devices which have AAAA record in the DNS in order to be
reachable from outside their site. ( If such a device has also to be reached
by hosts in the same sites, a local DNS may also contain an A record giving
its local v4- address. But this is not the subject at hand.)
-  called sites the entrance node of which are dual-stack
-  calling hosts which have v6 connectivity (and access to  AAAA records).
  (The translation therefore works in the reverse direction from that of a
NAT-PT used for v6 hosts to reach v4 hosts at global v4-addresses.)

Other point-by-point comments follow.

>Having limited ourselves to those applications for which it works without
>changing application data, there are four requirements:
>
>- that DNS be made to work (the far device is only advertising an A or MX
>record; we need to set up relevant state and advertise a AAAA record
* No DNS record translation is needed here because the calling host is
assumed to have v6 connectivity, and access to v6 DNS, and because the
called host has a v6 address in the DNS.

>  - that the assigned IPv6 address correlate with the IPv4 address+port in
> question (let me think hard, I'll bet the IPv4 address+port get embedded
> in the IPv6 address)
* The port which may be modified by the translator is that of the  calling
host.
  It has no relationship with this host's address, which is any v6 address.
  The port of the called device is that of the application.
  It is not subject to any translation, and has therefore no reason to
appear in any address.

>  - that the router not be required to re-assemble datagrams (use Path MTU,
> MSS modification, etc to effect this)
* On the v6 side, the v6-to-v4 translator could simply reject any v6 packet
longer than 1280.
  On the v4 side, it could simply reject any v4 packet which contains a
fragment of an incomplete datagram.

> - TCP/UDP/SCTP works (adjust the transport checksum appropriately)
* Yes. Due to pseudo-header inclusion in UDP and TCP checksums, the
translator has to adjust these checksums (like NAT-PT has to).
  On the other hand, SCTP, which has in my understanding checksum adjustment
problems also with IPv4 NATs, should remain out of the scope of the proposed
mechanism.
  (Incidentally, we can assume that there should be a negligible number of
v4 devices which are both SCTP capable and not easily dual-stack
upgradeable.)

> simple solution. Bring us that one simple path, and then we'll talk.
* In my understanding, the proposal I bring forward is orthogonal with other
questions being worked on (in particular with tunnel configurations of
v6tc), and does satisfy a real need.
  Its main new implication is an address format variant, which contains a
specific indication if the addressed node has to be reached in IPv4.
  Besides that, unless I am mistaken, complete specification of the
translator should not be difficult, starting from the work already made for
NAT-PT and from the comments above.

*Last but not least, and to keep maintaining everything on the table, an
Intellectual Property implication is part of the picture.
  This was made known as early as in November 2004, when
http://ops.ietf.org/lists/v6ops/v6ops.2004/msg01660.htmlt pointed to an
early and first document. Its introduction was clear on IP rights (and its
section 4.3 is still somewhat relevant).
  I obviously hope that this should not be blocking.
  If, as I do expect, the practical value of the approach is eventually
appreciated, my plan is not more than getting a fair and reasonable return
for the significant work I did. (This work was a personal investment,
without any compensation from anywhere).
  The goal is besides that to make the benefits of that work available to
the community of whoever may take advantage of it.

RD