3 ms·
There's plenty of room if the IPv4 header to extend it. The most significant bit of the IP protocol number field is mostly unused. The IP protocols that use it
by api 6y ago
There's plenty of room if the IPv4 header to extend it.
The most significant bit of the IP protocol number field is mostly unused. The IP protocols that use it could be safely deprecated on the open Internet.
Setting the MSB indicates a 64-bit address.
In 64-bit mode the source IP and destination IP fields in the V4 header become the most significant 32 bits of the source and destination IP. The least significant 32 bits of each are present in the options field, which contains enough room for both. In 64-bit mode any other use of the options field is deprecated. The bit index of these 32-bit chunks in the options field could be standardized to permit easy hardware decoding. The part of the options that indicate the option type and length could be present for backward compatibility with IP64-unaware routers but otherwise ignored.
Uglier than a clean slate design? Sure, a bit. But if this had been done, we'd already be using it everywhere and the problem would be solved.
TCP, UDP, and other IP protocols could remain almost entirely unchanged, though I imagine tables in software stacks would have to be extended to support 64 bits of address space. That's not a major change.
I just came up with that in 10 minutes while replying to this post. I assume it would take a committee several years to write the above spec.
The big "win" here is that existing IPv4 routers in the Internet's core infrastructure do not need to be upgraded all at once. They'd just lack the ability to understand anything beyond /32.
Honestly there are probably enough /32's to give one to every major endpoint, so I wonder if the core would even need to worry about it at all. I imagine that ISPs would hand out /32's to business customers (maybe for an additional fee), but once IP64 were widely deployed they'd probably hand out /48's to most subscribers. That would give you 65,535 "real" IP addresses for your house or small business. Mobile phones might get a /56, which would give them 256 IPs for tethering and permit cellular networks some additional IP space.
There are nice things about 128-bit addresses, but I am not sure they are worth adding 30+ years to the transition and having to lug around the hideous boat anchor that is NAT for an extra few decades.
- welterde 6y agoI think you will be surprised on how much stuff will break in mysterious ways. And that it will create a nightmare to actually operate. But even if we pretend it will just work there is the still the issue that IPv4-only hosts cannot talk to IPv4-NG hosts. There is no way around that. And having to upgrade the core is not really an issue (anymore). You are focusing on the wrong issue.
- jcranmer 6y ago> The big "win" here is that existing IPv4 routers in the Internet's core infrastructure do not need to be upgraded all at once. As I understand it, that is not the limiting factor in IPv6. Actually, I believe it was the second piece of the Internet's infrastructure to support IPv6 (the first part being OS networking support). Instead, the limiting factor is network management and middleware, in other words the edges and not the core of the Internet, that are holding back IPv6 adoption.
- Dagger2 6y agov6 already implements a similar scheme. You set the protocol field in the v4 packet to 41, and then put the v6 addresses at the beginning of the packet payload, with the original packet payload following afterwards. It doesn't seem to have helped as much as you're claiming.