4 ms·

Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an

by j1elo 6mo ago

Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space. So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.

IsTom 6mo ago
How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?
- deleted 6mo ago
  [deleted]
- j1elo 6mo ago
  In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case. What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
  - zamadatix 6mo ago
    https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.1 https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.... & the following section for the follow-up embedding.
  - Hikikomori 6mo ago
    They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
  - throw0101c 6mo ago
    > What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. Like: > Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
  - yrjrjjrjjtjjr 6mo ago
    The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.
    - icedchai 6mo ago
      Not really reasonable. That would 1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else. The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.
    - Dagger2 6mo ago
      Perhaps you could use 41, the value already associated with doing this. (What's up with people constantly suggesting that v6 should do things that it already does?)
      - deleted 6mo ago
        [deleted]
      - yrjrjjrjjtjjr 6mo ago
        That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.
        Dagger2 6mo ago
        That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.
zamadatix 6mo ago
Programmers really like to focus on things like: - How they would format the display of the bits - Where in the bit pattern IPv4 mapped addresses should go - Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks - Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are: - A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete. If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
SkiFire13 6mo ago
How would you get someone that only knows about IPv4 addresses like 10.20.30.40 to send a packet to someone with an address 10.20.30.40:fa:be:4c:9d?
throw0101c 6mo ago
> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. Like > Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse... Or: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6. So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc) You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space. Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect: * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs "Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea. (This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.) > If IPv4 were more painfully broken then the switch would have happened long ago. IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them). So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
wjholden 6mo ago
The header of an IPv4 packet has the source and destination addresses, both as 32-bit values. These fields are adjacent, and there's other stuff next to them. If you appended more bytes to the source address, routers would think that those new bytes are the destination address. This would not be backward compatible. Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;l=53 https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...
- urineaut 6mo ago
  That's not a language-specific thing, but is actually part of the IPv6 RFCs as IPv4-mapped IPv6 addresses: [1], [2] This is super useful because (at least on Linux) IPv6 sockets per default are dual-stack and bind to both IPv6 and IPv6 (except if you are using the IPV6_V6ONLY sockopt or a sysctl), so you don't need to open and handle IPv4 and IPv6 sockets separately (well, maybe some extra code for logging/checking properly with the actual IPv4 address). That is also documented in ipv6(7): IPv4 connections can be handled with the v6 API by using v4-mapped-on-v6 address type; thus a program needs to support only this API type to support both protocols. This is handled transparently by the address handling functions in the C library. IPv4 and IPv6 share the local port space. When you get an IPv4 connection or packet to an IPv6 socket, its source address will be mapped to v6. [0]: https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 [1]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2 https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....

by j1elo 6mo ago

IsTom 6mo ago

How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?

deleted 6mo ago
[deleted]
j1elo 6mo ago
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case. What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
- zamadatix 6mo ago
  https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.1 https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.... & the following section for the follow-up embedding.
- Hikikomori 6mo ago
  They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
- throw0101c 6mo ago
  > What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. Like: > Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
- yrjrjjrjjtjjr 6mo ago
  The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.
  - icedchai 6mo ago
    Not really reasonable. That would 1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else. The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.
  - Dagger2 6mo ago
    Perhaps you could use 41, the value already associated with doing this. (What's up with people constantly suggesting that v6 should do things that it already does?)
    - deleted 6mo ago
      [deleted]
    - yrjrjjrjjtjjr 6mo ago
      That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.
      - Dagger2 6mo ago
        That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.

zamadatix 6mo ago

Programmers really like to focus on things like: - How they would format the display of the bits - Where in the bit pattern IPv4 mapped addresses should go - Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks - Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are: - A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete. If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.

SkiFire13 6mo ago

How would you get someone that only knows about IPv4 addresses like 10.20.30.40 to send a packet to someone with an address 10.20.30.40:fa:be:4c:9d?

throw0101c 6mo ago

> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. Like > Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5] * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse... Or: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6. So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc) You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space. Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect: * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs "Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea. (This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.) > If IPv4 were more painfully broken then the switch would have happened long ago. IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them). So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.

wjholden 6mo ago

The header of an IPv4 packet has the source and destination addresses, both as 32-bit values. These fields are adjacent, and there's other stuff next to them. If you appended more bytes to the source address, routers would think that those new bytes are the destination address. This would not be backward compatible. Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;l=53 https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...

urineaut 6mo ago
That's not a language-specific thing, but is actually part of the IPv6 RFCs as IPv4-mapped IPv6 addresses: [1], [2] This is super useful because (at least on Linux) IPv6 sockets per default are dual-stack and bind to both IPv6 and IPv6 (except if you are using the IPV6_V6ONLY sockopt or a sysctl), so you don't need to open and handle IPv4 and IPv6 sockets separately (well, maybe some extra code for logging/checking properly with the actual IPv4 address). That is also documented in ipv6(7): IPv4 connections can be handled with the v6 API by using v4-mapped-on-v6 address type; thus a program needs to support only this API type to support both protocols. This is handled transparently by the address handling functions in the C library. IPv4 and IPv6 share the local port space. When you get an IPv4 connection or packet to an IPv6 socket, its source address will be mapped to v6. [0]: https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 [1]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2 https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....