5 ms·

Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit

Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit source and destination headers in V4.

jedberg 2y ago
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?
chadsix 2y ago
We do backwards and forwards compatibility between v4 and v6 using NAT64+DNS64 between IPv6 -> IPv4[1] and a reverse proxy (delorean) for IPv4 -> IPv6 [2]. To ensure reachability to IPv4 endpoints without a domain, we use visibleip.com [3]. For our users, it doesn't matter if it's IPv4 or IPv6 - they can reach it, and it can reach them. [1] https://blog.ipv6.rs/ipv4-activated-via-nat64/ https://blog.ipv6.rs/ipv4-activated-via-nat64/ [2] https://github.com/ipv6rslimited/delorean https://github.com/ipv6rslimited/delorean [3] https://github.com/ipv6rslimited/legacydns https://github.com/ipv6rslimited/legacydns
tsimionescu 2y ago
If they didn't completely rethink how IPs are associated with hosts, with the whole SLAAC and privacy address and etc crazyness that even ended up making ifconfig deprecated, perhaps adoption could have been much quicker. IPv6 didn't only impact networking devices, it affected end-user applications that interact with the network in many ways, and this is a big part of the slow adoption.
- ajsnigrutin 2y ago
  We had two choices back then.. 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. 2) if we're already replacing everything, make stuff better We chose #2, with varying degrees of what is "better".
  - quectophoton 2y ago
    And for the record, a backwards-compatible-ish way was proposed in 1993 (https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475), by using an option in the IPv4 packet header. AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed. 1993 was more than 30 years ago. So people who wanted to keep it backwards-compatible with IPv4 already had a chance.
    - throw0101b 2y ago
      From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram. […] On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received (in either version) the assumption is confirmed. If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them. So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first): * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized: There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host. Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6). IPv7 would have had the exact same issues that IPv6 had with rollout. There is no "just" when trying to expand a fixed-size data structure across the entire planet.
alerighi 2y ago
You could have just extended the IPv4 header in such a way that the routers in between you and the server didn't need to understand the extended protocol, and could continue to route IPv4 packets as-is, since they only see the upper 32 bit of the address. Then network inside LAN and the server need of course to understand IPv4-extended (let's call it IPv5) packets, but still you only need to update the endpoint devices, and not the core of the network (fare easy, since that evolves more quickly!). You could also implemented a mechanism "similar" to NAT, where the router did for outgoing traffic compose the extended "IPv5" packet by combining the local IPv4 and the external IPv4, and did the opposite operation for incoming packets. That way really only the router needed to be updated, and not individual devices in your house. Thus being backward compatible in both ways. Also adopting IPv6 these days would require to maintain still IPv4, this means that for example firewall rules must be made both for IPv4 and IPv6, something that adds a lot of work to IT technicians (and they thus disable the protocol that if you disable the internet still works, that is IPv6). Extending IPv4 would mean that the same firewall rules can apply, just considering again the upper 32 bits of the address. Finally IPv6 is in general more complex, it has some obscure things like SLAAC or the fact that an interface can have multiple IPs, that not all IPs are routable, etc, even simply the notation for IPv6 addresses that is not even consistent among software (in some software you have to put it between [] to disambiguate with port numbers, in some other not), DHCPv6 implementations that are still these days quite broken, etc. Compared to IPv4 is quite a complication... I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4, and requires maintaining a network with two protocols, since everyone completes the migrations, this is unlikely to succeed in the next years (for example in my country, Italy, most ISP, even the most important one, don't even bother to provide you an IPv6 address! I think that because it does increment the problems and thus the requests to handle in the customer service, thus they decided that you just get IPv4 that works reliably).
- quectophoton 2y ago
  > You could have just extended the IPv4 header Sounds like IPv7, from year 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 > I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4 Doubt, seeing how IPv7 appeared around the same time as IPv6 (RFC1883, from year 1995) and we still don't see IPv7 anywhere. To be fair, IPv7 seems to have been deprecated in 2012 (RFC6814). It had almost 20 years to catch up but, quoting the RFC, "IPv7 was never widely deployed".
hot_gril 2y ago
The issue is really forwards compatibility. Every ipv4 address should've been kept valid in all ipv6 networks. Step 1 would've been to leave all the routing, DNS, NAT, DHCP etc as-is and just get people's devices speaking ipv6. And we would've already been there years ago. Once that's done, DNS and DHCP can be updated, then people can start using the extended address space by splitting up their blocks. So if you previously had 1.2.3.4, you now also have 1.2.3.4.1 etc. It's actually not too late to do this with the existing v6 header.
mprovost 2y ago
It's not the case that there were no alternative designs at the time that v6 was proposed. RFC 1385 described a backwards compatible Extended Internet Protocol which used IP Option headers to stuff in extra addressing space. https://datatracker.ietf.org/doc/html/rfc1385 https://datatracker.ietf.org/doc/html/rfc1385
- p_l 2y ago
  Still deals with the mess that was BSD Sockets preventing forward compatibility.

Can you describe how you'd make it more backwards compatible? I often see comments like this, yet nobody can work around the fact that you're limited by 32-bit source and destination headers in V4.

jedberg 2y ago

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?

chadsix 2y ago

We do backwards and forwards compatibility between v4 and v6 using NAT64+DNS64 between IPv6 -> IPv4[1] and a reverse proxy (delorean) for IPv4 -> IPv6 [2]. To ensure reachability to IPv4 endpoints without a domain, we use visibleip.com [3]. For our users, it doesn't matter if it's IPv4 or IPv6 - they can reach it, and it can reach them. [1] https://blog.ipv6.rs/ipv4-activated-via-nat64/ https://blog.ipv6.rs/ipv4-activated-via-nat64/ [2] https://github.com/ipv6rslimited/delorean https://github.com/ipv6rslimited/delorean [3] https://github.com/ipv6rslimited/legacydns https://github.com/ipv6rslimited/legacydns

tsimionescu 2y ago

If they didn't completely rethink how IPs are associated with hosts, with the whole SLAAC and privacy address and etc crazyness that even ended up making ifconfig deprecated, perhaps adoption could have been much quicker. IPv6 didn't only impact networking devices, it affected end-user applications that interact with the network in many ways, and this is a big part of the slow adoption.

ajsnigrutin 2y ago
We had two choices back then.. 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. 2) if we're already replacing everything, make stuff better We chose #2, with varying degrees of what is "better".
- quectophoton 2y ago
  And for the record, a backwards-compatible-ish way was proposed in 1993 (https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475), by using an option in the IPv4 packet header. AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed. 1993 was more than 30 years ago. So people who wanted to keep it backwards-compatible with IPv4 already had a chance.
  - throw0101b 2y ago
    From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram. […] On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received (in either version) the assumption is confirmed. If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them. So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first): * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized: There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host. Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6). IPv7 would have had the exact same issues that IPv6 had with rollout. There is no "just" when trying to expand a fixed-size data structure across the entire planet.

