7 ms·

You hit on the problem with IPv6 designers- they took a solution (bigger address space) to a problem (not enough addresses) and they added a bunch of other chan

You hit on the problem with IPv6 designers- they took a solution (bigger address space) to a problem (not enough addresses) and they added a bunch of other changes (No NAT, No DHCP, ARP vs NDP, weird address scheme, etc) that arguably made things worse. Then they wonder why people aren’t adopting it. (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.)

lwf 8y ago
> (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.) Can you expand what you mean by this? I'm drawing a blank.
- geofft 8y ago
  I assume they're referring to the 3-month certificate lifetimes, which all but force you to automate certificate renewal, whereas the 1+-year certificates of the past let you treat it as manual sysadmin work. This was based on a belief that automating certificate renewals is the right thing to do. Still, LE seems to be wildly more successful than IPv6. I suspect in part that's because they were more technically right - or at least it's more feasible to add the automation than to rearchitect an IPv4 network - and in part because you can do manual certificate updates. (For complicated and entirely uninteresting reasons, I do manual certificate updates on my personal website every three months using certbot certonly --manual and scp, and it works.) I'm also way more personally sympathetic to LE because they're pushing the change for security reasons (revocation doesn't work, so we need to move to very short-lived certs) and not mere elegance ones. Rolling out IPv6 as designed brings no security benefits either to the user or to the ecosystem, and carries quite a few potential security risks.
  - saurik 8y ago
    I think another big thing with Let's Encrypt is that they are free while their legacy competitors cost money, which is on the brutal end of incentives.
  - dane-pgp 8y ago
    It's worth pointing out, in terms of LE being "wildly more successful", that this represents a single organisation, with a security critical role on the web, approaching a monopoly. That's actually a worse situation than if 100% of hosts on the internet supported (different but compatible implementations of) IPv6. Here is a chart showing the trend for LE marketshare (under the IdenTrust root): https://w3techs.com/technologies/history_overview/ssl_certificate https://w3techs.com/technologies/history_overview/ssl_certif... I really support LE's mission, and celebrate their success, but would feel more comfortable if a separate organisation tried replicating what they had done, running the same service but with distinct personnel and assets. For reference, here is another chart showing the run down of the remaining IPv4 supply: http://www.potaroo.net/tools/ipv4/plotend.png http://www.potaroo.net/tools/ipv4/plotend.png
sopooneo 8y ago
A successful solution would have pissed a lot of people off. Every faction that had just one little enhancement, that could by itself probably have been okay, would have to have been told no. That's a hard thing to do. Sometimes you have to say "yes" to one powerful faction, regardless of whether their request is technically a great idea, in order to get enough political capital to fend off everyone else.
zamadatix 8y ago
No NAT/DHCP is an implementation choice not a protocol limitation. NDP is the only real "you must do <x>" in your list that is true. The address schemes are either straight from v4 (link local, private, loopback, public, multicast), optional (temp address), or just best practices (/64s)
- geofft 8y ago
  Your ability to implement this as a network operator is also constrained by what your network devices and client devices support. Since there exist devices that don't support DHCPv6 and only support SLAAC, /64s turn from a best practice to a requirement. Since everyone made fun of NAT, NAT66 implementations did not exist until very recently and they're still uncommon, even though it's been technically obvious what to do since day one. You can implement IPv6 by ditching all your network hardware, installing commodity Linux boxes, writing some patches to iptables, and insisting that nobody bring Android devices onto your network unless they run your in-house fork of AOSP. I just think most people would not consider that an option in scope.
SamuelAdams 8y ago
I think this is what will cause USB-C to fail. It’s taking a simple problem (allow reversible, higher-bandwidth connections) and making it complex. The latest spec requires encryption. In a cable. Which might be ok for some applications, but certainly not necessary for all items. Now you have so many versions, which may or may not implement a laundry list of features. And people just want simple, no fuss cables.
- AlphaSite 8y ago
  > I think this is what will cause USB-C to fail. I think this ship has sailed. If the alt modes fail, that's fine, but the core spec is fine.
- cesarb 8y ago
  > I think this is what will cause USB-C to fail. It’s taking a simple problem (allow reversible, higher-bandwidth connections) and making it complex. Actually, it's still simple. For devices and hosts using USB 2.0, the only real change with the USB-C connector is a single extra resistor. For devices and hosts using USB 3.x, they only have to detect which of two pins has the resistor on the other side to select which of the two high-bandwidth channels should be used. And there are two main types of cable: USB 2.0 cables and full-featured cables, like the old non-USB-C USB 2.0 and USB 3.x cables. The extra complexity only appears when you want the extra features which are new to USB-C: higher voltage and/or current, alternate modes, using both high-bandwidth channels at the same time (USB 3.2), and so on.

