Error if IPv6 address is valid but didn't match recommendation

[jojoob]

I stumbled across update-systemd-resolved's accuracy in following RFC5952 (A Recommendation for IPv6 Address Text Representation). Section 4.1 claims 'single 16- bit 0000 field MUST be represented as 0'.

update-systemd-resolved exits with an error if this recommendation is violated. This completely prevents openvpn from establishing the connection.

openvpn[5638]: <8>Sep  3 15:51:06 update-systemd-resolved: 'fd00:ff:0:2:301:64::3' is not a valid IPv6 address: single '0' fields should not be compressed
ovpn-client[5638]: WARNING: Failed running command (--up/--down): external program exited with error status: 1
ovpn-client[5638]: Exiting due to fatal error

For me it was not an expected behaviour that a program exits with an error if an IP address is valid but just didn't match a recommendation. I think it would be better to just log a warning instead exit with error.

[xenohunter]

I get the same error while launching openvpn:

Fri May  1 12:09:41 2020 TUN/TAP device tun0 opened
Fri May  1 12:09:41 2020 TUN/TAP TX queue length set to 100
Fri May  1 12:09:41 2020 /usr/bin/ip link set dev tun0 up mtu 1500
Fri May  1 12:09:41 2020 /usr/bin/ip addr add dev tun0 10.49.0.7/16 broadcast 10.49.255.255
Fri May  1 12:09:41 2020 /usr/bin/ip -6 addr add fd54:20a4:d33b:b10c:18c:31:0:1005/112 dev tun0
Fri May  1 12:09:41 2020 /etc/openvpn/scripts/update-systemd-resolved tun0 1500 1585 10.49.0.7 255.255.0.0 init
<14>May  1 12:09:41 update-systemd-resolved: Link 'tun0' coming up
<14>May  1 12:09:41 update-systemd-resolved: Adding IPv4 DNS Server 10.49.0.1
<14>May  1 12:09:41 update-systemd-resolved: Adding IPv6 DNS Server fd54:20a4:d33b:b10c:018C:31::1
<8>May  1 12:09:41 update-systemd-resolved: 'fd54:20a4:d33b:b10c:018C:31::1' is not a valid IPv6 address: single '0' fields should not be compressed
Fri May  1 12:09:41 2020 WARNING: Failed running command (--up/--down): external program exited with error status: 1
Fri May  1 12:09:41 2020 Exiting due to fatal error

Meanwhile, are there any workarounds? Maybe some flag to openvpn which would make it strictly follow the RFC? Though I doubt it as the error follows the /usr/bin/ip -6 addr add fd54:20a4:d33b:b10c:18c:31:0:1005/112 dev tun0 command, thus making it dependent on ip.

[pastif]

It does seem like it would be better for update-systemd-resolved not to fail for valid addresses that don't conform to the guidelines in the RFC

I figured out a hacky workaround that shells out to python (tested on 3.8 but should work on 3.3 or later). Python's ipaddress module seems to automatically fix valid addresses so they follow the RFC. To do this just change the start of the process_dns_ipv6 function from

process_dns_ipv6() {
  local address=$1
  shift

to

process_dns_ipv6() {
  local address=$(python3 -c "from ipaddress import IPv6Address; a = IPv6Address('$1'); print(a, end='')")
  shift

Or for a slightly more robust version this also worked for me. I'm not that familiar with the intricacies of bash so not sure if it's as portable.

process_dns_ipv6() {
  local address=$(python3 <<EOF
from ipaddress import IPv6Address, AddressValueError
try:
    address = IPv6Address('$1')
except AddressValueError:
    address = '$1'
print(address, end='')
EOF
)
  shift

This makes the invalid_ipv6 tests fail, but I don't think it will cause any problems with valid addresses. The second version passes a few more tests than the first. Obviously it's not a proper solution but hopefully it'll be useful for people running into this issue.

[xenohunter]

@pastif, thank you! I guess it should have worked for me as well, though I'm not able to test it anymore. I've switched to a whole different solution and screwed my old script irreversibly.

[piotr-dobrogost]

@xenohunter What's your whole different solution if I may ask?

[xenohunter]

@piotr-dobrogost, sure! I use ProtonVPN, so when openvpn had started to fail I promptly switched to protonvpn-cli-ng which seems to be more comfortable to use, too.