4 ms·

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.

AussieWog93 6mo ago
Wait, why couldn't it? Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
- eptcyka 6mo ago
  In what world does is such a protocol any more *”””compatible”””* with IPv4 than IPv6 already is? It is a different header after all.
- kstrauser 6mo ago
  Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
- bluGill 6mo ago
  That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
  - CookieTonsure 6mo ago
    [dead]
- treyd 6mo ago
  Well for starters, IPv6 has 128 bit addrs. But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too. If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
  - AussieWog93 6mo ago
    >how would an IPv4-only host find an IPv6 host not in pool 0? Ah.
jcgl 6mo ago
Yep. Translation technologies like NAT64 and company basically as good a job as can be hoped for. And they're quite good nowadays! But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?
- p1mrx 6mo ago
  https://en.wikipedia.org/wiki/UTF-7 https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used. UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.
  - jcgl 6mo ago
    Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
  - throw0101c 6mo ago
    > https://en.wikipedia.org/wiki/UTF-7 https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used. UTF-7 was possible because there was an out-of-band mechanism to signal its use, "Content-Type: text/plain; charset=UTF-7": * https://datatracker.ietf.org/doc/html/rfc2152 https://datatracker.ietf.org/doc/html/rfc2152 What's the OOB signalling in IP packet transmission between two random nodes on the Internet.
    - wmf 6mo ago
      The first thing in the IP header is the version number.
      - throw0101c 6mo ago
        > The first thing in the IP header is the version number. So you just change the version number… like was done with IPv6? How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.
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
commandersaki 6mo ago
This recent article begs to differ: https://news.ycombinator.com/item?id=47352236 https://news.ycombinator.com/item?id=47352236
- orangeboats 6mo ago
  Come on... that's the top comment on the thread you shared. https://news.ycombinator.com/item?id=47355046 https://news.ycombinator.com/item?id=47355046 This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so. I quote from the top comment: >So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6. and >So you have to update DNS to create new resource record types [...] Just like with IPv6. and >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.
  - commandersaki 6mo ago
    The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6. The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4. IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later. Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.
    - Dagger2 6mo ago
      Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning. > but the point that there could be an interoperable version of a next generation IP and IPv4 Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms. You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.

AussieWog93 6mo ago

Wait, why couldn't it? Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.

eptcyka 6mo ago
In what world does is such a protocol any more *”””compatible”””* with IPv4 than IPv6 already is? It is a different header after all.
kstrauser 6mo ago
Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
bluGill 6mo ago
That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
- CookieTonsure 6mo ago
  [dead]
treyd 6mo ago
Well for starters, IPv6 has 128 bit addrs. But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too. If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
- AussieWog93 6mo ago
  >how would an IPv4-only host find an IPv6 host not in pool 0? Ah.

jcgl 6mo ago

Yep. Translation technologies like NAT64 and company basically as good a job as can be hoped for. And they're quite good nowadays! But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?

p1mrx 6mo ago
https://en.wikipedia.org/wiki/UTF-7 https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used. UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.
- jcgl 6mo ago
  Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
- throw0101c 6mo ago
  > https://en.wikipedia.org/wiki/UTF-7 https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used. UTF-7 was possible because there was an out-of-band mechanism to signal its use, "Content-Type: text/plain; charset=UTF-7": * https://datatracker.ietf.org/doc/html/rfc2152 https://datatracker.ietf.org/doc/html/rfc2152 What's the OOB signalling in IP packet transmission between two random nodes on the Internet.
  - wmf 6mo ago
    The first thing in the IP header is the version number.
    - throw0101c 6mo ago
      > The first thing in the IP header is the version number. So you just change the version number… like was done with IPv6? How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.

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

commandersaki 6mo ago

This recent article begs to differ: https://news.ycombinator.com/item?id=47352236 https://news.ycombinator.com/item?id=47352236

orangeboats 6mo ago
Come on... that's the top comment on the thread you shared. https://news.ycombinator.com/item?id=47355046 https://news.ycombinator.com/item?id=47355046 This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so. I quote from the top comment: >So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6. and >So you have to update DNS to create new resource record types [...] Just like with IPv6. and >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.
- commandersaki 6mo ago
  The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6. The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4. IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later. Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.
  - Dagger2 6mo ago
    Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning. > but the point that there could be an interoperable version of a next generation IP and IPv4 Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms. You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)