3 ms·
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-infor
by 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.