"Because it works now" is a perfectly good reason, I was more talking about a hypothetical "wave a wand and change all devices overnight" scenario.
I think an IPv8(Apparently we skip odd numbers) could be a real practical thing one day though, because a lot of things really do with quite work that well. The classic "it's always DNS" meme seems to be very real, tying TLS to domains instead of IPs impedes anything on LAN, IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
Insecure DNS doesn't need to exist outside of MDNS, and even MDNS could at least have pairing prompts, if all records are signed and everything is secured at the IP level(Embedding key hashes in the IP), then certificate authorities don't need to exist either.
MACs don't really need to be a thing either outside industrial niche stuff, if we mostly just do IP traffic, that extra framing and the lookup/translation layer can go away.
Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.
> tying TLS to domains instead of IPs impedes anything on LAN,
TLS doesn't care what's in the certs, that's an application concern. IP addresses work fine in x.509 certs, but are discouraged because of difficulty of validating that control of the IP will continue through the certificate validity period. But this wouldn't much help for your LAN use case, assuing you're using RFC1918 addresses, because no one can prove control of those, so no publicly trusted CA should issue certs for them. Same thing if you use ipv6 link local, although I don't know too many people typing those addresses, mostly people want to type in a ___domain name, and if you make a real one work (which is doable), you can use a real cert; if not, not.
> IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
DeviceChosenID that is the same everywhere is kind of a huge privacy thing that we already had and mostly rejected. Giving every ISP the same number of bits is silly anyway; Comcast needs more bits than [ISP that only serves California], and heirachical addressing is lovely for humans, but not necessarily a great way to manage networks; each regional portion of the network is going to end up doing its own BGP anyway, at which point, the heirarchy doesn't make a huge difference.
> Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.
Source routing exists in RFCs but was quickly dropped. There's a lot of security reasons, but also it just doesn't work that well. The destination is needed to make the best routing decisions.
Say you're in Chicago, sending to me near Seattle, and our ISPs peer in Virginia and Los Angeles (which is a bit contrived, but eh). If you send to the nearest peering, traffic will go east to Virginia, then west to Seattle. If you look up by destination, you'll more likely go west to LA, then north to Seattle and total distance will be much less.
You can prove control of an IP address if they were longer, and the DeviceGeneratedUniquePart was a hash of the certificate.
If you need to renew, you just get a new IP and tell DNS about it, if you're using fixed IPs and can't easily renew without manual work, you're still better off than no encryption.
Instead of proving control of a ___domain, you'd be proving that an IP is one of the correct ones for a ___domain.
Tech is advanced enough now that we don't need to conserve every single bit. What you lose in efficiency, you gain in easily being able to tell what part of the IP corresponds to one customer for antiDDOS ratelimiting and the like.
Source routing would probably be best as an optional feature. But if you had a hierarchy with a part explicitly tied to the region, you could source route to the county level at least or even data center level without needing to reveal the exact destination.
I think an IPv8(Apparently we skip odd numbers) could be a real practical thing one day though, because a lot of things really do with quite work that well. The classic "it's always DNS" meme seems to be very real, tying TLS to domains instead of IPs impedes anything on LAN, IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
Insecure DNS doesn't need to exist outside of MDNS, and even MDNS could at least have pairing prompts, if all records are signed and everything is secured at the IP level(Embedding key hashes in the IP), then certificate authorities don't need to exist either.
MACs don't really need to be a thing either outside industrial niche stuff, if we mostly just do IP traffic, that extra framing and the lookup/translation layer can go away.
Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.