A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity

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

 



On 6-jul-2007, at 0:54, Keith Moore wrote:

the problem is that those simple applications share the same hosts and
network that the other applications do.  if you put devices in the
network that only solve problems for the simple applications, then you
get a network that can only run simple applications.

      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hence the part in my previous message about dynamically obtaining real IPv4 connectivity tunneled over IPv6 when non-simple applications need to talk to the IPv4 world.

I understand there is a moratorium on new IPv4-IPv6 transition techniques in effect. I'm not familiar with the precise reasons for that (I assume it's the huge number of such mechanisms that was being proposed) but now that we have a better picture of the obstacles that block the transition from happening, I think it's time to revisit this and come up with a comprehensive set of transition tools that together, address the full range of user needs rather than one here and one there.

In my opinion, dual stack has largely served its purpose here and we should put that on the back burner and start thinking about going IPv6-only in parts of the network, because dual stack by definition means adding complexity while it doesn't provide any benefits at this time. While IPv6-only has its problems, it does make building a network simpler. See

http://arstechnica.com/news.ars/post/20070704-the-declaration-of-ipv6- independence.html

But I'll take that up on v6ops.

And from an
architectural perspective, address translation is clearly a dead end.
One of the reasons we argue against NATs is not that there aren't other
major problems, it's that people haven't managed to get the message on
NATs yet.

Well, an iceberg looks very differently depending on whether you look at it above water or below. The problem with NAT is like almost all persisting problems: the bad consequences aren't felt in the place where they're created.


_______________________________________________

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]