3 ms·

i'm envisioning more of a sort of ipvx, 64 bit addresses, encryption is non-optional and dos resistance is built-in.

by a-dub 4y ago

zamadatix 4y ago
It's mandatory to support in IPv6 so the only thing lacking in the general population's mind is a convincing enough reason for people to force it for every connection which will cause a lot of breakage due to the aforementioned middleboxes. But if you can convince that there's nothing about existing IPv6 implementation that would prevent it from working as described today. Switching to IPvX would be the same problem as convincing people to always encrypt with IPv6 just amplified as there is 0 hardware with existing support for such a protocol and IPv6 has had a 20 years head start on rollout that would be wiped away. It'd have the added "bonus" of being even harder to pitch adoption for since "NAT on IPv4 is working fine" and you'd still have to wait for those people THEN the IPv6 people to migrate. Meanwhile things like QUIC, HTTP/3, and TCPLS give all the same advantages as migrating to the hypothetical IPvX without breaking when they run into middleboxes. Just think of it as IPvX but with a wider header field than you were planning. After all you'll still need some header that tells the network where to deliver the packet then the encrypted payload it's just that that dumb destination header uses more bits than it needs to if it were designed fresh.
- a-dub 4y ago
  i think the big problem with ipv6 has been that there just hasn't been a compelling enough reason for most users to care. it's great for network operators and planners who worry about things like limited address space, but otherwise, it means nothing to end users other than more cumbersome addresses (and potentially slower routing table lookups). i think a major design goal of something like IPvX would be to eliminate the need for any firewalls, NATs or network partitions. everything would be hardened for the public internet, every datagram would be encrypted, every listening service would be ddos resistant and this would all be handled by the networking stack by default. crucially i think that there would have to be a hook to get end users to use it. i think there's a lot of room for next generation decentralized public internet identity, naming, reputation and commerce protocols. if these next generation services only lived on IPvX and made direct use of expanded address space, then maybe it would be compelling enough for an upgrade. of course there are concerns about replacing all the old networking hardware and the environmental impacts of such, so maybe that could be mitigated by exploiting planned sunsets and also mark a sunset for planned sunsets. spitballing is fun! :)

i'm envisioning more of a sort of ipvx, 64 bit addresses, encryption is non-optional and dos resistance is built-in.

by a-dub 4y ago

i'm envisioning more of a sort of ipvx, 64 bit addresses, encryption is non-optional and dos resistance is built-in.

It's mandatory to support in IPv6 so the only thing lacking in the general population's mind is a convincing enough reason for people to force it for every connection which will cause a lot of breakage due to the aforementioned middleboxes. But if you can convince that there's nothing about existing IPv6 implementation that would prevent it from working as described today. Switching to IPvX would be the same problem as convincing people to always encrypt with IPv6 just amplified as there is 0 hardware with existing support for such a protocol and IPv6 has had a 20 years head start on rollout that would be wiped away. It'd have the added "bonus" of being even harder to pitch adoption for since "NAT on IPv4 is working fine" and you'd still have to wait for those people THEN the IPv6 people to migrate. Meanwhile things like QUIC, HTTP/3, and TCPLS give all the same advantages as migrating to the hypothetical IPvX without breaking when they run into middleboxes. Just think of it as IPvX but with a wider header field than you were planning. After all you'll still need some header that tells the network where to deliver the packet then the encrypted payload it's just that that dumb destination header uses more bits than it needs to if it were designed fresh.

a-dub 4y ago
i think the big problem with ipv6 has been that there just hasn't been a compelling enough reason for most users to care. it's great for network operators and planners who worry about things like limited address space, but otherwise, it means nothing to end users other than more cumbersome addresses (and potentially slower routing table lookups). i think a major design goal of something like IPvX would be to eliminate the need for any firewalls, NATs or network partitions. everything would be hardened for the public internet, every datagram would be encrypted, every listening service would be ddos resistant and this would all be handled by the networking stack by default. crucially i think that there would have to be a hook to get end users to use it. i think there's a lot of room for next generation decentralized public internet identity, naming, reputation and commerce protocols. if these next generation services only lived on IPvX and made direct use of expanded address space, then maybe it would be compelling enough for an upgrade. of course there are concerns about replacing all the old networking hardware and the environmental impacts of such, so maybe that could be mitigated by exploiting planned sunsets and also mark a sunset for planned sunsets. spitballing is fun! :)