Re: chicago IETF IPv6 connectivity

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

 



On 13-jul-2007, at 19:08, Jun-ichiro itojun Hagino wrote:

NAT-PT really needs to be wiped off the face of the earth.  It
provides all of the disadvantages of IPv4+NAT with all of the
transition costs of IPv6.

Indeed it does.  However, it has significant benefits as well:

	cannot agree more.  i do not care if it is based on TCP/UDP relaying
	(per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators
	have its own benefits.  and of course drawbacks, but the drawback
is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape
	plan (use native IPv6).

It seems like the discussion I was trying to start in v6ops is happening here instead... http://psg.com/lists/v6ops/v6ops.2007/ msg00467.html

I don't think NAT-PT or transport relay are the best choices to allow IPv6 hosts to talk to IPv4 hosts, because they both require the insertion of boxes with very non-standard behavior in the network and a DNS ALG to get the packets to those boxes. Using existing proxies is easier, because they don't create DNS pollution or strange boxes, they're simply applications running on a server, like so many other applications. The fact that proxies are already widely deployed doesn't hurt, of course.

(NAT-PT/transport relay require the host to do DNS lookups over IPv6 or have IPv4 connectivity for the DNS lookups, while proxying is even possible if the host doesn't have access to the DNS. Example: set up proxying towards an [IPv6 address] in IE7 on Win XP, which can't do DNS over IPv6 transport.)

But we can't stop here, we need to provide a way to handle applications that have more extensive needs than those that can be met by a proxy as well, or the effect will be NAT/ALG stuff in IPv6. In my opinion, the easiest way to do this is to tunnel IPv4 over IPv6 on demand. I gather the softwires wg is working on that.

So if we add some glue in the form of an API or logic that knows when to switch from proxying to real tunneled IPv4 connectivity and discovery / automatic setup we're in good shape and people can start removing IPv4 from their networks except at the borders where the translation happens.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]