After a time of transition, all clients would be running 128 bit
addresses (or whatever length was determined to be helpful).

Just like with IPv6, there would be a transition period, but during that
time software updates would very easily bring equipment up to spec much
faster and quicker.

Eventually, 192.168.0.1 would be represented (for example) as
0.0.0.0.192.168.0.1 (or something similar - I haven't really sketched
out the logistics on paper).

So, while it's true that a 192.168.0.1 computer couldn't connect to a
43.23.0.0.12.168.0.1 computer, without a software patch - that patch
would be very simple and quick to deploy.   The number is the same, it
simply expands to it (somewhat like an area code split).

It would also be extremely easy to perform a translation operations on
equipment that required it for some reason since we're still operating
in the same basic IPv4 dotted notation system.

A computer running at 32.23.0.0.12.168.0.1 wants to access 192.168.0.1.
It has no problem sending out the request, since 192.168.0.1 is a subset
of the protocol 32.23.0.x has.  However, to get back 192.168.0.1 can
proxy through an IPv4.1 to IPv4.2 concentration system.   This very
quickly allows for rapid deployment and upgrading.

I suspect if such a system was implemented the uptake would be very very
fast.

IPv6 deployment is been so slow because it was not carefully thought
through from an ISP deployment perspective.  (For example, how the
DHCPv6 request doesn't send the device MAC address through, thus
preventing the ISP from being able to authorize the device or hand out a
specific IP range).  Yes, this can be gotten around, but you have to
have a device which can intercept the traffic, forward it, and direct
the DHCPv6.   This shouldn't be necessary.  The IPv6 protocol  took
something that worked (but had limited resources) and broke it while a
bunch of engineers sat around a table talking.

It's time we stopped trying to advance a broken cart, and simply fix the
existing, working horse and cart that we have through a very simple
extension process.

Heck, even allowing hex in the dotted quad would resolve a lot of issue.
  The issue with IPv6 is NOT the hex.  It's the way things were
implemented within the protocol stack.

On 3/18/22 3:44 PM, Owen DeLong via NANOG wrote:
>
>> What I would LOVE to see that someone will pop in with new IP protocol
>> that is much more similar to IPv4, just extends address space and fixes
>> some well know issues. (for example remove netmask and use prefixlen/CIDR).
>
> 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.
>
>> Other importand aspect is some kind of IPvX -> IPv4 interop, so you can
>> quickly put clients into new protocol and they have access to entire IPv4
>> internet out of the box.
>
> 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.
>
>> Also, we need to please enterprises so we need largish RFC1918 space too.
>
> 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.
>
>> Just my 2 cents again ;)
>
> I think you have over-valued it.
>
> Owen
>
>>
>>
>> ---------- Original message ----------
>>
>> From: Matt Hoppes <mattlists@rivervalleyinternet.net>
>> To: Joe Maimon <jmaimon@jmaimon.com>, bzs@theworld.com,
>>     Tom Beecher <beecher@beecher.cc>
>> Cc: NANOG <nanog@nanog.org>
>> Subject: Re: V6 still not supported
>> Date: Thu, 17 Mar 2022 23:34:19 -0500
>>
>> At this point I would *love* to see IPv4 get extended, a software patch applied
>> to devices, and IPv6 die a quick painless death.
>>
>>>
>>> Its not impossible to envision that IPv4 does not ever go away but actually
>>> gets extended in such a way that it obsoletes IPv6. The longer this drags out
>>> the less implausible it seems.
>>>
>>> Joe
>>>
>>>
>