<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, while it's true that a 192.168.0.1 computer couldn't connect to a<br>43.23.0.0.12.168.0.1 computer, without a software patch - that patch<br>would be very simple and quick to deploy. <br></blockquote><div><br></div><div>Software patches are never simple and quick to deploy. In fact, a common argument from people who don't want to use v6 is that software patches are too much work!!!</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 19, 2022 at 6:45 PM Matt Hoppes <<a href="mailto:mattlists@rivervalleyinternet.net">mattlists@rivervalleyinternet.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">After a time of transition, all clients would be running 128 bit <br>
addresses (or whatever length was determined to be helpful).<br>
<br>
Just like with IPv6, there would be a transition period, but during that <br>
time software updates would very easily bring equipment up to spec much <br>
faster and quicker.<br>
<br>
Eventually, 192.168.0.1 would be represented (for example) as <br>
0.0.0.0.192.168.0.1 (or something similar - I haven't really sketched <br>
out the logistics on paper).<br>
<br>
So, while it's true that a 192.168.0.1 computer couldn't connect to a <br>
43.23.0.0.12.168.0.1 computer, without a software patch - that patch <br>
would be very simple and quick to deploy.   The number is the same, it <br>
simply expands to it (somewhat like an area code split).<br>
<br>
It would also be extremely easy to perform a translation operations on <br>
equipment that required it for some reason since we're still operating <br>
in the same basic IPv4 dotted notation system.<br>
<br>
A computer running at 32.23.0.0.12.168.0.1 wants to access 192.168.0.1. <br>
It has no problem sending out the request, since 192.168.0.1 is a subset <br>
of the protocol 32.23.0.x has.  However, to get back 192.168.0.1 can <br>
proxy through an IPv4.1 to IPv4.2 concentration system.   This very <br>
quickly allows for rapid deployment and upgrading.<br>
<br>
I suspect if such a system was implemented the uptake would be very very <br>
fast.<br>
<br>
IPv6 deployment is been so slow because it was not carefully thought <br>
through from an ISP deployment perspective.  (For example, how the <br>
DHCPv6 request doesn't send the device MAC address through, thus <br>
preventing the ISP from being able to authorize the device or hand out a <br>
specific IP range).  Yes, this can be gotten around, but you have to <br>
have a device which can intercept the traffic, forward it, and direct <br>
the DHCPv6.   This shouldn't be necessary.  The IPv6 protocol  took <br>
something that worked (but had limited resources) and broke it while a <br>
bunch of engineers sat around a table talking.<br>
<br>
It's time we stopped trying to advance a broken cart, and simply fix the <br>
existing, working horse and cart that we have through a very simple <br>
extension process.<br>
<br>
Heck, even allowing hex in the dotted quad would resolve a lot of issue. <br>
  The issue with IPv6 is NOT the hex.  It's the way things were <br>
implemented within the protocol stack.<br>
<br>
On 3/18/22 3:44 PM, Owen DeLong via NANOG wrote:<br>
> <br>
>> What I would LOVE to see that someone will pop in with new IP protocol<br>
>> that is much more similar to IPv4, just extends address space and fixes<br>
>> some well know issues. (for example remove netmask and use prefixlen/CIDR).<br>
> <br>
> This shows a fundamental lack of understanding… Netmask and Prefixlen/CIDR are just<br>
> Different ways of representing the exact same thing. While it’s true that prior to CIDR, one<br>
> COULD implement discontiguous net masks, this was rare in actual practice and had no<br>
> real use, so nothing was lost in eliminating that capability.<br>
> <br>
> Internal to the operating system, regardless of whether presentation is as a CIDR length<br>
> or a netmask, it’s still stored and compared against addresses as a bitfield.<br>
> <br>
>> Other importand aspect is some kind of IPvX -> IPv4 interop, so you can<br>
>> quickly put clients into new protocol and they have access to entire IPv4<br>
>> internet out of the box.<br>
> <br>
> Client A has a 128 bit address.<br>
> Client B has a 32 bit address and does not understand packets with 128-bit addresses.<br>
> <br>
> Please explain how these two clients interoperate.<br>
> <br>
> That is literally what you are asking for here. Math says it doesn’t work.<br>
> <br>
>> Also, we need to please enterprises so we need largish RFC1918 space too.<br>
> <br>
> Why? Why does RFC-1918 space need to exist at all? Why not simply use transparent addressing and stop mutilating packet headers?<br>
> <br>
> 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.<br>
> <br>
>> Just my 2 cents again ;)<br>
> <br>
> I think you have over-valued it.<br>
> <br>
> Owen<br>
> <br>
>><br>
>><br>
>> ---------- Original message ----------<br>
>><br>
>> From: Matt Hoppes <<a href="mailto:mattlists@rivervalleyinternet.net" target="_blank">mattlists@rivervalleyinternet.net</a>><br>
>> To: Joe Maimon <<a href="mailto:jmaimon@jmaimon.com" target="_blank">jmaimon@jmaimon.com</a>>, <a href="mailto:bzs@theworld.com" target="_blank">bzs@theworld.com</a>,<br>
>>     Tom Beecher <<a href="mailto:beecher@beecher.cc" target="_blank">beecher@beecher.cc</a>><br>
>> Cc: NANOG <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
>> Subject: Re: V6 still not supported<br>
>> Date: Thu, 17 Mar 2022 23:34:19 -0500<br>
>><br>
>> At this point I would *love* to see IPv4 get extended, a software patch applied<br>
>> to devices, and IPv6 die a quick painless death.<br>
>><br>
>>><br>
>>> Its not impossible to envision that IPv4 does not ever go away but actually<br>
>>> gets extended in such a way that it obsoletes IPv6. The longer this drags out<br>
>>> the less implausible it seems.<br>
>>><br>
>>> Joe<br>
>>><br>
>>><br>
> <br>
</blockquote></div>