4 ms·

The biggest problem with ipv6 right now is that the DNS record system needs to be updated to support both simultaneously. Right now, it is necessary to perform

The biggest problem with ipv6 right now is that the DNS record system needs to be updated to support both simultaneously. Right now, it is necessary to perform the AAAA lookup alongside the A lookup which doubles the workload on the DNS. Also, ipv6 coverage is still spotty enough that it is sometimes more efficient to open both ipv4 and ipv6 in parallel in order to pick the one which performs better. The problem is that websites will, for the foreseeable future, have to be accessible via ipv4 else suffer a significant reduction in traffic. The issues that I've mentioned above are the reasons why nobody is currently rushing to implement ipv6. Depending on what websites you use, as little as 20% might be accessible via ipv6. This will hold true, I think, for 5 to 10 years. I don't believe that ipv4 will go away. One reason is because ipv6 is unwieldly in comparison. For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4. Personally, I have a real beef with the use of the colon as a separator. My prediction is that, as ipv6 becomes more endemic on the Internet back-end and the pressure on the ipv4 address space eases, then ipv4 addressing will become MORE attractive on the Internet front-end (meaning the consumer).

Dagger2 3y ago
That's really not the biggest issue. DNS servers can handle this level of load just fine. People throwing out excuse after excuse (frequently wrong or ill-informed) for not doing v6 is a bigger issue. > For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4 You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. Hex is an option, and so is combining fields. You can write HN's IP as 0321.216.230.240, or 0321.216.0xe6.240. Or 0xd1.216.0163360. There's about 40 different combinations like this. v6 clearly defines a canonical form, and doesn't have as much possible variation outside of it. > Personally, I have a real beef with the use of the colon as a separator. It had to be changed from . to avoid ambiguity with DNS. It also allows writing the right-hand 32 bits as a v4 literal (e.g. 64:ff9b::209.216.230.240 -- fortunately only in this form and not all of the other forms v4 has) which is convenient sometimes. Given their existing use in other networking protocols and things like MAC addresses, colons seem like the obvious alternative.
- 8chanAnon 3y ago
  >You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. That depends on the platform (and, no, leading zeroes are not legal). I work with Node.js and leading zeroes in an ipv4 address will be correctly rejected. There is no chance of mistaking 127.00.0.01 for 127.0.0.1 (the former will fail the net.isIP test). With ipv6, Node is quite forgiving and this annoys me. Without deconstructing and reconstructing the address in proper canonical form, it is difficult to tell the difference between identical addresses due to the presence of extra zeroes (they will pass the net.isIP test). Unfortunately, Node does not include a method for normalizing an address.
  - Dagger2 3y ago
    $ ping 0000000000321.216.230.240 PING 0000000000321.216.230.240 (209.216.230.240) 56(84) bytes of data. 64 bytes from 209.216.230.240: icmp_seq=1 ttl=46 time=142 ms Platform-specific syntax, excellent. That sure makes it sound more consistent. You're right that you need to canonicalize addresses as part of comparing their textual forms. It's well-documented -- at least in v6 -- that you need to do that. > Unfortunately, Node does not include a method for normalizing an address. That sounds like a Node problem. In C you can do it via getnameinfo(getaddrinfo()) or inet_ntop(inet_pton()).
    - zimpenfish 3y ago
      $ ping 0010.000010.0000000010.000000000000000010 PING 0010.000010.0000000010.000000000000000010 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.48 ms Oh the humanity.

Dagger2 3y ago

That's really not the biggest issue. DNS servers can handle this level of load just fine. People throwing out excuse after excuse (frequently wrong or ill-informed) for not doing v6 is a bigger issue. > For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4 You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. Hex is an option, and so is combining fields. You can write HN's IP as 0321.216.230.240, or 0321.216.0xe6.240. Or 0xd1.216.0163360. There's about 40 different combinations like this. v6 clearly defines a canonical form, and doesn't have as much possible variation outside of it. > Personally, I have a real beef with the use of the colon as a separator. It had to be changed from . to avoid ambiguity with DNS. It also allows writing the right-hand 32 bits as a v4 literal (e.g. 64:ff9b::209.216.230.240 -- fortunately only in this form and not all of the other forms v4 has) which is convenient sometimes. Given their existing use in other networking protocols and things like MAC addresses, colons seem like the obvious alternative.

8chanAnon 3y ago
>You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. That depends on the platform (and, no, leading zeroes are not legal). I work with Node.js and leading zeroes in an ipv4 address will be correctly rejected. There is no chance of mistaking 127.00.0.01 for 127.0.0.1 (the former will fail the net.isIP test). With ipv6, Node is quite forgiving and this annoys me. Without deconstructing and reconstructing the address in proper canonical form, it is difficult to tell the difference between identical addresses due to the presence of extra zeroes (they will pass the net.isIP test). Unfortunately, Node does not include a method for normalizing an address.
- Dagger2 3y ago
  $ ping 0000000000321.216.230.240 PING 0000000000321.216.230.240 (209.216.230.240) 56(84) bytes of data. 64 bytes from 209.216.230.240: icmp_seq=1 ttl=46 time=142 ms Platform-specific syntax, excellent. That sure makes it sound more consistent. You're right that you need to canonicalize addresses as part of comparing their textual forms. It's well-documented -- at least in v6 -- that you need to do that. > Unfortunately, Node does not include a method for normalizing an address. That sounds like a Node problem. In C you can do it via getnameinfo(getaddrinfo()) or inet_ntop(inet_pton()).
  - zimpenfish 3y ago
    $ ping 0010.000010.0000000010.000000000000000010 PING 0010.000010.0000000010.000000000000000010 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.48 ms Oh the humanity.