alerighi 2y ago

You could have just extended the IPv4 header in such a way that the routers in between you and the server didn't need to understand the extended protocol, and could continue to route IPv4 packets as-is, since they only see the upper 32 bit of the address. Then network inside LAN and the server need of course to understand IPv4-extended (let's call it IPv5) packets, but still you only need to update the endpoint devices, and not the core of the network (fare easy, since that evolves more quickly!). You could also implemented a mechanism "similar" to NAT, where the router did for outgoing traffic compose the extended "IPv5" packet by combining the local IPv4 and the external IPv4, and did the opposite operation for incoming packets. That way really only the router needed to be updated, and not individual devices in your house. Thus being backward compatible in both ways. Also adopting IPv6 these days would require to maintain still IPv4, this means that for example firewall rules must be made both for IPv4 and IPv6, something that adds a lot of work to IT technicians (and they thus disable the protocol that if you disable the internet still works, that is IPv6). Extending IPv4 would mean that the same firewall rules can apply, just considering again the upper 32 bits of the address. Finally IPv6 is in general more complex, it has some obscure things like SLAAC or the fact that an interface can have multiple IPs, that not all IPs are routable, etc, even simply the notation for IPv6 addresses that is not even consistent among software (in some software you have to put it between [] to disambiguate with port numbers, in some other not), DHCPv6 implementations that are still these days quite broken, etc. Compared to IPv4 is quite a complication... I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4, and requires maintaining a network with two protocols, since everyone completes the migrations, this is unlikely to succeed in the next years (for example in my country, Italy, most ISP, even the most important one, don't even bother to provide you an IPv6 address! I think that because it does increment the problems and thus the requests to handle in the customer service, thus they decided that you just get IPv4 that works reliably).

quectophoton 2y ago
> You could have just extended the IPv4 header Sounds like IPv7, from year 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 > I'm the opinion that we are slow to adopt IPv6 since it's too different from IPv4 Doubt, seeing how IPv7 appeared around the same time as IPv6 (RFC1883, from year 1995) and we still don't see IPv7 anywhere. To be fair, IPv7 seems to have been deprecated in 2012 (RFC6814). It had almost 20 years to catch up but, quoting the RFC, "IPv7 was never widely deployed".

hot_gril 2y ago

The issue is really forwards compatibility. Every ipv4 address should've been kept valid in all ipv6 networks. Step 1 would've been to leave all the routing, DNS, NAT, DHCP etc as-is and just get people's devices speaking ipv6. And we would've already been there years ago. Once that's done, DNS and DHCP can be updated, then people can start using the extended address space by splitting up their blocks. So if you previously had 1.2.3.4, you now also have 1.2.3.4.1 etc. It's actually not too late to do this with the existing v6 header.

mprovost 2y ago

It's not the case that there were no alternative designs at the time that v6 was proposed. RFC 1385 described a backwards compatible Extended Internet Protocol which used IP Option headers to stuff in extra addressing space. https://datatracker.ietf.org/doc/html/rfc1385 https://datatracker.ietf.org/doc/html/rfc1385

p_l 2y ago
Still deals with the mess that was BSD Sockets preventing forward compatibility.