lwf 8y ago

> (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.) Can you expand what you mean by this? I'm drawing a blank.

geofft 8y ago
I assume they're referring to the 3-month certificate lifetimes, which all but force you to automate certificate renewal, whereas the 1+-year certificates of the past let you treat it as manual sysadmin work. This was based on a belief that automating certificate renewals is the right thing to do. Still, LE seems to be wildly more successful than IPv6. I suspect in part that's because they were more technically right - or at least it's more feasible to add the automation than to rearchitect an IPv4 network - and in part because you can do manual certificate updates. (For complicated and entirely uninteresting reasons, I do manual certificate updates on my personal website every three months using certbot certonly --manual and scp, and it works.) I'm also way more personally sympathetic to LE because they're pushing the change for security reasons (revocation doesn't work, so we need to move to very short-lived certs) and not mere elegance ones. Rolling out IPv6 as designed brings no security benefits either to the user or to the ecosystem, and carries quite a few potential security risks.
- saurik 8y ago
  I think another big thing with Let's Encrypt is that they are free while their legacy competitors cost money, which is on the brutal end of incentives.
- dane-pgp 8y ago
  It's worth pointing out, in terms of LE being "wildly more successful", that this represents a single organisation, with a security critical role on the web, approaching a monopoly. That's actually a worse situation than if 100% of hosts on the internet supported (different but compatible implementations of) IPv6. Here is a chart showing the trend for LE marketshare (under the IdenTrust root): https://w3techs.com/technologies/history_overview/ssl_certificate https://w3techs.com/technologies/history_overview/ssl_certif... I really support LE's mission, and celebrate their success, but would feel more comfortable if a separate organisation tried replicating what they had done, running the same service but with distinct personnel and assets. For reference, here is another chart showing the run down of the remaining IPv4 supply: http://www.potaroo.net/tools/ipv4/plotend.png http://www.potaroo.net/tools/ipv4/plotend.png

sopooneo 8y ago

A successful solution would have pissed a lot of people off. Every faction that had just one little enhancement, that could by itself probably have been okay, would have to have been told no. That's a hard thing to do. Sometimes you have to say "yes" to one powerful faction, regardless of whether their request is technically a great idea, in order to get enough political capital to fend off everyone else.

zamadatix 8y ago

No NAT/DHCP is an implementation choice not a protocol limitation. NDP is the only real "you must do <x>" in your list that is true. The address schemes are either straight from v4 (link local, private, loopback, public, multicast), optional (temp address), or just best practices (/64s)

geofft 8y ago
Your ability to implement this as a network operator is also constrained by what your network devices and client devices support. Since there exist devices that don't support DHCPv6 and only support SLAAC, /64s turn from a best practice to a requirement. Since everyone made fun of NAT, NAT66 implementations did not exist until very recently and they're still uncommon, even though it's been technically obvious what to do since day one. You can implement IPv6 by ditching all your network hardware, installing commodity Linux boxes, writing some patches to iptables, and insisting that nobody bring Android devices onto your network unless they run your in-house fork of AOSP. I just think most people would not consider that an option in scope.

SamuelAdams 8y ago

I think this is what will cause USB-C to fail. It’s taking a simple problem (allow reversible, higher-bandwidth connections) and making it complex. The latest spec requires encryption. In a cable. Which might be ok for some applications, but certainly not necessary for all items. Now you have so many versions, which may or may not implement a laundry list of features. And people just want simple, no fuss cables.

AlphaSite 8y ago
> I think this is what will cause USB-C to fail. I think this ship has sailed. If the alt modes fail, that's fine, but the core spec is fine.
cesarb 8y ago
> I think this is what will cause USB-C to fail. It’s taking a simple problem (allow reversible, higher-bandwidth connections) and making it complex. Actually, it's still simple. For devices and hosts using USB 2.0, the only real change with the USB-C connector is a single extra resistor. For devices and hosts using USB 3.x, they only have to detect which of two pins has the resistor on the other side to select which of the two high-bandwidth channels should be used. And there are two main types of cable: USB 2.0 cables and full-featured cables, like the old non-USB-C USB 2.0 and USB 3.x cables. The extra complexity only appears when you want the extra features which are new to USB-C: higher voltage and/or current, alternate modes, using both high-bandwidth channels at the same time (USB 3.2), and so on.