Re: WG last call on NAT-PT to Experimental

[Baker Fred <fred@cisco.com>]

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