3 ms·

It's pretty simple. If IPv6 headers were split into two parts, where the first part was the same as IPv4, and the second part had the rest of the bits, so you

It's pretty simple. If IPv6 headers were split into two parts, where the first part was the same as IPv4, and the second part had the rest of the bits, so you had say 8 octets instead of 4. The rest of the header would look like data to an IPv4 router. So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers. Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. Old IPv4 hosts wouldn't be able to talk to IPv6 endpoints, but at least this way the user could upgrade their own stack without having to wait for their ISP, and every network in between, to also upgrade. It's pretty much carrier grade NAT but from client to client without ISP support being necessary, which is the biggest bottleneck right now.

andrewshadura 2y ago
This has been proposed many times already, and it actually wouldn't work.
- jedberg 2y ago
  Why not?
  - ianburrell 2y ago
    Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts. I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.
    - jedberg 2y ago
      Of course they can't. But the point is that if a client wants to interact with IPv6, they only have to upgrade themselves, and not wait for everything in between to get upgraded. And the service can serve on their IPv4 gateway and then pass the traffic back to other hosts to server IPv4 clients.
      - deleted 2y ago
        [deleted]
jcranmer 2y ago
> So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers. How does the IPv4 person craft the reply back to the not-IPv4 source?
- jedberg 2y ago
  They don't. They still have to upgrade. But at least the service owner has options to run the services on their gateway and then pass the traffic back to the hosts behind on their internal IPv6 network. And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.
  - jcranmer 2y ago
    In other words, your proposal establishes only not-IPv4<->not-IPv4 communication over an IPv4 tunnel, which is something actual IPv6 has had for decades? (There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)
    - jedberg 2y ago
      No, it establishes a path for piecemeal upgrades to the infrastructure that is cross compatible with IPv4.
      - jcranmer 2y ago
        I'm not seeing it... can you clearly explain specifically what scenarios your not-IPv4 deployment strategy enables that doesn't exist with IPv6 today? (If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)
icedchai 2y ago
One problem with this approach is it doesn't really expand the address space for new address assignments. We're still stuck within the 32-bit IPv4 space for the "outer" routing. This seems worse than simply tunneling IPv6 for users with ISPs that don't support it yet.
throw0101d 2y ago
> Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. So: * https://en.wikipedia.org/wiki/Teredo_tunneling https://en.wikipedia.org/wiki/Teredo_tunneling * https://en.wikipedia.org/wiki/6in4 https://en.wikipedia.org/wiki/6in4 * https://en.wikipedia.org/wiki/ISATAP https://en.wikipedia.org/wiki/ISATAP You can sign up for an IPv6 connection, without any IPv6 support from your ISP, via Hurricane Electric's tunnel service: * https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup * https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.html https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn... It's been around for at least a decade: * https://www.internetsociety.org/blog/2014/01/weekend-project-set-up-an-ipv6-tunnel/ https://www.internetsociety.org/blog/2014/01/weekend-project... Any 'expanded IPv4 address' solution will (have) face the same problems that IPv6 has faced, and the solutions will end up being the same: having to slowly upgrade the network stack (hosts, routers, firewalls, ASICs), changes in networking system calls and associated structs (because the number of bits), gateways and transitions mechanisms, expansion of related protocols (DNS A records are only 32-bits, so a new record type needs to be supports (e.g., AAAA for IPv6, AAAAAA for your new proposal)). If you want to argue that we should have (say) kept ARP instead of moving NDP, sure. But anything to do with expanded addressing would be the exact situation: code upgrades and transition mechanisms.
- lloeki 2y ago
  > It's been around for at least a decade I just logged into tunnelbroker.net to check: my HE account has been registered November 22, 2010 11:30:00 UTC. Today it's unused because IPv6 is basically always available in France. That's not even the first time I tried IPv6 things, part of it being I had some access to RENATER via my engineering school, right when they kicked off IPv6 around 2002. The past 10 years of IPv6 have been largely uneventful for me: it just works.
  - simoncion 2y ago
    > The past 10 years of IPv6 have been largely uneventful for me: it just works. Yeah, ditto. Except that it has been more like twenty than ten for me. From my he.net tunnel, to (several years later) my Comcast-provided native IPv6 service, to IPv6 on my phone, to IPv6 with my local ISP (once I switched off of Comcast/NBCUniversal) it has been so very, very boring and reliable for so many years.
