----- On Mar 19, 2022, at 6:44 PM, Matt Hoppes
mattli...@rivervalleyinternet.net wrote:
> After a time of transition, all clients would be running 128 bit
> addresses (or whatever length was determined to be helpful).
What you describe is literally IPv6.
> 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.
If it is so easy, then why is some software not yet supporting IPv6? What makes
you think that lazy software developers would suddenly become interested in
this new IP when they don't seem interested in the current standard?
I don't get what you are trying to accomplish here that is not already covered
by IPv6.
>
> 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.
No, it wouldn't. You have a fundamental misunderstanding about how IP addresses
work. Nothing stores IP addresses in the classic (and horrible) IPv4-style
dotted notation. IPs are stored as binary numbers, be they 32-bit, or 128-bit.
The way they are displayed are just a shorthand to make reading them easier
(although, the variable character length of IPv4 is really annoying, but is
fixed in IPv6)
> 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.
Again, you are basically talking about IPv6. I am still missing where you have
some way to accomplish the same goal without having every system have to be
re-written (again). Why would we want to start again at 0% when we are a
significant portion of the way to full IPv6 deployment?
> 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).
As others have said, this has been fixed. I do agree that leaving out DHCP was
shortsighted. But it was relatively easily added (just like it was for IPv4).
Just because the current implementation and best practice for a protocol
doesn't meet a specific need of yours doesn't mean we should go back to the
drawing board and re-implement the entire networking stack again.
>
> 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.
As above, I will point out that you seem to have a misunderstanding of what
IPv6 is and is not. Hex vs. dotted quad is merely a display standard having
nothing to do with anything that really matters (router code, etc). What you
seem to be proposing is just a different way to represent 128-bit addresses,
which would make them difficult to distinguish from 32-bit addresses. These
issues have long been worked out by many very smart people.
-Randy
