Re: IPv4 flag day

[John Curran via NANOG <nanog () lists nanog org>]

> On Jun 16, 2026, at 6:36 PM, Randy Bush via NANOG <nanog () lists nanog org> wrote:
>
> > Was there a backup plan for getting everyone to switch to IPv6,
>
> the plan from the ipv6 designers was dual-stack.  this was before ipv4
> run-out.  as dual-stack requires v4 space ~= v6 space, this plan was
> based on the assumption that the transition would be quick, before ipv4
> run-out.
>
> there was no backup plan.
>
> when the transition was not quick, 42 ingenious transition schemes
> arose, of varying quality.  some have stood the test of time.


Randy - 

You’re being a bit generous here, as the plan was actually to have “a rational and well-defined transition plan” –
that was clearly specified in the "Technical Criteria for Choosing IPng”  [RFC 1726] – but alas none of the proposals 
brought running code to the table…  

[see attached NANOG email from 5 years back on same topic - that seems to be the periodicity on this particular thread!]

There was a decision made that we had to quickly select a winner and proceed anyway, and that meant leaving the 
transition 
issue to be solved by a number of new IETF working groups… “dual stack” / ships-in-the-night was definitely not the 
adopted 
IPng recommendation (i.e. it was only after that transition work - which mostly focused on tunnels - completely crashed 
& burned that IETF then retreated to “dual-stack is the answer”…)

Luckily, those who had the need – the operator community – stepped up and made solutions happen…   Yes, some might
say far too many transition schemes, but then again, that’s understandable given the IETF decision to proceed with 
choosing 
the IP next generation protocol despite the lack of any actual transition architecture from day one.

Thanks, 
/John

p.s.  Disclaimers:  my words alone.  Also, I was a member of the IETF IPng Directorate (not establishing credentials, 
but 
        rather being complete with disclosing my complicity in the decision making that led to the IPv6 transition 
fiasco...)

> Begin forwarded message:
>
> From: John Curran <jcurran () istaff org>
> Subject: Re: IPv6 woes - RFC
> Date: September 16, 2021 at 5:15:13 AM EDT
> To: Eliot Lear <lear () ofcourseimright com>
> Cc: North American Network Operators' Group <nanog () nanog org>
>
> On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear () ofcourseimright com <mailto:lear () ofcourseimright com>> wrote:
> > ….
> > There is no evidence that any other design choices on the table at the time would have gotten us transitioned any 
> > faster, and a lot of evidence and analysis that the exact opposite is more likely.  
>
> Elliot - 
>
> If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially 
> true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome. 
>
> If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring 
> victory, then I’d strongly disagree.  I believe that we had the appropriate technical criteria for IPng (very nicely 
> compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard 
> those very criteria in order to “make a decision” & “move forward.”
>
> All of the IPng proposals where completely deficient with respect to transition capabilities.  In the rush to make a 
> IPng decision, the actual IPng Transition Criteria [1]  that mandated a straightforward transition plan from IPv4 was 
> simply acknowledged and then declared as “resolved" because we would also simultaneously form some working groups to 
> study all of the transition requirements and made good on the transition criteria via future 
> deliverables...(deliverables that were subsequently not delivered on)  
>
> The right answer would have been to formally and critically evaluate each of the candidate protocols against the 
> requirements and not make any selection until candidate presented itself that actually met the required technical 
> criteria.   Instead, IPv6 transition was left as an afterthought for the operator community to solve, and thus the 
> battles with the IETF on NAT-based transition for nearly two decades to get this basic technical requirement met.
>
> FYI,
> /John
>
> Disclaimer: my views alone - made from 100% recycled electrons. 
>
> ===  [1] The actual IPng Transition criteria (per RFC 1726) are as follows - 
>
> "
> 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).
> "
>
> In short:  
>
>   1) The protocol must have a straightforward transition plan 
>   2) A number of ways to achieve this which are to be explored
>   3) IPng must provide backward-compatibility to IPv4-only hosts
>   4) The absence of a well-defined transition plan is not acceptable
>
> ===

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/A6CSLMRKWYCPILBIIN5MDK6RMLZH7G7D/