Subject: WG last call on NAT-PT to Experimental

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Mar 2005 05:04:02 +0200 (EET)

Hi,

(co-chair hat on)

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.

Thanks!

(hat off)

---

From: Rémi Després <[email-masked]>
Date: Thu, 10 Mar 2005 12:29:02 +0100

> 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.
>

  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: Fri, 11 Mar 2005 08:26:46 -0600

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:

>> NAT-PT to

---

From: [email-masked], Remi <[email-masked]>
Date: Fri, 11 Mar 2005 19:22:50 +0100

Thanks for the comments.
Further remarks below.
Remi

> To the reachable only via IPv6, communication will be limited if there is
> not ability to translate. Companies are *very* likely to find translation
> themselves while the number of companies that one is forced to use that to
> get to is nominal.
ALG translations in DMZs are significantly more complex than just
some NAPT-6to4 at the entrance of v6&4 sites where there are v4-only
servers that have to be reached from outside.

>end2end-freindly approach where it is applicable,
Agreed, but as you say "when it is applicable"
E2E encapsulation is not relevant to reachability of v4-only host.

>and dual stack
>implementation is obviously to be preferred for any currently-IPv4 network.
Agreed also.
But the subjet is making reachable some "servers" which, for some legitimate
reason(s), are not updated to dual satck (e.g. some egacy small devices like
sensors, or other automata, which today operate within v4 private sites).

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Mar 2005 08:05:41 +0200 (EET)

Folks --

The WG last call ends in a couple of days.  More comments, feedback, 
suggestions for improvement etc. would be welcome...

On Thu, 10 Mar 2005, Pekka Savola wrote:
> 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.
>
> Thanks!
>
> (hat off)
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings