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

Thu Mar 24 13:01:58 UTC 2022

On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f at 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/ <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 <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 <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.

===
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220324/8cebbf6a/attachment.html>