Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00

[Fred Baker <[e-mail]>]

On Feb 7, 2011, at 10:04 AM, Templin, Fred L wrote:
> Why not something better? Why not IRON:

"Better" is a value judgement, a comparison of a proposed solution with a set of requirements, and is often somewhat in the eye of the beholder.

I think it would be fair to say that the objective of v6ops is to deploy, operate, and maintain a ubiquitous IPv6 network comparable to the IPv4 network of today and independent of any underlying infrastructure. There may well be underlying infrastructure of various kinds - ATM, MPLS, various WAN technologies, or "Ethernet" in whatever form it may appear at the moment. However, the networks that the operators on this list operate are not networks in which one expects hosts to dynamically place circuits on an infrastructure of a different kind to provide service, but to operate as a ubiquitous and stable service. 

It may be fair to ask each type of technology to describe its relationship to that kind of service, and to carefully consider the operational implications of running it. That's where Ole is coming from in suggesting that RFC 3056 be retired; it depends on an underlying infrastructure (IPv4 addressing and anycast servers), and has been a source of problems for ISPs trying to deploy native IPv6 service as noted in RFCs 3964 and 4472, and in the drafts draft-ietf-v6ops-tunnel-loops, draft-ietf-v6ops-tunnel-security-concerns, draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and draft-vandevelde-v6ops-harmful-tunnels. That is also at least in part where questions of other overlay networks like Teredo come in.

If I can summarize Keith's concern with 6rd, it is not that it doesn't deploy an IPv6-capable service; it is that the service has a smaller Path MTU than the native MTU of links he uses, often has a broken PMTU implementation due to ICMPv6 filtering, and is not native. If I can summarize the views of those using it (such as a Dutch provider I spoke with Wednesday in London), it's not that they don't want or expect to deploy a native IPv6 service, it's that they want to deploy an IPv6 service now and have infrastructure that they can't immediately upgrade (such as, in the Dutch case I mentioned, a service network that they have to use that is IPv4-only for the foreseeable future).

Similar exchanges can be described around dIVI, 4rd, and ds-lite. Fundamentally, if my bread and butter today is IPv4 and my shiny new IPv6 network will in the nature of the case require some time to harden, why would I disrupt my bread and butter to deploy the new, and while doing so make my present business model dependent on the not-yet-hardened network? They are very reasonable ways to remove IPv4 from a dual stack network, but from the perspective of risk an odd way to deploy the IPv6 network.

If you want to make the case that IRON is "better" than something else, I think the thing to do is write the applicability statement. The networks on this list operate as a ubiquitous and stable service comparable to the present IPv4 network and independent of any underlying infrastructure; anything else needs to help them move toward that goal, and needs by nature to be effortlessly removed from the network as native IPv6 deployment settles in. What is the applicability of IRON to such a network?