IPv6 woes - RFC

Thu Sep 16 09:46:33 UTC 2021

It's hard to argue that there was no transition plan.  There were in 
fact at least three transition plans for the selected approach (dual 
stack, 6to4, and tunneling) some of which have been discarded along the 
way; while others came to be based on operational experience.  Moreover, 
the only way to really know that a transition mechanism is really going 
to work is to let it out of the lab.  And ALL of the proposals would 
have suffered the very same transition pains, because just as Jeroen has 
pointed out, the pain stretched all the way to the application.

I don't think it's reasonable to argue that we should have waited for 
some other mythical better proposal to come along.  I don't recall 
anyone arguing for that at the time, and there's no reason to believe 
that such a mythical proposal would have ever come to be in any 
foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler 
and I argued the very opposite, that we were digging ourselves a hole 
with NAT.  Your argument at the time (Interop '95, Vegas) was that the 
IETF didn't have the right to dictate address usage to deployments.  
True enough, but then people shouldn't hang their woes on the IETF.

As I mentioned earlier, the fundamental issue was that there were no ng 
proposals that were in fact substitutable resources for v4, and NAT 
was.  From there, economics has ruled, arguments be damned.

Eliot

* I *did* in fact posit an approach in 1992 that would have allowed for 
orderly transition such that IPv4 could continue, and that was to define 
class E addresses as extension blocks that were in fact name space 
prefixes for another IPv4 header.  It wasn't taken seriously, and 
perhaps rightly so.  This actually borrowed a page from the PSTN - most 
people communicate locally and so you would rarely use those extended 
name spaces.  This was before Paul (Tsuchiya) Francis offered PIP, which 
had a notion of Landmark Routing that also went nowhere.

On 16.09.21 11:15, John Curran wrote:
> On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear at ofcourseimright.com 
> <mailto:lear at 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 fromIPv4 was simply acknowledged
>     and then declared as “resolved" becausewe 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
>
> ===
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/a7825765/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc
Type: application/pgp-keys
Size: 7386 bytes
Desc: OpenPGP public key
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/a7825765/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/a7825765/attachment.sig>