> > 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. >
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!!! On Sat, Mar 19, 2022 at 6:45 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). > > 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 <mattli...@rivervalleyinternet.net> > >> To: Joe Maimon <jmai...@jmaimon.com>, b...@theworld.com, > >> Tom Beecher <beec...@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 > >>> > >>> > > >