Re: Comments on draft-thain-ipv8-01

I unironically think that if this was the original proposal from v4 -> 
v8, (instead of v6) i.e. keep the "dot separated octet" notation, it 
would be much more widely adopted today.

- Raghu Saxena

On 4/16/2026 9:41 PM, 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
>