3 ms·

IPv4 as deployed with NAT is more complex than IPv6. The most significant barriers to V6 adoption are, in this order: 1. It’s an entirely new network. IPv4 onl

by api 6y ago

IPv4 as deployed with NAT is more complex than IPv6. The most significant barriers to V6 adoption are, in this order: 1. It’s an entirely new network. IPv4 only hosts are not reachable on the IPv6 net. It replaces rather than extends IP, and I can’t figure out why they did that. 2. The addresses are too long to remember and easily type, and the encoding with its shortening rules is non-canonical and annoying to visually parse. Extending V4 to 64 bits on top of the V4 space would have been a much better idea for multiple reasons. Every V4 becomes a /32 in a full /64. Using something like base32 addresses could have been kept to just barely type-able length. People always push back on #2 with “use DNS.” I always wonder if these people have ever done IT or devops. You constantly type IPs in the real world and long V6 addresses are a huge annoyance.

ignoramous 6y ago
> Every V4 becomes a /32 in a full /64. IPv4-mapped IPv6? http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2....
jrockway 6y ago
I do a lot of devops and haven't typed an IP address in a while. I do a lot of comparisons, however, and comparing 128 bit numbers is slightly more difficult than 32 bit numbers. Overall, I stopped remembering IP address a long time ago. I wouldn't recognize "jrock.us" if you showed it to me. I kind of recognize my current external IPv4 address, but it could be off by a lot before I'd notice. I think, many years ago, I typed a lot of IP addresses, but don't anymore. I am personally fully-ready for IPv6, but understand that the world is not. (For example, my website was IPv6-accessible for many years, but changed providers and now it's not. I was a little sad about this, but it turns out nobody cares, so I didn't spend any time on it. Unfortunate, but someday it will work again, I'm sure.)
welterde 6y ago
> It’s an entirely new network. IPv4 only hosts are not reachable on the IPv6 net. It replaces rather than extends IP, and I can’t figure out why they did that. IPv6 cannot be an extension of IPv4 since IPv4 is not forward-compatible. It has nothing in it that would allow stuffing more address bits into it. And since you cannot encode more than 32bit in 32bit you will never be able to have a IPv4 successor that can just interoperate with IPv4 - you will always end up in exactly the same situation as IPv6 is right now. And if you just want to route your IPv4-ng over IPv4 in the core or something (which is what your idea is more or less). You can do that with IPv6 as well: Use 6in4 tunneling. But you are still at the same problem that a IPv4-only cannot communicate with an IPv4-ng-only host, since it is unaware of IPv4-ng.
- 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 ago
    I 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.

by api 6y ago

ignoramous 6y ago

> Every V4 becomes a /32 in a full /64. IPv4-mapped IPv6? http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2....

jrockway 6y ago

I do a lot of devops and haven't typed an IP address in a while. I do a lot of comparisons, however, and comparing 128 bit numbers is slightly more difficult than 32 bit numbers. Overall, I stopped remembering IP address a long time ago. I wouldn't recognize "jrock.us" if you showed it to me. I kind of recognize my current external IPv4 address, but it could be off by a lot before I'd notice. I think, many years ago, I typed a lot of IP addresses, but don't anymore. I am personally fully-ready for IPv6, but understand that the world is not. (For example, my website was IPv6-accessible for many years, but changed providers and now it's not. I was a little sad about this, but it turns out nobody cares, so I didn't spend any time on it. Unfortunate, but someday it will work again, I'm sure.)

welterde 6y ago

> It’s an entirely new network. IPv4 only hosts are not reachable on the IPv6 net. It replaces rather than extends IP, and I can’t figure out why they did that. IPv6 cannot be an extension of IPv4 since IPv4 is not forward-compatible. It has nothing in it that would allow stuffing more address bits into it. And since you cannot encode more than 32bit in 32bit you will never be able to have a IPv4 successor that can just interoperate with IPv4 - you will always end up in exactly the same situation as IPv6 is right now. And if you just want to route your IPv4-ng over IPv4 in the core or something (which is what your idea is more or less). You can do that with IPv6 as well: Use 6in4 tunneling. But you are still at the same problem that a IPv4-only cannot communicate with an IPv4-ng-only host, since it is unaware of IPv4-ng.

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 ago
  I 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.