3 ms·

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

> 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.
- 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 ago
  v6 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.
iso1210 6y ago
I could set up an entirely ipv6 network on each of my devices and connect it with nat into IPv4, but crucially I want someone typing "ping 1.1.1.1" or opening a udp conenction to 92.42.35.61 port 5210 would just work, and I don't want to add much overhead (and wide deployment of dual stack is adding overhead) Imagine I have a mid sized ipv4 network comprising say 200 /24 subnets across multiple locations, all on 192.168.x.0/24, with 192.168.0.0/24 reserved for a vpls connecting them together (say ospf point-to-multipoint, other topologies are preferable of course). Default router to the internet on 192.168.0.1 (internal), which srcnats to a public IP addresses of 12.12.12.0/24, say 1 hide per subnet, advertised out as BGP to a couple of providers via some /30 links from their allocation. Now say I want to create a new client network. 1) Create a new subnet on 192.168.201.0/24 and put them all behind the new hide 12.12.12.201 I've done this 100+ times already, no problem, but it's rather legacy. 2) Create a new ipv6 network, with a 192.168.0.89/24 address which links to the other networks I could create a new ipv6 network, and reach servers on 192.168.12.1, or 192.168.51.8, as well as reaching the internet on ipv4. Traffic leaving the network would get srcnatted to 192.168.0.89. I then have a new http service I need to add, so I create a new ipv6 server network. This is reachable directly from the wifi clients as I have an ipv6 peering between the wifi client router and the ipv6 server router. For access from ipv4 subnets I can just put a destination nat on 192.168.0.89 port 80 to my new server, so it's reachable from all other ipv4 clients, but also from ipv6 clients directly. the server wouldn't need as it would see the ipv6 connection from the natting router (which maintains the state). I could also add a port forward from the public IPv4 address too. 3) Do both, and have twice the overhead as I have to manage both an IPv4 and IPv6 network. I'd rather not do that dual stack. After all what's the point in moving to ipv6 if you need to keep ipv4 running. It would be like using IP and IPX on the same network. My next step would be to add a public Ipv6 address peering. I put in ipv6 routing on my default router. Now my new server is reachable directly on ipv6 from my client ipv6 network, and the entire ipv6 internet It's also reachable from my older network on the internal 192.168 address range, and from the ipv4 internet on I don't have to have a dual stack on every device (including the server), just on 3 routers. I notice that some of my customers would like to connect via ipv6, so that's fine, I do an ipv6->ipv4 nat on my firewall for legacy services. With this setup, which doesn't need me to change 20,000 devices on 200 subnets simultaneously, or end up in a situation where I have 20,000 dual stack devices, I can start migrating to ipv6 without losing any existing ipv4 services. Eventually I will be left with just a handful of ipv4 subnets and a couple of routers running an ipv6/v4 natting gateway

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

iso1210 6y ago

I could set up an entirely ipv6 network on each of my devices and connect it with nat into IPv4, but crucially I want someone typing "ping 1.1.1.1" or opening a udp conenction to 92.42.35.61 port 5210 would just work, and I don't want to add much overhead (and wide deployment of dual stack is adding overhead) Imagine I have a mid sized ipv4 network comprising say 200 /24 subnets across multiple locations, all on 192.168.x.0/24, with 192.168.0.0/24 reserved for a vpls connecting them together (say ospf point-to-multipoint, other topologies are preferable of course). Default router to the internet on 192.168.0.1 (internal), which srcnats to a public IP addresses of 12.12.12.0/24, say 1 hide per subnet, advertised out as BGP to a couple of providers via some /30 links from their allocation. Now say I want to create a new client network. 1) Create a new subnet on 192.168.201.0/24 and put them all behind the new hide 12.12.12.201 I've done this 100+ times already, no problem, but it's rather legacy. 2) Create a new ipv6 network, with a 192.168.0.89/24 address which links to the other networks I could create a new ipv6 network, and reach servers on 192.168.12.1, or 192.168.51.8, as well as reaching the internet on ipv4. Traffic leaving the network would get srcnatted to 192.168.0.89. I then have a new http service I need to add, so I create a new ipv6 server network. This is reachable directly from the wifi clients as I have an ipv6 peering between the wifi client router and the ipv6 server router. For access from ipv4 subnets I can just put a destination nat on 192.168.0.89 port 80 to my new server, so it's reachable from all other ipv4 clients, but also from ipv6 clients directly. the server wouldn't need as it would see the ipv6 connection from the natting router (which maintains the state). I could also add a port forward from the public IPv4 address too. 3) Do both, and have twice the overhead as I have to manage both an IPv4 and IPv6 network. I'd rather not do that dual stack. After all what's the point in moving to ipv6 if you need to keep ipv4 running. It would be like using IP and IPX on the same network. My next step would be to add a public Ipv6 address peering. I put in ipv6 routing on my default router. Now my new server is reachable directly on ipv6 from my client ipv6 network, and the entire ipv6 internet It's also reachable from my older network on the internal 192.168 address range, and from the ipv4 internet on I don't have to have a dual stack on every device (including the server), just on 3 routers. I notice that some of my customers would like to connect via ipv6, so that's fine, I do an ipv6->ipv4 nat on my firewall for legacy services. With this setup, which doesn't need me to change 20,000 devices on 200 subnets simultaneously, or end up in a situation where I have 20,000 dual stack devices, I can start migrating to ipv6 without losing any existing ipv4 services. Eventually I will be left with just a handful of ipv4 subnets and a couple of routers running an ipv6/v4 natting gateway