3 ms·

> complete rework and rethink how local network routing works There's no fundamental difference in routing. They both use trivially simple prefix routing. > r

> complete rework and rethink how local network routing works There's no fundamental difference in routing. They both use trivially simple prefix routing. > removal of standard NAT NAT isn't "standard". NAT is a nasty kludge that people put in because they were too lazy to upgrade their software stacks. And IPv6 was defined before NAT was commonly used, in large part as a way to avoid NAT becoming common. Because NAT is a bad idea in every possible way. Also, IPv4 is itself much, much simpler without NAT. And you can do NAT on IPv6 if you're stupid enough to want to. Saying that IPv6 is complicated because it removes the need for a complicated hack like NAT is just insanity. > (DHCPv6, SLAAC, and all of those messes) Those are not in any way more complicated or harder to use than DHCP4. Setting up a DHCP server to get automatic address assignment on an IPv4 network is actually harder than letting a router automatically do SLAAC to do address assignment on IPv6. Also, DHCP is not part of IPv4, and DHCP6 is not part of IPv6. I was using and managing IPv4 networks before DHCP existed. Yes, it was a royal pain in the ass... which is why that functionality was integrated into IPv6. Which was done a protocol that's actually simpler than DHCP, although I didn't and still don't approve of the way it wastes address bits.

izacus 3y ago
Look, you can bloviate about how "easy and not complicated" IPv6 is and how NAT is a cludge... but failing adoption and horrid bugginess of IPv6 network stack implementation is showing the actual truth of just how much IPv6 changes and complexity hamstring the standard. The fact that you consider SLAAC somehow equivalent to DHCP shows that - I've never seen a router (outside maybe some ciscos) where those two could be used to achieve the same stable network assignment and configure downstream service firewalls appropriately. That is - if SLAAC actually works across all clients and they're not a buggy mess.
- orangeboats 3y ago
  >but failing adoption 45% adoption. >horrid bugginess of IPv6 network stack Were the IPv4 network stack _not_ buggy? Are you sure it's just not the general incompetence of network equipment people? >where those two could be used to achieve the same stable network assignment and configure downstream service firewalls appropriately What? >SLAAC actually works across all clients and they're not a buggy mess What buggy mess? I'm on SLAAC and I don't notice anything buggy?
  - yjftsjthsd-h 3y ago
    > 45% adoption After 28 years? Yeah, that sounds like failing adoption.
    - orangeboats 3y ago
      The World IPv6 Launch Day was carried out on June 2012. 12 years for 45% adoption is certainly not bad, considering how many ancient networking equipments are still around.
      - yjftsjthsd-h 3y ago
        Spending 16 years in development is also not an amazing look, but if we run with that - no, 45% adoption after 12 years certainly is bad. As a reference point, it looks like Cisco gear has a ~5 year process for EOLing things. So 12 years is a while, even if it was purely driven by old gear getting replaced. Edit: I should caveat - I don't have good data on actual lifespan of networking equipment; if you can show that it's likely to live more than a decade then that would be reasonably compelling.
        orangeboats 3y ago
        To Google, HTTPS was at 48% adoption in 2014. [0] This is 14 years after its initial specification (RFC 2818), even longer if you take Netscape into account. And this is despite the fact that HTTPS is completely done in software, which typically gets updated more often than hardware. I stand by my assessment that 45% adoption after 12 years is actually pretty good. [0]: https://transparencyreport.google.com/https/overview?hl=en https://transparencyreport.google.com/https/overview?hl=en (I use Google's data for both HTTPS and IPv6 stats. If you consider 3rd party data, HTTPS adoption is way worse, even to this day it hasn't topped 75%.)
  - izacus 3y ago
    "45% adoption" doesn't tell about just how poorly IPv6 is actually supported on routers and home devices available to smaller customers.
- Hizonner 3y ago
  The implementation you use is your own choice, not a law of nature or part of either protocol. This is a classic responsibility-evasion cycle: Users: We can't get equipment that supports this (or supports it well, or makes it easy), so we won't deploy it. Vendors: Users aren't demanding it, so we won't support it. The result is a suboptimal local equilibrium and an obvious market failure, but you invariably get loudmouths on message boards saying "Look, the Market (Peace Be Upon It) has spoken!". Gets a bit old. The right answer in this case is probably coercive government regulation of the form "No IPv4 packet shall cross a property line", but I'm not holding my breath.

izacus 3y ago

Look, you can bloviate about how "easy and not complicated" IPv6 is and how NAT is a cludge... but failing adoption and horrid bugginess of IPv6 network stack implementation is showing the actual truth of just how much IPv6 changes and complexity hamstring the standard. The fact that you consider SLAAC somehow equivalent to DHCP shows that - I've never seen a router (outside maybe some ciscos) where those two could be used to achieve the same stable network assignment and configure downstream service firewalls appropriately. That is - if SLAAC actually works across all clients and they're not a buggy mess.

orangeboats 3y ago
>but failing adoption 45% adoption. >horrid bugginess of IPv6 network stack Were the IPv4 network stack _not_ buggy? Are you sure it's just not the general incompetence of network equipment people? >where those two could be used to achieve the same stable network assignment and configure downstream service firewalls appropriately What? >SLAAC actually works across all clients and they're not a buggy mess What buggy mess? I'm on SLAAC and I don't notice anything buggy?
- yjftsjthsd-h 3y ago
  > 45% adoption After 28 years? Yeah, that sounds like failing adoption.
  - orangeboats 3y ago
    The World IPv6 Launch Day was carried out on June 2012. 12 years for 45% adoption is certainly not bad, considering how many ancient networking equipments are still around.
    - yjftsjthsd-h 3y ago
      Spending 16 years in development is also not an amazing look, but if we run with that - no, 45% adoption after 12 years certainly is bad. As a reference point, it looks like Cisco gear has a ~5 year process for EOLing things. So 12 years is a while, even if it was purely driven by old gear getting replaced. Edit: I should caveat - I don't have good data on actual lifespan of networking equipment; if you can show that it's likely to live more than a decade then that would be reasonably compelling.
      - orangeboats 3y ago
        To Google, HTTPS was at 48% adoption in 2014. [0] This is 14 years after its initial specification (RFC 2818), even longer if you take Netscape into account. And this is despite the fact that HTTPS is completely done in software, which typically gets updated more often than hardware. I stand by my assessment that 45% adoption after 12 years is actually pretty good. [0]: https://transparencyreport.google.com/https/overview?hl=en https://transparencyreport.google.com/https/overview?hl=en (I use Google's data for both HTTPS and IPv6 stats. If you consider 3rd party data, HTTPS adoption is way worse, even to this day it hasn't topped 75%.)
- izacus 3y ago
  "45% adoption" doesn't tell about just how poorly IPv6 is actually supported on routers and home devices available to smaller customers.
Hizonner 3y ago
The implementation you use is your own choice, not a law of nature or part of either protocol. This is a classic responsibility-evasion cycle: Users: We can't get equipment that supports this (or supports it well, or makes it easy), so we won't deploy it. Vendors: Users aren't demanding it, so we won't support it. The result is a suboptimal local equilibrium and an obvious market failure, but you invariably get loudmouths on message boards saying "Look, the Market (Peace Be Upon It) has spoken!". Gets a bit old. The right answer in this case is probably coercive government regulation of the form "No IPv4 packet shall cross a property line", but I'm not holding my breath.