5 ms·

Ah, where to start ... 128-bit addresses are annoyingly huge. 64 bits would have been enough. Even 48 bits gives you 64 thousand times the ipv4 address space.

Ah, where to start ... 128-bit addresses are annoyingly huge. 64 bits would have been enough. Even 48 bits gives you 64 thousand times the ipv4 address space. 64 bits gives you 4 billion times the ipv4 address space. In practice the 128-bit address space has been used as wastefully as it allows e.g. giving a whole /64 to a single server (4 billion ipv4 internets to just a single server!) Link-local addresses being automatically assigned to every interface, as they are with ipv6 (fe80::xxxx:xxxx:xxxx:xxxx) means that you need to use an interface index or name to distinguish them, so now addresses sometimes need a "%XX" added on the end, e.g. fe80::1ff:fe23:4567:890a%eth2 (this is specific to the source machine, not dest ...) IPv6 was originally designed to not have DHCP, but in practice we still need DHCP (DHCPv6) in most cases. There were a bunch of schemes to try to bootstrap ipv6 adoption and they all made it worse. Way back in the 2000s my cable company had some 6to4 servers that worked. Then later there was "teredo" tunneling included in windows vista I think. And there were more. They're all pretty much forgotten now. The problem was that they gave some percent of consumer computers (maybe 2%? maybe 5%?) a false impression of working ipv6, and these computers would hang when trying to access websites that advertised ipv6 addresses in dns responses. So, many websites that had ipv6 at one point, removed it, for many years, until late 2010s ("ipv6 day" etc). This was fixed with the "happy eyeballs" algorithm and other tricks like not returning ipv6 addresses from dns requests made over ipv4 (not sure how widely this was done, but it was done by some significant number of ISPs). Anyway this set back adoption by 10 years probably. There was even a problem where linux had a sysctl option to automatically listen on a "mapped" ipv6 address whenever a process listened on an ipv4 address, this was automatically enabled on some popular linux distros. Later, when the process tried to explicitly listen on a port on ipv6, it would fail because something was already listening on that port on the wildcard address. So companies had to figure out this issue and disable that sysctl option - but, again, the typical response was "screw it just disable ipv6 everywhere". I'm typing this from a corporate laptop with ipv6 explicitly disabled even though my current network supports it, because the required corporate VPN doesn't support ipv6. Today.

RamRodification 3y ago
> "screw it just disable ipv6 everywhere" Troubleshooting step #1. Sad (reasonable, but sad).
- iso1631 3y ago
  ipv6 doesn't give most people the business benefits. These are companies that are perfectly happy with on prem rfc1918 addresses and a bit of srcnat, and indeed are likely reducing that space requirement today as more stuff moves into 'the cloud' Why spend money trying to get ipv6 work when your laptops work fine with a 192.168.x.x range
  - simoncion 3y ago
    On the other hand, even something as easy as ULAs would have saved a former employer of mine three+ months of effort in network renumbering (and other directly-related resource management activities (like, suchas, deciding "Is it more trouble to renumber this, or merely turn it off and deal with having a much, much shittier replacement?")) planning after a corporate merger.
    - iso1631 3y ago
      It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network so you'd have to re-number the ipv4 part anyway, and still probably end up with a mess with ipv6.
      - simoncion 3y ago
        > It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network... For the ones that needed Internet access, sure. But, a huge chunk of these machines were machines that never, ever, ever talked outside of the corporate intranet, so they never needed an Internet gateway, and NAT was never an issue. Assigning these boxes an address from a ULA would have worked just fine. > ...you'd have to re-number the ipv4 part anyway, As mentioned above, for the machines that did need to talk to the Internet (which required them to have v4 addresses) yeah, sure. > ...and still probably end up with a mess with ipv6. I don't see how this follows from what you said. The way you generate ULA prefixes means that you're highly unlikely to ever have to renumber ULA-using networks that you want to merge. Do you have specific addressing perils or pitfalls in mind? (Bear in mind that you're talking to someone who has been happily using IPv6 at home for twenty years, and someone who's quite aware that companies like Comcast, T-Mobile, and a bunch of other telecoms run IPv6 on their infrastructure (and often their customer-facing) networks, trouble-free, and have been for many, many years.)
