IPv6 woes - RFC

Thu Sep 16 12:10:20 UTC 2021

On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear at ofcourseimright.com> wrote:
> 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.

Eliot -

The requirement was not for the assertion of multiple “transition plans”, but rather "The protocol must have a straightforward transition plan from the current IPv4.”

"A straightforward plan” – singular.  If you have a link to that plan, please provide it, but until such time I’ll stay with my understanding of events (that being that we completely dropped the ball with regard to providing the operator community with a meaningful transition plan.)
> 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.
> 
Sorry, I was on the IPng Directorate, and there were indeed arguments that we lacked meaningful transition strategy, and that the fig leaf of shipping the responsibility off to “to-be-defined” working groups was irresponsible.
> 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.
> 
As predicted - "As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices.  In order to meet the requirement for “viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred.”

Sorry, but as the sole “network operator” on the IPng Directorate who lived through thru convenient papering over of the transition requirement firsthand, I’ll have to concur with Randy Bush’s take on this one -

>> "real compatibility with ipv4 was disdained.  the transition plan was dual stack and v4 would go away in a handful of years.  the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space."
>> 
>> we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially.”

Anyone who wants to argue that IPng had a viable transition plan best put a hard link to the documented plan in their reply - trying to argue the point without actually citing the alleged  “straightforward plan" is just embarrassing.

Thanks,
/John

p.s.  Disclaimer: my views alone (although likely shared by many operators upon hearing silence in response to the question:  “Okay, how is this transition really supposed to work?”)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/95b5f5af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/95b5f5af/attachment.sig>