RE: V6 still not supported

["Pascal Thubert \(pthubert\) via NANOG" <nanog () nanog org>]

OK so you really did not read my post, even now. The tech I described was pure v4. It would pass your gateway.
The only we can talk is that we listen to each other... Quoting the text so you do not need to look it up:

"
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.
"

Now what?

Pascal


> -----Original Message-----
> From: NANOG <nanog-bounces+pthubert=cisco.com () nanog org> On Behalf Of Mark
> Delany
> Sent: jeudi 24 mars 2022 12:45
> To: nanog () nanog org
> Subject: Re: V6 still not supported
>
> On 24Mar22, Pascal Thubert (pthubert) allegedly wrote:
> > Hello Mark:
> >
> > > Any such "transition plan" whether "working" or "straightforward" is
> > > logically impossible. Why anyone thinks such a mythical plan might
> > > yet be formulated some 20+ years after deploying any of ipv6, ipv4++
> > > or ipv6-lite is absurd.
> >
> > This is dishonest
>
> My point is that if there was a real transition plan it would have been
> invented and executed by now and we'd all be on ipv6. Yet the reality is that
> here we are some 20 years later with no plan and no ubiquitous ipv6. How is
> that observation dishonest?
>
> > considering that I just proved on this very thread that such ideas
> > existed
>
> I don't know why you're conflating an idea with a plan - they are about as
> far away from each other as is possible. Frankly no one cares about ideas,
> they're a dime a dozen.
>
> A plan is an actionable, compelling and logical set of steps towards an end
> result. Do you have such a thing for moving everyone on the planet to ipv6?
>
> Here's a simple test of whether you have a plan or not. I'm connected via my
> legacy ipv4 ISP router completely oblivous to ipv6. How does your plan
> incentivise me to upgrade my router to support ipv6?
>
> When you have an answer to that, you might have a glimmer of a plan.
>
>
> Mark.