[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG last call on NAT-PT to Experimental


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.


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