Re: A straightforward transition plan (was: Re: V6 still not supported)

[John Curran <jcurran () istaff org>]

Noah -

It was assumed that IPng would include a standard straightforward technological solution to support communication with 
IPv4 hosts – this was a defined hard requirement. 

This transition mechanism wasn’t available at the time of the selection of IPng, and instead was left as a future 
deliverable.  The future deliverable was then abandoned, leaving transition mechanisms as an area where service 
providers had to fill in the gaps years later through their own efforts. 

The failure to deliver on a standard interoperability method to existing IPv4 hosts (something that major ISPs now 
commonly do today but only after a decade or so of their own work)  is precisely why all early plans and assumptions 
about IPv6 deployment became moot. 

Your questions about IPv6 deployment assumptions is a question about assumptions that were known to be invalid the 
moment that we choose a new IP protocol that lacked the required interoperability. 

Thanks,
/John

p.s. Disclaimer: my views alone - objects in the past may be larger than they actually appear. 

> On Jan 11, 2023, at 6:11 PM, Noah <noah () neo co tz> wrote:
>
> 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 <jcurran () istaff org <mailto:jcurran () istaff org>> wrote:
> > On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f () november emu st <mailto:k3f () 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] 
> > <https://datatracker.ietf.org/doc/html/rfc1752%5D> 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.
> >
> > ===