You know that's not what he meant. the world is always changing. it was designed in 1998 by networking gear companies, with their own company needs in mind. It wasn't engineered with end user, or even network administrators and app developers in mind.
The only reason it's around is because of sunken cost fallacy and people stuck in decades old tech-debt. A new protocol designed today will be different, much the same as how Rust is different than Ada. SD-WAN wasn't a thing in 1998, the cost of chips and the demand of mobile customers wasn't a thing. supply/demand economics have changed the very requirments behind the protocol.
Even concepts like source and destination addressing should be re-thought. The very concept of a network layer protocol that doesn't incorporate 0RTT encryption by default is ridiculous in 2026. Even protocols like ND, ARP, RA, DHCP and many more are insecure by default. Why is my device just trusting random claims that a neighbor has a specific address without authentication? Why is it connecting to a network (any! wired,wireless, why does it matter, this is a network layer concern) without authenticating the network's security and identity authority? I despise the corporatized term "zero trust" but this is what it means more or less.
People don't talk about security, trust, identity and more, because ipv6 was designed to save networking gear vendors money, and any new costly features better come with revenue streams like SD-WAN hosting by those same companies. There are lots and lots of new things a new layer-3 protocol could bring to the scene. But security aside, the main thing would be replacing numbered addressing with identity-based addressing.
It all comes down to how much money it costs the participants of the RFC committees. given how dependent the world is on this tech, I'm hoping governments intervene. It's sad that this is the tech we're passing to future generations. We'll be setting up colonies on mars, and troubleshooting addressing and security issues like it's 2005.
>There are lots and lots of new things a new layer-3 protocol could bring to the scene. But security aside, the main thing would be replacing numbered addressing with identity-based addressing
I don't know much about MPLS and only know IP routing, but that quote above sounds very hand-waving. How do you route "identity based addressing"?
Not to mention authenticated identity-based routing would mean embedding trusted centralized authorities into even deeper network layers. That is such a mess for TLS, after CAs started going rogue we've basically ended up with Google, a shitty ad company, deciding who should be trusted because they control Chrome.
Not at all, it doesn't even need to be PKI. But if it was, your routers would be the CA. Or more practically, whatever device is responsible for addressing, also responsible as the authority over those addresses. Your DHCP server would also be the CA for your LAN. Even a simple ND/ARP would require a claim (something like a short byte value end-devices can lookup/cache) that allows it to make that "the address x.x.x.x is at <mac>" statement. Smarter schemes might allow the network forwarder (router) to translate claims to avoid end devices looking up and caching lots of claims locally (and it would need to be authorized to do so).
You wouldn't need TLS. this scheme i just thought would actually decentralize/federate PKI a lot more. If you have a public address assigned, your ISP is the IP-CA. I don't want to get into the details of my DNS replacement idea, but similar to network operators being authorities over the addresses they're responsible for, whoever issued you a network name is also the identity authority over that name (so DNS registrars would be CA's). Ideally though, every device would be named, and the people that have logical control over the address will also be responsible for the name and all identity authentication and claims over those addresses and names. You won't have freaking google and browsers dictating which CA root to trust, it will instead be the network you're joining that does that (be it your DHCP server, or your ISP is up for debate, but I prefer the former). Ideally, your public key hash is your address. How others reach you would be by resolving your public key from your identity, the traffic will be sent to your public key (or see my sibling comment for the concept of cryptographic identity). All names would of course be free, but what we call "DNS" today will survive as an alias to those proper names. so your device might be guelo.lan123.yourisp.country but a registrar might sell you a guelo.com alias that points to the former name.
The implications of this scheme are wild, think about it!
Rogue trust providers will be a problem, but only to their domain. right now random CA roots can issue domains for anything. with the scheme I proposed, your country can mess with its own traffic, as can your isp, as can you over your lan. You won't be able to spoof traffic for a different lan, or isp using their name.
It wouldn't be a good idea to spell out an entire protocol in a comment section, but the key part is that it would cost a lot.
It is far from hand-waving. Right now we have numeric addressing, where routers look at bits and perform ASIC-friendly bitwise (and other) operations on that number to forward a lot of traffic really fast for cheap.
Identity and trust establishment won't be part of the regular data flow, but at network connection time, each end-device will discover the network authority it has connected to, and build trust that allows it to validate identities in that network, including address assignments, neighbor discovery, name resolution and verification, authorized traffic forwarders (routers) and more.
After the connection is established and the network is trusted, as part of the connection establishment, the network authority designates how addressing should be done. If Alice's Iphone wants to connect to Bob's server, it will encrypt the data, and as part of a very slim header designate Bob's server's cryptographic identifier, destination service identifier, and its own cryptographic identifier for the first packet. To reduce overhead, subsequent traffic can use a simple hash of the connection identifers mentioned earlier.
When devices come online in the network, their cryptographic identifers will become known to the entire network, including intermediate routers. Routing protocols work with the identity authority of the network to build forwarding tables based on cryptographic identifiers, and for established sessions, session ids.
"Cryptographic identifier" is also not a hand-wavy term. what it means must be dynamic, so as to avoid protocol updates like v4 and v6 over addressing. V6 presumed just having lots of bits is enough. An ideal protocol will allow the network itself to communicate the identifier type and byte-size. For example an FQDN, or an IPv4 address alike could be used directly, or a public key hash using a hash algorithm of the network's choice can be used. So long as the devices in the network support it, and the end device supports it, it should work fine.
Internet addressing can use a scheme like this, but it doesn't need to. IPv6 took the wrong approach with NAT, it got rid of it instead of formalizing it. we'll always need to translate addresses. But the internet is actually well-positioned for this, due to the prevalence of certificate authorities, but it will require rethinking foundational protocols like DNS, BGP, and PKI infrastructure.
But my original point wasn't this, it was that tech has come far, our requirements today are different than 30 years ago. Even the OSI layered model is outdated, among other things.
This is just my proposal that I just thought of as I'm typing this, smarter people that can sit down and think through the problem can think of better protocols. I only proposed it to demnostrate the concept isn't hand-wavy or ridiculous.
IPv6 was relatively rushed to meet the address shortage issue of IPv4 while at the same time solve lots of other problems. The next network layer protocol (and we do need one) should have the goal of making networking as a whole adaptable to new and unforeseen requirements (that's why I suggested the network authority be the one to dictate the addressing scheme, and with it, be responsible for translating it if needed). We're being held back, not just in tech but as a species, because of this short-sighted protocol design! exaggerated as that statement might sound, it is true.
I'll reserve further discussion on the topic for when it is required, but I hope this prevents more dismissive responses.
> it was designed in 1998 by networking gear companies
That's false. Firstly, rfc1883 was published in 1995 which means work started some time before that, and the RFC process included operating system vendors and RIR administrators. The primary author of rfc1883 worked at Xerox Parc, and the primary author of rfc1885 worked at DEC. Neither were networking gear companies.
No, I think proposed, draft and internet standard all have specific meanings we don't need to debate over. Your claim that IPv6 was first proposed in 1995 is correct, as is my claim that it was first accepted in 1998. No one actually uses a proposed standard, but when it is draft people start implementing it and giving feedback over issues until it is fully ratified is my understanding (correct me if that's wrong please).
The only reason it's around is because of sunken cost fallacy and people stuck in decades old tech-debt. A new protocol designed today will be different, much the same as how Rust is different than Ada. SD-WAN wasn't a thing in 1998, the cost of chips and the demand of mobile customers wasn't a thing. supply/demand economics have changed the very requirments behind the protocol.
Even concepts like source and destination addressing should be re-thought. The very concept of a network layer protocol that doesn't incorporate 0RTT encryption by default is ridiculous in 2026. Even protocols like ND, ARP, RA, DHCP and many more are insecure by default. Why is my device just trusting random claims that a neighbor has a specific address without authentication? Why is it connecting to a network (any! wired,wireless, why does it matter, this is a network layer concern) without authenticating the network's security and identity authority? I despise the corporatized term "zero trust" but this is what it means more or less.
People don't talk about security, trust, identity and more, because ipv6 was designed to save networking gear vendors money, and any new costly features better come with revenue streams like SD-WAN hosting by those same companies. There are lots and lots of new things a new layer-3 protocol could bring to the scene. But security aside, the main thing would be replacing numbered addressing with identity-based addressing.
It all comes down to how much money it costs the participants of the RFC committees. given how dependent the world is on this tech, I'm hoping governments intervene. It's sad that this is the tech we're passing to future generations. We'll be setting up colonies on mars, and troubleshooting addressing and security issues like it's 2005.