IPv6 woes - RFC

Michael Thomas mike at mtcc.com
Mon Sep 13 22:06:39 UTC 2021


On 9/13/21 11:22 AM, Randy Bush wrote:
> < rant >
>
> ipv6 was designed at a time where the internet futurists/idealists had
> disdain for operators and vendors, and thought we were evil money
> grabbers who had to be brought under control.
>
> the specs as originally RFCed by the ietf is very telling.  for your
> amusement, take a look at rfc 2450.  it took five years of war to get
> rid of the tla/sla crap.  and look at the /64 religion today[0].
>
> 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.
>
This is really easy to say in hindsight. 30 years ago it wasn't even 
vaguely a given that the Internet would even win and the size of the IP 
universe was still tiny. The main problem is that the internet was a 
classic success disaster where you're going as fast as possible and 
falling farther and farther behind. All of the gripes about particulars 
strike me as utterly irrelevant in the global scheme of things. As I 
mentioned, if they did nothing more than bolted on two more address 
bytes it still would have been just as impossible to get vendors and 
providers to care because everybody was heads down trying to deal with 
the success disaster. It's really easy to say that ipv6 suffers from 
second system syndrome -- which it does -- but that doesn't provide any 
concrete strategy for what would have been "better" in both getting 
vendors and providers to care. None of them wanted to do anything other 
than crank out kit that could be sold in the here and now that providers 
were willing to buy. That was certainly my experience at Cisco. As I 
said, the exec I talked to didn't actually want to do anything at all 
but was willing to let a couple of engineers navel gaze if it gave him 
something to talk about were the subject to actually come up with 
customers and a bludgeon against 3COM (iirc) at the time.

None of this is technical. It was which short term hack is going to keep 
the gravy train flowing? I was a developer at the time keeping an eye on 
the drafts as they were coming out. They didn't strike me was overly 
difficult to implement nor did they strike me as particularly 
overwrought. From a host standpoint, i didn't think it would take too 
much effort to get something up and running but I waited until somebody 
started asking for it. That never came. Nothing ever came. Then NAT's 
came and kicked the can down the roads some more. Now we have mega-yacht 
NAT's to kick it down the road even farther. Tell us what else would 
have prevented that?

Mike




More information about the NANOG mailing list