Re: V6 still not supported

[Tom Beecher <beecher () beecher cc>]

> 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 <
mattlists () 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 <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