Hi John, So, It was assumed that IPv4 depletion would effectively lead to the adoption of IPv6. This has not been the case in the last decade save for a very few countries in the world.
It was also assumed that IPv6 only networks would crop all over the place as a result, providing the same interconnectivity benefits enjoyed by the IPv4 internet. Out of curiosity,did the emergency of transfer markets slow IPNG adoption while creating prolonged dependence on IPv4? Cheers, *.**/noah* On Thu, Mar 24, 2022 at 4:03 PM John Curran <jcur...@istaff.org> wrote: > On 24 Mar 2022, at 5:19 AM, Mark Delany <k...@november.emu.st> wrote: > > > On 24Mar22, Greg Skinner via NANOG allegedly wrote: > > straightforward transition plan > > > in-hand working transition strategy > > > nor a straightforward transition > > > The words quoted above are mine, not Greg’s, so let’s send the blame in my > direction not his… :-) > > Any such "transition plan" whether "working" or "straightforward" is > logically > impossible. > > > That entirely depends on what is meant by “straightforward transition > plan”… If one means a plan that provides that “Network ABC will transition > on this date with this approach, and then Network JKL will transition using > this approach, then network XYZ shall transition on this date, etc. ” then > you are indeed correct – such a command-and-control approach is not "the > Internet way", comrade. > > If by “straightforward transition plan” one means a clear and rational set > of options that allows networks to plan their own migration from IPv4-only > to IPv6, while maintaining connectivity to IPv4-only hosts and with a level > of effort reasonable comparable to just running IPv4, then I would > disagree, as such an "IPng transition plan” was achievable, expected, and > we collectively failed to deliver on it (as noted below) > > The "Technical Criteria for Choosing IP The Next Generation (IPng)” > [RFC1726] did have a specific requirement in this regard (see quoted > section attached to this email), and that requirement postulated that > “there will be IPv4 hosts on the Internet effectively forever. IPng must > provide mechanisms to allow these hosts to communicate, even after IPng has > become the dominant network layer protocol in the Internet.” It also > noted that we must be able to run dual-stack with a comparable level of > effort as IPv4-only, but that dual-stack alone was not sufficient and > actual interoperability mechanisms would be required between IPv4 and IPng > for IPng success. > > The IPng recommendation [RFC 1752, > https://datatracker.ietf.org/doc/html/rfc1752] proceeded with the SIPP > proposal as the basis for IPv6, just noting some weakness with respect to > satisfying this IPng transition requirement – > > The biggest problem the reviewers had with SIPP was with IPAE, SIPP's > transition plan. The overwhelming feeling was that IPAE is fatally > flawed and could not be made to work reliably in an operational > Internet. > > > The work to meet this requirement was punted to a newly-defined IETF IPng > Transition (NGTRANS) Working Group - the working group was to design the > mechanisms to necessary for a straightforward transition of the Internet > from IPv4 to IPv6 and to give advice on what procedures and techniques are > preferred. NGTRANS did define a set of dual-stack and tunneling solutions > [RFC 4213], but didn’t get to actual interoperability mechanisms or clear > roadmap of options that would have met IPng’s requirement for > straightforward transition plan. > > In fact, what happened instead is that dual-stack (aka “Ships in the > Night” - both protocols should be able to run on the same host unaware of > the others existence) ended up as the de facto IPv6 transition strategy, > and anything more was left to be researcher/vendor/user defined… For > those who want a really nice summary of the state of affairs on IPv6 > transition around 2008 (more than 10 years after the IPng recommendation) I > would suggest Geoff Huston’s "IPv6 Transition at IETF 72” summary in the > IETF Journal <https://www.ietfjournal.org/ipv6-transition-at-ietf-72/> – > as usual, Geoff does a great job with a rather complex topic. > > So instead of having a clear & straightforward menu of options for network > operators on how to deploy IPv6 in parallel in their network without > breaking anything (i.e. a set of coherent strategies to choose from that > would have constituted a “a straightforward transition plan”), we ended up > with an explosion of transition approaches in various states of > functionality, side-effects, and maturity – the exact opposite of what a > network operator wants to face when considering transitioning their > production network to IPv6. There was even an attempt to inventory the > various solutions - > https://www.ietf.org/archive/id/draft-jankiewicz-v6ops-v4v6biblio-03.txt – > but keeping track of them all is akin to counting tribbles so I don’t > believe it was ever published. > > Luckily, necessity is the mother of invention, and those whose operators > experiencing the most significant network growth have figured out the > particular protocols and techniques necessary for their transition to IPv6. > Of course, that also meant each operator and their vendors have to work > out all of the inevitable interactions with other protocols, security > aspects, etc. anew with their particular chosen approach and selected > technologies – hence why even to this day there is not a standard > “cookbook” or “straightforward transition plan” for networks on how to > deploy IPv6. I’ll be the first to admit that there are many networks that > have sufficient complexity or unique aspects that warrant their own custom > plan for IPv6, but disbelieve that the majority of network operators could > not benefit from a clear set of standardized transition approaches for IPv6 > rollout. (Alas, Internet standards work has generally taken a “let a > thousand flowers bloom” approach to such matters, despite the IPng > requirement to the contrary.) > > FYI, > /John > > ==== Excerpt - "Technical Criteria for Choosing IP The Next Generation > (IPng)” <https://datatracker.ietf.org/doc/html/rfc1726> > > 5.5 <https://datatracker.ietf.org/doc/html/rfc1726#section-5.5> Transition > > CRITERION > The protocol must have a straightforward transition plan from the > current IPv4. > > DISCUSSION > A smooth, orderly, transition from IPv4 to IPng is needed. If we > can't transition to the new protocol, then no matter how wonderful > it is, we'll never get to it. > > We believe that it is not possible to have a "flag-day" form of > transition in which all hosts and routers must change over at > once. The size, complexity, and distributed administration of the > Internet make such a cutover impossible. > > Rather, IPng will need to co-exist with IPv4 for some period of > time. There are a number of ways to achieve this co-existence > such as requiring hosts to support two stacks, converting between > protocols, or using backward compatible extensions to IPv4. Each > scheme has its strengths and weaknesses, which have to be weighed. > > Furthermore, we note that, in all probability, there will be IPv4 > hosts on the Internet effectively forever. IPng must provide > mechanisms to allow these hosts to communicate, even after IPng > has become the dominant network layer protocol in the Internet. > > The absence of a rational and well-defined transition plan is not > acceptable. Indeed, the difficulty of running a network that is > transitioning from IPv4 to IPng must be minimized. (A good target > is that running a mixed IPv4-IPng network should be no more and > preferably less difficult than running IPv4 in parallel with > existing non-IP protocols). > > Furthermore, a network in transition must still be robust. IPng > schemes which maximize stability and connectivity in mixed IPv4- > IPng networks are preferred. > > Finally, IPng is expected to evolve over time and therefore, it > must be possible to have multiple versions of IPng, some in > production use, some in experimental, developmental, or evaluation > use, to coexist on the network. Transition plans must address > this issue. > > > Partridge and Kastenholz [Page 12] > > ------------------------------ > > RFC 1726 <https://datatracker.ietf.org/doc/html/rfc1726> IPng > Technical Criteria December 1994 > > > The transition plan must address the following general areas of > the Internet's infrastructure: > > Host Protocols and Software > Router Protocols and Software > Security and Authentication > Domain Name System > Network Management > Operations Tools (e.g., Ping and Traceroute) > Operations and Administration procedures > > The impact on protocols which use IP addresses as data (e.g., DNS, > distributed file systems, SNMP and FTP) must be specifically > addressed. > > The transition plan should address the issue of cost distribution. > That is, it should identify what tasks are required of the service > providers, of the end users, of the backbones and so on. > > Time Frame > A transition plan is required immediately. > > > === > >
