Re: Use of "ipv8" depricated some time back in '99 - Re: Comments on draft-thain-ipv8-01

Tom Beecher <[email protected]>
Newsgroups gmane.ietf.general
Message-ID <CAL9Qcx5B2=t-FFQd8OE-r5bYSx2L8+s3eaaFBt=2HMyhQAZ3nQ@mail.gmail.com>
>
> So if you MUST persist on this work, you will have to use ipv10.....


https://datatracker.ietf.org/doc/draft-omar-ipv10/12/

Someone tried going there already too.

However, there is zero appetite for a new version of IP.  These 'one
version to rule them all' ideas are unlikely to gain any traction at all
such that the assigned version number will ever matter.



On Sun, Apr 26, 2026 at 11:38 PM Robert Moskowitz <rgm-ietf=
[email protected]> wrote:

> Look for drafts around ipv8 back when.
>
> The concensus was ipv8 was so abused that that number was off limits.
>
> Which in part is why there is RFCs 1606 and 1607
>
> So if you MUST persist on this work, you will have to use ipv10.....
>
> Yes, I am a few weeks late....
>
> ;)
>
> On 4/16/26 9:41 AM, Andrew wrote:
> > This was sent to me by … maybe a half dozen people.
> >
> > Is this some sort April Fools joke?
> >
> > It seems like, by adopting this whole model, we would gain:
> > - Legacy applications can continue using IPv4 sockets (AF_INET and
> 32-bit address types) * but only if they use the system DNS resolver? *
> > - We can continue using dot-decimal notation instead of scary hex digits
> >
> > In exchange, we need to force everyone to adopt:
> > - new network stack in every OS
> > - new DNS resolver in the OS which can manage prefixes for legacy
> applications (which is architecturally incompatible how resolving works on
> Linux)
> > - significantly higher burdens on embedded devices to speak IP
> > - new incompatible firewalls
> > - new incompatible proxies
> > - new incompatible attributes for any protocol which transfers IP
> addresses
> > - new routing metric (which has not been used in any protocol before)
> > - new incompatible OSPF
> > - new incompatible IS-IS
> > - new BGP AFI
> > - new DNS record type
> > - new address space for IANA+RIRs to manage
> > - new access control protocol, which is unlike any protocol we have seen
> before
> > - force the use of DHCP again, even though we finally have almost gotten
> rid of it
> >
> > Compared to IPv6, even if fully implemented into every OS and client and
> router, the proposed protocol would still lack sufficient address space -
> if each ASN has one 32 bit address space, then an ISP who currently has a
> v6 /20 would not have enough space to give customers more than a single
> address, so we are back to NAT again. It doesn’t look like any sort of
> prefix delegation is used for customer networks, so I guess it’s back to
> NAT again anyway?
> >
> > How quickly can we reject this?
> >
> > Andrew
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.