akira2501 2y ago
> The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. In your scheme, any IPv4 address is automatically expanded into an IPv6 gateway address, since there is no other way to map that partial addresses together. So, for every /32 of space you want to add, you have to get another IPv4 and use it as a gateway. It's also going to be a massive amount of fun doing "second level CIDR" on those gateways. You've just turned CGNAT inside out to no real benefit.
JackSlateur 2y ago
Pretty simple indeed Will it rewrite all my hardware, without it nothing will work ? No You'd need a full rewrite at the parser level As everybody said : ipv4 cannot be made compatible with larger addr space
Hikikomori 2y ago
Where you gonna put the bits for the extended address?

andrewshadura 2y ago

This has been proposed many times already, and it actually wouldn't work.

jedberg 2y ago
Why not?
- ianburrell 2y ago
  Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts. I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.
  - jedberg 2y ago
    Of course they can't. But the point is that if a client wants to interact with IPv6, they only have to upgrade themselves, and not wait for everything in between to get upgraded. And the service can serve on their IPv4 gateway and then pass the traffic back to other hosts to server IPv4 clients.
    - deleted 2y ago
      [deleted]

jcranmer 2y ago

> So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers. How does the IPv4 person craft the reply back to the not-IPv4 source?

jedberg 2y ago
They don't. They still have to upgrade. But at least the service owner has options to run the services on their gateway and then pass the traffic back to the hosts behind on their internal IPv6 network. And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.
- jcranmer 2y ago
  In other words, your proposal establishes only not-IPv4<->not-IPv4 communication over an IPv4 tunnel, which is something actual IPv6 has had for decades? (There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)
  - jedberg 2y ago
    No, it establishes a path for piecemeal upgrades to the infrastructure that is cross compatible with IPv4.
    - jcranmer 2y ago
      I'm not seeing it... can you clearly explain specifically what scenarios your not-IPv4 deployment strategy enables that doesn't exist with IPv6 today? (If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)

icedchai 2y ago

One problem with this approach is it doesn't really expand the address space for new address assignments. We're still stuck within the 32-bit IPv4 space for the "outer" routing. This seems worse than simply tunneling IPv6 for users with ISPs that don't support it yet.

throw0101d 2y ago

> Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. So: * https://en.wikipedia.org/wiki/Teredo_tunneling https://en.wikipedia.org/wiki/Teredo_tunneling * https://en.wikipedia.org/wiki/6in4 https://en.wikipedia.org/wiki/6in4 * https://en.wikipedia.org/wiki/ISATAP https://en.wikipedia.org/wiki/ISATAP You can sign up for an IPv6 connection, without any IPv6 support from your ISP, via Hurricane Electric's tunnel service: * https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup * https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.html https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn... It's been around for at least a decade: * https://www.internetsociety.org/blog/2014/01/weekend-project-set-up-an-ipv6-tunnel/ https://www.internetsociety.org/blog/2014/01/weekend-project... Any 'expanded IPv4 address' solution will (have) face the same problems that IPv6 has faced, and the solutions will end up being the same: having to slowly upgrade the network stack (hosts, routers, firewalls, ASICs), changes in networking system calls and associated structs (because the number of bits), gateways and transitions mechanisms, expansion of related protocols (DNS A records are only 32-bits, so a new record type needs to be supports (e.g., AAAA for IPv6, AAAAAA for your new proposal)). If you want to argue that we should have (say) kept ARP instead of moving NDP, sure. But anything to do with expanded addressing would be the exact situation: code upgrades and transition mechanisms.

lloeki 2y ago
> It's been around for at least a decade I just logged into tunnelbroker.net to check: my HE account has been registered November 22, 2010 11:30:00 UTC. Today it's unused because IPv6 is basically always available in France. That's not even the first time I tried IPv6 things, part of it being I had some access to RENATER via my engineering school, right when they kicked off IPv6 around 2002. The past 10 years of IPv6 have been largely uneventful for me: it just works.
- simoncion 2y ago
  > The past 10 years of IPv6 have been largely uneventful for me: it just works. Yeah, ditto. Except that it has been more like twenty than ten for me. From my he.net tunnel, to (several years later) my Comcast-provided native IPv6 service, to IPv6 on my phone, to IPv6 with my local ISP (once I switched off of Comcast/NBCUniversal) it has been so very, very boring and reliable for so many years.

akira2501 2y ago

> The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address. In your scheme, any IPv4 address is automatically expanded into an IPv6 gateway address, since there is no other way to map that partial addresses together. So, for every /32 of space you want to add, you have to get another IPv4 and use it as a gateway. It's also going to be a massive amount of fun doing "second level CIDR" on those gateways. You've just turned CGNAT inside out to no real benefit.

JackSlateur 2y ago

Pretty simple indeed Will it rewrite all my hardware, without it nothing will work ? No You'd need a full rewrite at the parser level As everybody said : ipv4 cannot be made compatible with larger addr space

Hikikomori 2y ago

Where you gonna put the bits for the extended address?