5 ms·

This annoys me, especially the last “It takes at least 25 years” rhetoric. It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to repl

This annoys me, especially the last “It takes at least 25 years” rhetoric. It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other. The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck. We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow. If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility. Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.

SkiFire13 6mo ago
> Instead they expected humans to parse hex, which no one does Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.
- rusk 6mo ago
  Wait til you’ve got to copy & paste em, or see em comingled with hw addresses
  - eqvinox 6mo ago
    Wait till you find an application that accepts 1.65793 as an IPv4 address. Or 134744072. $ ping -c 1 1.65793 PING 1.65793 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=1.56 ms --- 1.65793 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.560/1.560/1.560/0.000 ms (by the way, this was way less of a dumb peculiarity back when IPv6 was designed)
    - estimator7292 6mo ago
      I damn near have a stroke every time I try to reason about IPv4 addresses as an integer. But hey, I guess four bytes is four bytes no matter how you read them.
  - SkiFire13 6mo ago
    I'm not disagreeing that's a bad aspect of IPv6, I'm just saying that it's not that big of a issue for its adoption.
    - rusk 6mo ago
      I think it’s one of many that indicates the underlying issues for its adoption. It’s a 90s technology, not as much thought was given about how it would be used.
lamonade 6mo ago
how do you encode 128 bits without making a long number? and not using hex?
- b112 6mo ago
  Far easier to use ipv8, which just has 5 octets instead of 4.
  - AndrewDucker 6mo ago
    That still means replacing every part of the chain.
    - b112 6mo ago
      There are lots of legacy things in tcp/ip headers. One of them can be for the extra octlet. When ipv4 legacy flies around, that oclet will be null or 0. The entire internet could route just fine, especially if you put the extra octlet at the end. 1.1.1.1 gets an extra 1.1.1.1.newoctlet. So every existing IP gets a bonus 255 new IPs, and for now, routing of those is hardlocked to that IP, and it works with all legacy gear. In 30 years or something, we can care about the mobility of those new IPs.
      - Dagger2 6mo ago
        You're at the very beginning, baby steps stage of inventing IPv6 there. You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does. Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
        6mo ago
9dev 6mo ago
> The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?
- muvlon 6mo ago
  What problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful. Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
  - 9dev 6mo ago
    DHCP requires explicit configuration; it needs a range that hopefully doesn't conflict with any VPN you use; it needs changes if your range ever gets too small; and it's just another moving part really. With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
    - j16sdiz 6mo ago
      When it fail, you find there is no option to tune its behaviour. Plug in a rough router and see quickly you can find it.
      - 9dev 6mo ago
        What kind of failure are you referring to? What would you want to tune? You can still easily locate all devices on your network.
  - eqvinox 6mo ago
    * privacy addresses are great * deriving additional addresses for specific functions is great (e.g. XLAT464/CLAT) * you don't get collisions when you lose your DHCP lease database * as Brian says, DHCP wasn't quite there yet when IPv6 was designed * ability to proactively change things by sending different RAs (e.g. router or prefix failover, though these don't work as well as one would hope) * ability to encode mnemonic information into those 64 bits (when configuring addresses statically) * optimization for the routing layers in assuming prefixes mostly won't be longer than /64 … and probably 20 others that don't come to mind immediately. I didn't even spend seconds thinking about the ones I listed here.
JumpCrisscross 6mo ago
> What does your ISP support? My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1]. [1] https://test-ipv6.com https://test-ipv6.com
- collabs 6mo ago
  Is it possible that you own your own router and have at some point configured the router to turn up 6 off? I know it is turned off on my router because I had some issues with Verizon ipv6 and tp link in the past.
  - JumpCrisscross 6mo ago
    Good idea–on my list of to-check items.
- mindcrime 6mo ago
  FWIW, I'm also on Spectrum (by virtue of the Time Warner acquisition back in the day) and I get 10/10 on that page. That is, after turning off Firefox "Enhanced Privacy Protection" which actually blocked the page from loading at all for some reason. Got 9/10 using Chrome. Both on Linux.
