Re: WG last call on NAT-PT to Experimental

[Rémi Després <remi.despres@rd-iptech.com>]

> 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