3 ms·

>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, n

>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.