eqvinox 6mo ago
> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other. You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges. You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.) And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for. > If they’d designed something that was easy to understand, […] I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess. > […] not too hard to implement quickly and easily, […] As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.) > […] expected humans to parse hex […] You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.) Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago. Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?
drob518 6mo ago
I was at some of those IETF meetings in the mid-1990s and attended some early IPv6 working group sessions. We knew the conversion would take time, but I don’t think any of us thought it would be this slow. I was involved with multiple L3 switches and routers from 1997 through 2010. The issue was always that IPv6 basically required lots of boxes in the middle to understand it in order to roll it out, so when would it be commercially necessary? Yes, you can do tunneling and NAT at various points, but it always requires more than just the endpoints. It shows up in DNS and socket APIs. There’s no easy way to determine if a path supports it, and the path can change in an instant due to a route change. All that is very different than SSL or QUIC where only the endpoints have to be involved. That’s why QUIC uses UDP, for instance, so old intermediate devices just see it as a protocol they already know. SSL just assigned port 443 and the “https” protocol in the web URL. If a web client contacts a server on port 443 that doesn’t use SSL, it just fails. To put it another way, the level of the stack that you’re changing matters. SSL and QUIC are really L5+. IPv6 is squarely L3. There are no protocol negotiation mechanism available at L3. So, from a business standpoint, when do you take the hit and integrate it all into the processing pipeline? How do you do that in a way that doesn’t impact your IPv4 forwarding performance, because that’s what the near-term market will judge you on? How do you afford the development and test cost associated with a whole other development (almost double)? If you’re doing software forwarding, the answers are a lot easier. As soon as you’re designing silicon, it’s a lot harder. When you’re under a lot of commercial pressure, it’s difficult to be the one who goes first. And remember that this hardware evolves on roughly 10 year cycles (2 years for design, 3-5 year market sales, 3-5 year depreciation at the customer before they buy new ones). Oh, and customer rollout of IPv6 is a major project with lots of program management and testing, not just buying a box or two. So, yea hindsight is easy. Eventually you get there, but it’s a long road.
gucci-on-fleek 6mo ago
> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs. > GPRS/HSDPA/3G/4G/5G Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.
themafia 6mo ago
> It didn’t take 25 years for SSL. It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed. Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.
- throwawaymobule 6mo ago
  I think most of the web wasn't encrypted by default until letsencrypt came on the scene just over a decade ago. (I remember a few "free cert" offerings that were entirely manual, and cost you $200 if you wanted to revoke a cert) It's firmly the default now, and very odd if a site doesn't default to https.
commandersaki 6mo ago
Yeah the at least 25 years thing is a cop out. The IPng committee specifically chose the protocol that didn't have a transition plan, and today still doesn't have a transition plan. I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.
- Dagger2 6mo ago
  Well, other than the transition plans that it has and still has. The exact same plans that the other options like TUBA had. If you ignore those then sure, it didn't have a plan.
  - commandersaki 6mo ago
    Stomping your foot angrily at ISPs and Internet facing entities to adopt a protocol noone cares and/or getting governments to intervene because you've exhausted all your options and progress is stagnant is not a transition plan, that's a hail mary.
    - Dagger2 6mo ago
      If you can't enforce a flag day then that's all you're left with, isn't it? Other than maybe hacking into people's networks, upgrading them and then somehow preventing them from undoing your work.

SkiFire13 6mo ago

> Instead they expected humans to parse hex, which no one does Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.

rusk 6mo ago
Wait til you’ve got to copy & paste em, or see em comingled with hw addresses
- eqvinox 6mo ago
  Wait till you find an application that accepts 1.65793 as an IPv4 address. Or 134744072. $ ping -c 1 1.65793 PING 1.65793 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=1.56 ms --- 1.65793 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.560/1.560/1.560/0.000 ms (by the way, this was way less of a dumb peculiarity back when IPv6 was designed)
  - estimator7292 6mo ago
    I damn near have a stroke every time I try to reason about IPv4 addresses as an integer. But hey, I guess four bytes is four bytes no matter how you read them.
- SkiFire13 6mo ago
  I'm not disagreeing that's a bad aspect of IPv6, I'm just saying that it's not that big of a issue for its adoption.
  - rusk 6mo ago
    I think it’s one of many that indicates the underlying issues for its adoption. It’s a 90s technology, not as much thought was given about how it would be used.

lamonade 6mo ago

how do you encode 128 bits without making a long number? and not using hex?

b112 6mo ago
Far easier to use ipv8, which just has 5 octets instead of 4.
- AndrewDucker 6mo ago
  That still means replacing every part of the chain.
  - b112 6mo ago
    There are lots of legacy things in tcp/ip headers. One of them can be for the extra octlet. When ipv4 legacy flies around, that oclet will be null or 0. The entire internet could route just fine, especially if you put the extra octlet at the end. 1.1.1.1 gets an extra 1.1.1.1.newoctlet. So every existing IP gets a bonus 255 new IPs, and for now, routing of those is hardlocked to that IP, and it works with all legacy gear. In 30 years or something, we can care about the mobility of those new IPs.
    - Dagger2 6mo ago
      You're at the very beginning, baby steps stage of inventing IPv6 there. You aren't the first person to come up with the idea of adding extra bits to IP addresses to make them longer. The problem isn't finding somewhere to stash the extra bits in the packet format (which is trivial; you can simply set the next-protocol field to a special value and then put the bits at the start of the payload), it's getting all software to use those extra bits -- and getting that to work requires doing all of the new AF family, new sockaddr struct, new DNS records, dual stack/translation/tunnels etc etc that v6 does. Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through.
      - 6mo ago

9dev 6mo ago

> The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?

