On Jul 28, 2011, at 3:50 AM, Philip Homburg wrote: > In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote: >> PS - And in those cases, proper address selection is a much better solution >> (IMHO) than hitting this screw with a hammer. > > I think the problem is that we don't know how to do 'proper' address > selection. It would be nice if 5 or 10 years ago there would have been a good > standard to do address selection. Today, we are just in the stage of doing > more experiments. > > There is one thing that works well. And that is, you only assign global > IPv6 addresses to a host if global IPv6 connectivity is at least as good as > IPv4 connectivity.
In general, all of a host's addresses (at least, those in the same preference class in the address selection algorithm) need to work equally well from everywhere. But even that might not be sufficient. Fred Baker has recently been citing a different example of the same problem: Imagine a future where hosts on a network have both v6 and legacy v4 through stateful NAT. Because the v6 connection works well most of the time, hosts tend to choose v6 destinations, and sites reduce the capacity of their NATs over time. Then the v6 connection fails, and suddenly everything falls back to v4, and the connections through NAT also fail for lack of sufficient capacity to handle the load. Note that in some sense this is a perceptual problem. If instead of a v4 and a v6 address, each of those hosts had two v6 addresses and two different egress paths, the network engineers would be more likely to understand that both external connections needed to be of equal capacity - just like multihomed v4 networks with a single prefix now. And in some sense there's nothing wrong with having a v6 connection for most things and a small v4 NAT for connecting to legacy v4 services, as long as you don't think of the v4 path as a fallback - you're willing to accept that loss of the v6 connection is for practical purposes loss of external connectivity. The problem is that if you think of the v4 NAT as a fallback for the v6 service, AND you don't drastically overprovision the NAT. > We want large scale deployment of IPv6 today not some time in the future > when we finally figured out address selection. And that means that today we > have to make sure that users don't end up with unreliable IPv6 connections. If you make the constraint that nobody can use IPv6 at all until the IPv6 connections work as well in all cases as the IPv4 connections, that creates a huge barrier to the universal deployment of IPv6 - which already has enough barriers as it is. A less onerous constraint is that less reliable IPv6 connections don't get used in preference to more reliable IPv4 connections. We're lucky in the case of 6to4 in that it has a well-known prefix that allows the traffic to be distinguished from other v6 traffic. But it's still necessary to manage expectations about IPv4 as a fallback path. Keith _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