simoncion 3y ago
> I'm typing this from a corporate laptop with ipv6 explicitly disabled even though my current network supports it, because the required corporate VPN doesn't support ipv6. Today. And (today) my (mandatory) corporate VPN doesn't support ipv6, but my both laptop and the VPN work just fine when the machine has one or more IPv6 addresses. I'm having a somewhat difficult time imagining what series of misconfigurations were required to make your corporate network fail in that way. Anyway. I've been using IPv6 continuously (whether via Teredo, an explicitly-configured 6to4 tunnel, or native dual-stack) for (ugh) nearly twenty years. IME, it works fine, really.
warbeforepeace 3y ago
The 128-bit address complaint is short sited. What does it really matter if the addresses are 128-bit. It ensures we are able to use this protocol for decades. IPv4 space was used wastefully too when it was plentiful. That will correct itself when and if IPv6 addresses become constrained. I don't really understand your complaint about link-local addresses and why its a real problem. The whole bootstrap ipv6 adoption stuff was a mess. We can agree there. There are plenty of shitty bugs in IPv4 handling that still get released in major platforms. Not sure why the sysctyl thing is hard. Anytime you adopt a new feature, service, or platform it requires some critical thinking.

RamRodification 3y ago

> "screw it just disable ipv6 everywhere" Troubleshooting step #1. Sad (reasonable, but sad).

iso1631 3y ago
ipv6 doesn't give most people the business benefits. These are companies that are perfectly happy with on prem rfc1918 addresses and a bit of srcnat, and indeed are likely reducing that space requirement today as more stuff moves into 'the cloud' Why spend money trying to get ipv6 work when your laptops work fine with a 192.168.x.x range
- simoncion 3y ago
  On the other hand, even something as easy as ULAs would have saved a former employer of mine three+ months of effort in network renumbering (and other directly-related resource management activities (like, suchas, deciding "Is it more trouble to renumber this, or merely turn it off and deal with having a much, much shittier replacement?")) planning after a corporate merger.
  - iso1631 3y ago
    It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network so you'd have to re-number the ipv4 part anyway, and still probably end up with a mess with ipv6.
    - simoncion 3y ago
      > It's almost certain you'd have deployed a dual stack ipv4 and ipv6 internal network... For the ones that needed Internet access, sure. But, a huge chunk of these machines were machines that never, ever, ever talked outside of the corporate intranet, so they never needed an Internet gateway, and NAT was never an issue. Assigning these boxes an address from a ULA would have worked just fine. > ...you'd have to re-number the ipv4 part anyway, As mentioned above, for the machines that did need to talk to the Internet (which required them to have v4 addresses) yeah, sure. > ...and still probably end up with a mess with ipv6. I don't see how this follows from what you said. The way you generate ULA prefixes means that you're highly unlikely to ever have to renumber ULA-using networks that you want to merge. Do you have specific addressing perils or pitfalls in mind? (Bear in mind that you're talking to someone who has been happily using IPv6 at home for twenty years, and someone who's quite aware that companies like Comcast, T-Mobile, and a bunch of other telecoms run IPv6 on their infrastructure (and often their customer-facing) networks, trouble-free, and have been for many, many years.)

simoncion 3y ago

> I'm typing this from a corporate laptop with ipv6 explicitly disabled even though my current network supports it, because the required corporate VPN doesn't support ipv6. Today. And (today) my (mandatory) corporate VPN doesn't support ipv6, but my both laptop and the VPN work just fine when the machine has one or more IPv6 addresses. I'm having a somewhat difficult time imagining what series of misconfigurations were required to make your corporate network fail in that way. Anyway. I've been using IPv6 continuously (whether via Teredo, an explicitly-configured 6to4 tunnel, or native dual-stack) for (ugh) nearly twenty years. IME, it works fine, really.

warbeforepeace 3y ago

The 128-bit address complaint is short sited. What does it really matter if the addresses are 128-bit. It ensures we are able to use this protocol for decades. IPv4 space was used wastefully too when it was plentiful. That will correct itself when and if IPv6 addresses become constrained. I don't really understand your complaint about link-local addresses and why its a real problem. The whole bootstrap ipv6 adoption stuff was a mess. We can agree there. There are plenty of shitty bugs in IPv4 handling that still get released in major platforms. Not sure why the sysctyl thing is hard. Anytime you adopt a new feature, service, or platform it requires some critical thinking.