6 ms·

IPv6 is a bad technical standard to begin with (which is on of the reasons behind slow adoption). Forcing it with legislation would only make everyone involved

IPv6 is a bad technical standard to begin with (which is on of the reasons behind slow adoption). Forcing it with legislation would only make everyone involved to hate it more.

throw0101a 5y ago
> IPv6 is a bad technical standard to begin with Can you expound on why you think this is the case?
- snuxoll 5y ago
  Not GP, but I think IPv6 is generally fine. The big issue is around mid sized enterprises, where multi homing becomes a need and for so long PI address space was reserved for peering-sizes entities. This makes sense from the perspective of reducing routing table size, but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck). The IETF really needs to fix this issue in particular, it’s the last big hurdle in seeing adoption IMO.
  - throw0101a 5y ago
    > but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck). Is using ULA and NPTv6 any worse than using NAT44?
    - snuxoll 5y ago
      It’s not - but that doesn’t mean it’s a good solution. Clients should be able to know their globally routable address and ULA with NPTv6 seriously fucks with that, so I’m not a fan.
  - ikiris 5y ago
    PI was never reserved for peering sized entities... just get PI space.
    - throw0101a 5y ago
      Depending on the tech skills of the organizations, your ISP(s) may have to run BGP on your behalf--even if the IPv6 is yours. (Not sure if that's even a thing.)
  - magila 5y ago
    What would a good solution to that even look like? Giving every mid-sized company it's own PI block would massively bloat the routing table so that's not going to happen. The solution space that's left basically comes down to some form of NAT/NPT or multi-home support at the endpoints. The IETF's preferred solution is the latter which seems reasonable to me.
    - snuxoll 5y ago
      I fully agree that giving PI blocks out like candy is not the ideal solution - but the solutions for dealing with multiple PA spaces are woefully inadequate right now. I’d really like to see the IETF step in here and come up with some workable proposals before we ruin IPv6 while it’s still possible to fix these issues.
- 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.
- citrin_ru 5y ago
  It's too late to discuss alternatives to IPv6, so I haven't spend time collecting what I think wrong with it (and below just random thoughts). The main reason I don't like it - it is much more complex than IPv4 and this complexity provides from little to now real benefits (but a lot of advertised by IPv6 evangelists). The only reason networks migrate to IPv6 is the scarcity of IPv4 addresses, not other features which was envisioned as improvements over IPv4, but on practice turned out to be not very useful. 128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me. Idea was to embed MAC-address in lower 64bit, but it turned out to be a bad idea because of privacy implications and for most end-user devices lower 64bit are now random. Given that /64 prefix in most cases used by single host a 64bit address would be sufficient. If we had 64bit addresses we would save RAM for routers and OS kernels and simplify implementation (64bit integers are available in practically all modern programming languages and 64bit operations are fast, while 128bit is a slower extension which is not universally available). For me IPv6 is an example of the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
  - betterunix2 5y ago
    In my experience IPv6 is much simpler to deal with than IPv4; in fact the large address space with a 64-bit prefix as the network number greatly simplifies management and configuration and theoretically improves the CPU performance of routers by allowing allowing more aggressive route aggregation. When ISPs give /56 prefixes to users, users can easily set up subnets according to their own needs without requiring extra coordination and without breaking end-to-end connectivity. You are wrong that /64 prefixes are usually assigned to a single host; in fact the number of Internet-connected devices in a typical home has grown over time and can easily be a dozen or more. If I were running an ISP, I would migrate the backbone network to IPv6 and just use embedded IPv4 addresses to avoid the headaches that come with router-to-router IPv4 links. With IPv6 you always have a link-local address on every port that can be used by routing protocols without relying on proprietary solutions that are not interoperable between vendors or having to assign an IPv4 address (and hoping that you assigned a large enough subnet for future growth). It is much easier to scale up an IPv6-only network and much easier to connect one IPv6-only network to another. Of course IPv6 is not perfect. SLAAC did not really work out as planned and now we are stuck with an annoying mix of SLAAC and DHCPv6. Reverse-DNS is still a bit of a pain. IPSec is not what it should have been and too many IPv6 standards rely on IPSec for security/authentication. Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.

IPv6 is a bad technical standard to begin with (which is on of the reasons behind slow adoption). Forcing it with legislation would only make everyone involved to hate it more.

throw0101a 5y ago

> IPv6 is a bad technical standard to begin with Can you expound on why you think this is the case?

snuxoll 5y ago
Not GP, but I think IPv6 is generally fine. The big issue is around mid sized enterprises, where multi homing becomes a need and for so long PI address space was reserved for peering-sizes entities. This makes sense from the perspective of reducing routing table size, but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck). The IETF really needs to fix this issue in particular, it’s the last big hurdle in seeing adoption IMO.
- throw0101a 5y ago
  > but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck). Is using ULA and NPTv6 any worse than using NAT44?
  - snuxoll 5y ago
    It’s not - but that doesn’t mean it’s a good solution. Clients should be able to know their globally routable address and ULA with NPTv6 seriously fucks with that, so I’m not a fan.
