[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call on NAT-PT to Experimental
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: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] 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
> >
>
>