muvlon 6mo ago
What problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful. Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
- 9dev 6mo ago
  DHCP requires explicit configuration; it needs a range that hopefully doesn't conflict with any VPN you use; it needs changes if your range ever gets too small; and it's just another moving part really. With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
  - j16sdiz 6mo ago
    When it fail, you find there is no option to tune its behaviour. Plug in a rough router and see quickly you can find it.
    - 9dev 6mo ago
      What kind of failure are you referring to? What would you want to tune? You can still easily locate all devices on your network.
- eqvinox 6mo ago
  * privacy addresses are great * deriving additional addresses for specific functions is great (e.g. XLAT464/CLAT) * you don't get collisions when you lose your DHCP lease database * as Brian says, DHCP wasn't quite there yet when IPv6 was designed * ability to proactively change things by sending different RAs (e.g. router or prefix failover, though these don't work as well as one would hope) * ability to encode mnemonic information into those 64 bits (when configuring addresses statically) * optimization for the routing layers in assuming prefixes mostly won't be longer than /64 … and probably 20 others that don't come to mind immediately. I didn't even spend seconds thinking about the ones I listed here.

JumpCrisscross 6mo ago

> What does your ISP support? My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1]. [1] https://test-ipv6.com https://test-ipv6.com

collabs 6mo ago
Is it possible that you own your own router and have at some point configured the router to turn up 6 off? I know it is turned off on my router because I had some issues with Verizon ipv6 and tp link in the past.
- JumpCrisscross 6mo ago
  Good idea–on my list of to-check items.
mindcrime 6mo ago
FWIW, I'm also on Spectrum (by virtue of the Time Warner acquisition back in the day) and I get 10/10 on that page. That is, after turning off Firefox "Enhanced Privacy Protection" which actually blocked the page from loading at all for some reason. Got 9/10 using Chrome. Both on Linux.

eqvinox 6mo ago

> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other. You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges. You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.) And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for. > If they’d designed something that was easy to understand, […] I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess. > […] not too hard to implement quickly and easily, […] As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.) > […] expected humans to parse hex […] You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.) Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago. Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?

drob518 6mo ago

I was at some of those IETF meetings in the mid-1990s and attended some early IPv6 working group sessions. We knew the conversion would take time, but I don’t think any of us thought it would be this slow. I was involved with multiple L3 switches and routers from 1997 through 2010. The issue was always that IPv6 basically required lots of boxes in the middle to understand it in order to roll it out, so when would it be commercially necessary? Yes, you can do tunneling and NAT at various points, but it always requires more than just the endpoints. It shows up in DNS and socket APIs. There’s no easy way to determine if a path supports it, and the path can change in an instant due to a route change. All that is very different than SSL or QUIC where only the endpoints have to be involved. That’s why QUIC uses UDP, for instance, so old intermediate devices just see it as a protocol they already know. SSL just assigned port 443 and the “https” protocol in the web URL. If a web client contacts a server on port 443 that doesn’t use SSL, it just fails. To put it another way, the level of the stack that you’re changing matters. SSL and QUIC are really L5+. IPv6 is squarely L3. There are no protocol negotiation mechanism available at L3. So, from a business standpoint, when do you take the hit and integrate it all into the processing pipeline? How do you do that in a way that doesn’t impact your IPv4 forwarding performance, because that’s what the near-term market will judge you on? How do you afford the development and test cost associated with a whole other development (almost double)? If you’re doing software forwarding, the answers are a lot easier. As soon as you’re designing silicon, it’s a lot harder. When you’re under a lot of commercial pressure, it’s difficult to be the one who goes first. And remember that this hardware evolves on roughly 10 year cycles (2 years for design, 3-5 year market sales, 3-5 year depreciation at the customer before they buy new ones). Oh, and customer rollout of IPv6 is a major project with lots of program management and testing, not just buying a box or two. So, yea hindsight is easy. Eventually you get there, but it’s a long road.

gucci-on-fleek 6mo ago

> It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs. > GPRS/HSDPA/3G/4G/5G Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.

themafia 6mo ago

> It didn’t take 25 years for SSL. It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed. Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.

throwawaymobule 6mo ago
I think most of the web wasn't encrypted by default until letsencrypt came on the scene just over a decade ago. (I remember a few "free cert" offerings that were entirely manual, and cost you $200 if you wanted to revoke a cert) It's firmly the default now, and very odd if a site doesn't default to https.

commandersaki 6mo ago

Yeah the at least 25 years thing is a cop out. The IPng committee specifically chose the protocol that didn't have a transition plan, and today still doesn't have a transition plan. I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.

Dagger2 6mo ago
Well, other than the transition plans that it has and still has. The exact same plans that the other options like TUBA had. If you ignore those then sure, it didn't have a plan.
- commandersaki 6mo ago
  Stomping your foot angrily at ISPs and Internet facing entities to adopt a protocol noone cares and/or getting governments to intervene because you've exhausted all your options and progress is stagnant is not a transition plan, that's a hail mary.
  - Dagger2 6mo ago
    If you can't enforce a flag day then that's all you're left with, isn't it? Other than maybe hacking into people's networks, upgrading them and then somehow preventing them from undoing your work.