3 ms·

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 i

by 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.
  - orangeboats 3y ago
    [flagged]
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.

by izacus 3y ago

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.
- orangeboats 3y ago
  [flagged]

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.