V6 still not supported

Sun Mar 20 10:17:28 UTC 2022

I know its the same, but from UX standpoints looks different.
Anyway, that was just one example.

As for IPv6 -> IPv4 (note the arrow) its pretty much easy.
IPv6 have much bigger address space, so it can embed IPv4 addresses
in special interop subnets that are routed to special NAT GW
that handle IPv6 -> IPv4 translation. Thats right, its one way.
IPv4 -> IPv6 is pretty much impossible. But do we need one?
Todays internet is centralized, a lot of traffic goes into cloud, not 
between users. Also, transition is not 0 -> 1, its gradual. Same about 
users. Some even dont really understand what they are using, happy that 
netflix or facebook opens. There are of course power users, so they will
go different transition path. Dont put everyone into same bucket.

As for content providers (servers) they can stay for IPv4 for a while,
become dual stack or even (once a traffic level shifts) provide
IPv4 -> IPv6 balancers to handle leftovers of IPv4 traffic.

Also, not all services can work via proxying/balacing. Some services
needs to be dual stack from the start.

As for RFC1918, because why not? Why are you forcing me to run my networks
your way? Its mine network and I want to set it up the way I see fit.
Not everyone is going to ask RIPE/LIR was address space for his small 
network. Isnt that too much burden?

---------- Original message ----------

From: Owen DeLong <owen at delong.com>
To: borg at uu3.net
Cc: nanog at nanog.org
Subject: Re: V6 still not supported
Date: Fri, 18 Mar 2022 13:44:13 -0700

This shows a fundamental lack of understanding˙˙ Netmask and Prefixlen/CIDR are just
Different ways of representing the exact same thing. While it˙˙s true that prior to CIDR, one
COULD implement discontiguous net masks, this was rare in actual practice and had no
real use, so nothing was lost in eliminating that capability.

Internal to the operating system, regardless of whether presentation is as a CIDR length
or a netmask, it˙˙s still stored and compared against addresses as a bitfield.

Client A has a 128 bit address.
Client B has a 32 bit address and does not understand packets with 128-bit addresses.

Please explain how these two clients interoperate.

That is literally what you are asking for here. Math says it doesn˙˙t work.

Why? Why does RFC-1918 space need to exist at all? Why not simply use transparent addressing and stop mutilating packet headers?

However, if you really think this is important, I will refer you to what is called ULA in IPv6. It˙˙s pretty much all the same problems of RFC1918 minus the high probability of collision when merging two networks.

I think you have over-valued it.

Owen