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] 
<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.

===

Reply via email to