On 22/11/2013 12:29, John C Klensin wrote: > > --On Friday, November 22, 2013 11:37 +1300 Brian E Carpenter > <brian.e.carpenter@xxxxxxxxx> wrote: > >> ... >> Actually there has been a clear market choice among many ISPs >> for years: straightforward dual stack. It works very well. We >> also have a plethora of tunnelled solutions, some better than >> others, which apply to various different scenarios where the >> provider's view is that OPEX for dual stack is higher than >> OPEX for tunnels. The service to the application software is >> still dual stack (in most cases). > > Brian, > > Keeping in mind that, with respect to this question, I'm just an > apps guy, but my impression is quite different, mainly: > > (1) Unless the service levels between the endpoint machines are > always equivalent when IPv4 and IPv6 are both present and there > are no circumstances in which a choice between IPv4 and IPv6 > would make a service difference, there is no such thing as > "straightforward dual stack". >From the apps point of view, that's true; hence we end up with heuristics such as Happy Eyeballs. I was referring to ISP (or campus) infrastructure, where people have been running dual stacks for many years. > (2) The non-straightforward version requires that applications, > at least TCP-based applications, be able to make rather complex > route optimization decisions about which protocol and addresses > to use and make those decisions in a way that completely > violates clean layering models. We have, in general, never > figured out how applications are supposed to do that, nor how to > make the needed information available to them. Probably because there is no general solution to that problem, but IMHO you can't fix that without a time machine that takes you back to about 1977. > (3) If one is going to have dual stack on the applications > (generally "client") machines, they need either wired-in > simplistic preference models (e.g., "always prefer IPv6") or > protocols for getting information from and controlling border > routers to which they have default routes. The former has not > served us well and we haven't done the protocol work for the > latter. Another alternative would be to actually do routing > from the applications machines with either packets source-routed > through the border routers or the latter being completely > transparent. As far as I know, the Internet has not worked that > way in a very long time and no one has seriously proposed > changing the way it does work. Actually, in the MIF/Homenet world you will find a lot of discussion of the need for source/destination based routing. > Now I'm obviously missing, or misunderstanding, something that > allows you to assert that straightforward dual stack is the > clear market choice and works well despite the above. Could > you explain what it is? As I said, I'm talking about ISP infrastructure, where the issue is how to deliver both v4 and v6 service to the customer side of the CPE box. For years, ISPs that do this by simply running both protocols have been saying that it's straightforward. The problems you describe are ones that occur when a host sees more than one IP service. They don't depend (or very little) on how those services are carried inside the ISP infrastructure. On the other hand, I haven't noticed any particular user issues from this, whether my dual service has come from my ISP, a campus, or the IETF network. I'm not sure my wife knows that she's using IPv6 for a lot of what she does. The problems, though real, are not blocking for most current users. Also, IMHO, they have nothing specific to do with IPv6; they are intrinsic to running two network layer protocols. Brian >>> And the market is not going to make a choice because the >>> market stakeholders find NAT works well enough for its needs. >> And when it doesn't, they will switch to IPv6. > > Or they will build bigger NATs or invent a latter-day version of > X.75 gateways at peering points or national boundaries. It > isn't clear to me that IPv6 is the only remaining choice when > the easiest-to-deploy NAT technologies turn out to be > insufficient or too hard to operate. If it is not, then we have > no guarantees that IPv6 will be chosen over options and most of > us would consider worse. > >>> What I would do as a government entity is to get a group of >>> techies to describe a minimum set of technical capabilities >>> for Internet access points. >> Please don't. The history of government mandates for IPv6 is, >> to say the least, chequered. > > Indeed. Just like the history of government mandates for other > networking technologies. > > john > > > >