- ikiris 5y ago
  PI was never reserved for peering sized entities... just get PI space.
  - throw0101a 5y ago
    Depending on the tech skills of the organizations, your ISP(s) may have to run BGP on your behalf--even if the IPv6 is yours. (Not sure if that's even a thing.)
- magila 5y ago
  What would a good solution to that even look like? Giving every mid-sized company it's own PI block would massively bloat the routing table so that's not going to happen. The solution space that's left basically comes down to some form of NAT/NPT or multi-home support at the endpoints. The IETF's preferred solution is the latter which seems reasonable to me.
  - snuxoll 5y ago
    I fully agree that giving PI blocks out like candy is not the ideal solution - but the solutions for dealing with multiple PA spaces are woefully inadequate right now. I’d really like to see the IETF step in here and come up with some workable proposals before we ruin IPv6 while it’s still possible to fix these issues.
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.
citrin_ru 5y ago
It's too late to discuss alternatives to IPv6, so I haven't spend time collecting what I think wrong with it (and below just random thoughts). The main reason I don't like it - it is much more complex than IPv4 and this complexity provides from little to now real benefits (but a lot of advertised by IPv6 evangelists). The only reason networks migrate to IPv6 is the scarcity of IPv4 addresses, not other features which was envisioned as improvements over IPv4, but on practice turned out to be not very useful. 128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me. Idea was to embed MAC-address in lower 64bit, but it turned out to be a bad idea because of privacy implications and for most end-user devices lower 64bit are now random. Given that /64 prefix in most cases used by single host a 64bit address would be sufficient. If we had 64bit addresses we would save RAM for routers and OS kernels and simplify implementation (64bit integers are available in practically all modern programming languages and 64bit operations are fast, while 128bit is a slower extension which is not universally available). For me IPv6 is an example of the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- betterunix2 5y ago
  In my experience IPv6 is much simpler to deal with than IPv4; in fact the large address space with a 64-bit prefix as the network number greatly simplifies management and configuration and theoretically improves the CPU performance of routers by allowing allowing more aggressive route aggregation. When ISPs give /56 prefixes to users, users can easily set up subnets according to their own needs without requiring extra coordination and without breaking end-to-end connectivity. You are wrong that /64 prefixes are usually assigned to a single host; in fact the number of Internet-connected devices in a typical home has grown over time and can easily be a dozen or more. If I were running an ISP, I would migrate the backbone network to IPv6 and just use embedded IPv4 addresses to avoid the headaches that come with router-to-router IPv4 links. With IPv6 you always have a link-local address on every port that can be used by routing protocols without relying on proprietary solutions that are not interoperable between vendors or having to assign an IPv4 address (and hoping that you assigned a large enough subnet for future growth). It is much easier to scale up an IPv6-only network and much easier to connect one IPv6-only network to another. Of course IPv6 is not perfect. SLAAC did not really work out as planned and now we are stuck with an annoying mix of SLAAC and DHCPv6. Reverse-DNS is still a bit of a pain. IPSec is not what it should have been and too many IPv6 standards rely on IPSec for security/authentication. Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.