I see the same thing from the other side, being a S/W developer for switching 
and routing boxes since the early 90's. The PM barrier is a high wall indeed. 
And yet some techs succeed to pass it. What I'm arguing is that we can pass 
that wall if we work together with the same objective. 

I've been monitoring this list for a while, very insightful, very happy with 
what I learn in the process. But here I feel compelled to react. I read that 
IPv6 did not succeed in 25 years. But unless I miss something, complaining did 
not succeed either, did it?

My frustration is that indeed (as a dev guy) we have been trying hard to serve 
users our best. We proposed a number of things in the IPv4 evolution direction 
that I see being asked on this list. For larger IPv4 space and smooth 
migration, I'm personally fond of the IP-in-IP variation that filed in 20+ 
years ago as US patent 7,356,031. Basically we reserve a /8, say, since it is 
so popular at this time, 240.0.0./8, and make it the "elevator shaft" between 
IPv4 realms. Say the current IPv4 Internet is realm 1, that Internet would have 
IP address 240.0.0.1/8 in the shaft, and would continue operating as is, 
without a change in hosts and routers for traffic staying inside the current 
Internet. Now say China builds realm 2; that Internet would have IP address 
240.0.0.2/8 in the shaft. A host in the Internet that wants to talk to a host 
in China would require an update to parse new DNS double-A (realm, address) 
records to encapsulate the packet IP-in-IP, outer src= 240.0.0.1 outer 
dest=240.0.0.2. The router that serves the shaft at level 1 attracts 
240.0.0.0/8 within realm 1 and routes up the elevator for more specific (host) 
routes within that prefix. The router that serves the shaft at level 2 attracts 
240.0.0.2/32 inside the shaft; upon the said packet it would swap the inner and 
outer destination and the packet would reach the Chinese address with classical 
routing within realm 2. Routers serving the shaft need an update, but then, 
only those do. Obviously the host in China can only reply if its stack is 
updated to understand the format. But all the other hosts and routers in China 
can be classical IPv4 as we know them long as their traffic stays in China. To 
migrate to IPv6 what you can do is map the elevator shaft prefix in, say, 
400::/3 (sadly cannot use F00/3 that would map 240 neatly but is already 
assigned). The current internet would own 400:1::/32, China would own 
400:2::/32, etc... You encode the double-A of the host in the prefix, reserve a 
well known suffix for IPv4 mapped double-A, and you have an IPv6 address that 
can be mapped both ways statelessly. When migrating to v6, each IPv4 node that 
owns a public IPv4 address in one realm gets a full IPv6 /64 for free.

This kind of ideas have existed for long but apparently did not meet their 
public. 

So we tried evolving IPv6 instead. And we did. I've witnessed deep evolution in 
networking technology with, e.g., IoT and SRv6. I've seen both being despised 
on this list and I'm not asking for more fuel on that fire. I just want to use 
these techs as a proof that evolution is indeed possible, that it happens in 
the context of IPv6, and that done in your direction it could make some folks 
happier than the current state of affairs. On the side, since I see the name, 
please consider that Cisco ships both techs above, so it is indeed capable of 
risk taking, the PM wall can indeed be passed, as long as there's enough 
pressure from both side.

For those interested, I'd be happy to chat on how IPv6 ND has evolved (on 
paper) but is stuck behind the PM wall as well.

Keep safe;

Pascal

Message-----
> From: NANOG <nanog-bounces+pthubert=cisco....@nanog.org> On Behalf Of
> Michael Thomas
> Sent: mardi 22 mars 2022 22:37
> To: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> 
> On 3/22/22 5:45 AM, Randy Bush wrote:
> > john,
> >
> > fwiw your story matches what is left of my memory.  one nuance
> >
> >> That’s not to say that there wasn’t "IETF politics” involved, but
> >> rather that such politics were expressed as enormous pressure to
> >> “make a decision”
> > my take was that cidr had done a lot to relieve the immediate
> > technical pressure for the short term; but there was a deep fear that
> > the industry press was stirring a major poolpah about the end of the
> > internet due to
> > ipv4 exhaustion.  i.e. a seriously flawed technical compromise was
> > pushed on us in reaction to a perception of bad press.
> >
> > i have learned that, when i am under great pressure to DO SOMETHING,
> > it's time to step back, go make a cup of tea, and think.  the ietf did
> > not.  and here we are, a quarter of a century later, still trying to
> > clean up the mess.
> >
> So are you saying that an ipng that came out in, say, 2000 which was
> according to you was vastly superior having taken the time to get it
> right would have had any better chance of being adopted? My experience
> with Cisco product managers at the time is that they couldn't give a
> shit about the technical aspects of an ipng. If their silicon forwarding
> couldn't handle it, they weren't interested unless customers were
> clamoring for it. I can't see how that negative feedback loop could have
> ever been prevented other than other ipng being done in, oh say, 1993
> when it was all still software forwarding.
> 
> Mike

Reply via email to