34 ms·

I'm not the person you are responding to, but from what I understand the main issues are: ipv6 is not backwards compatible with ipv4. Consequently adding supp

by magpi3 5y ago

I'm not the person you are responding to, but from what I understand the main issues are: ipv6 is not backwards compatible with ipv4. Consequently adding support for ipv6 requires a dual stack solution (since supporting ipv4 is a must). An alternative solution to the problem of the limited number of ipv4 addresses has been reliance on NATs. This is much simpler than supporting ipv6 and is already widely adopted everywhere, and so that's what people are choosing to do. The obvious conclusion (from a casual observer like myself): the successor to ipv4 has to be backwards compatible with it, similar to how UTF-8 is backwards compatible with ASCII. EDIT: I should note that I am not a network engineer, so if anything I have written is incorrect, I hope someone corrects me.

throw0101a 5y ago
> ipv6 is not backwards compatible with ipv4. I've seen this objection, and I do not see how it could be otherwise. If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).
- magpi3 5y ago
  Again, I am not a network engineer and so I am a little of my depth. But I will respond in the hopes someone will educate me if I am wrong. While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard. From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
  - magicalhippo 5y ago
    The problem is packets flow both ways in a network. It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply. So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
  - throw0101a 5y ago
    Yes, and all software had to be rewritten to use UTF-8. If you tried sending UTF-8 bits through an ASCII-only system, you'd display a bunch of garbage and even cause larger issues (as some bit sequences could have been interpreted as control/escape characters). So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
  - betterunix2 5y ago
    Actually, IPv4 address can be mapped to the IPv6 address space and routed across an IPv6-only network; you have stateless NAT gateways at the edges. That allows network operators to manage a single-stack network while still giving users an IPv4 network. 464XLAT adds one more component to the picture, which is a stateful NAT gateway that allows a network operator to provide limited IPv4 service without giving each user a public IPv4 address. For reference: https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...

by magpi3 5y ago

throw0101a 5y ago

> ipv6 is not backwards compatible with ipv4. I've seen this objection, and I do not see how it could be otherwise. If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).

magpi3 5y ago
Again, I am not a network engineer and so I am a little of my depth. But I will respond in the hopes someone will educate me if I am wrong. While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard. From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
- magicalhippo 5y ago
  The problem is packets flow both ways in a network. It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply. So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
- throw0101a 5y ago
  Yes, and all software had to be rewritten to use UTF-8. If you tried sending UTF-8 bits through an ASCII-only system, you'd display a bunch of garbage and even cause larger issues (as some bit sequences could have been interpreted as control/escape characters). So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
- betterunix2 5y ago
  Actually, IPv4 address can be mapped to the IPv6 address space and routed across an IPv6-only network; you have stateless NAT gateways at the edges. That allows network operators to manage a single-stack network while still giving users an IPv4 network. 464XLAT adds one more component to the picture, which is a stateful NAT gateway that allows a network operator to provide limited IPv4 service without giving each user a public IPv4 address. For reference: https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...