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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf