IPv6 addresses do not follow RFC 5952

[alin-at-dfinity]

Compressed IPv6 addresses are formatted as per RFC 1884 section 2.2, which is arguably unclear about whether a single zero should be replaced by ::. (Even though RFC 1884 does say "[the] use of "::" indicates multiple groups of 16-bits of zeros", with the most common interpretation of "multiple" being "> 1".)

However RFC 1884 was obsoleted by successive versions of "IP Version 6 Addressing Architecture", with the latest being RFC 4291 (which explicitly allows for both :0: and ::). But RFC 4291 was (according to IETF) updated by (among others) RFC 5952 and while the latter is titled "Recommendation", in section 4.2.2 it explicitly disallows using :: to replace a single zero:

   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
   2001:db8::1:1:1:1:1 is not correct.

It would seem to me like the only code change necessary in ipv6calc would be to bump this >= 0 test to >= 1. (And maybe simplify the logic a bit. And rename the file from librfc1884.c to librfc5952.c.)

---

For context, we are running into issues string matching (within Prometheus labels) IPv6 addresses generated by Rust library code (that implements RFC 5952) with ones generated by ipv6calc for about half the IP addresses we use (which have exactly one zero segment). And make it impossible to match the instance label of our process with that of node-exporter, so we're "missing" machine metrics for about half our instances.

[pbiering]

Good catch, will investigate next days, will keep you updated.

[alin-at-dfinity]

Thank you, much appreciated.

[pbiering]

fix according to your suggestion + adjustments of various tests, if able, please test https://github.com/pbiering/ipv6calc/tree/fix-issue-28

[alin-at-dfinity]

Wow, that was quick!

Haven't had a chance to build and test it, but the code and test changes LGTM. Thank you!

[pbiering]

Haven't had a chance to build and test it, but the code and test changes LGTM. Thank you!

Which distro are you using? If Enterprise Linux, I can supply a test RPM, otherwise I try static binary from ftp://ftp.bieringer.de/pub/tmp/

[alin-at-dfinity]

I'm running Ubuntu. But I can't seem to get to ftp://ftp.bieringer.de/pub/tmp/. Chrome just hangs and using the ftp command I get all kinds of combinations of 200 PORT command successful, 250 CWD command successful and then 425 Unable to build data connection: Connection refused and 450 LIST: Connection refused.

230 Anonymous access granted, restrictions apply
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /pub/tmp/
250 CWD command successful
ftp> dir
200 PORT command successful
425 Unable to build data connection: Connection refused
ftp> ls
450 LIST: Connection refused

[pbiering]

FTP active mode is no longer supported proper, please use passive mode with such legacy client (modern Linux clients use passive mode by default).

Or use wget ftp://ftp.bieringer.de/pub/tmp/ipv6calc-static-fix-issue-28

[alin-at-dfinity]

Thanks, tested with a couple of our IPv6 addresses and everything works as expected.

$ ./ipv6calc-static-fix-issue-28  -q --in 'prefix+mac' "2b04:9dc0:0:108::" "50:00:8c:ff:fe:29" --printcompressed
2b04:9dc0:0:108:5200:8cff:feff:fe29
$ ./ipv6calc-static-fix-issue-28  -q --in 'prefix+mac' "2b04:9dc0:0:108::" "50:00:8c:ff:fe:29" --printuncompressed
2b04:9dc0:0:108:5200:8cff:feff:fe29

[pbiering]

thank you for confirmation fixed with https://github.com/pbiering/ipv6calc/commit/47ef79eb026dc6d5e233474cb73c2dd33cf2d4d2 expect soon a new release

[pbiering]

Here you can fetch updated RPMs for Enterprise Linux / Fedora: https://koji.fedoraproject.org/koji/packageinfo?packageID=366