DHCPv6 with networkd not triggering

1

I’m struggeling to get DHCPv6 active with networkd. I have the following /etc/systemd/network/11-wan.network config:

[Match]
Name=wan

[Network]
DHCP=yes
Domains=tanso.net
IPv6AcceptRA=yes

[DHCPv4]
Hostname=janfrode
UseHostname=no

[IPv6AcceptRA]
UseDNS=no
DHCPv6Client=always

[DHCPv6]
PrefixDelegationHint=::/56
ForceDHCPv6PDOtherInformation=yes
UseHostname=no
UseDNS=no
UseNTP=no

but I don’t see any DHCPv6 requests. All I see are these:

[nix-shell:~]# tshark -i wan -n  '(udp port 546 and port 547)'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wan'
    1 0.000000000 fe80::eea8:6bff:fef4:8183 → ff02::1:2    DHCPv6 138 Solicit XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    2 0.003265084 fe80::202:ff:fe01:5 → fe80::eea8:6bff:fef4:8183 DHCPv6 104 Advertise XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    3 113.528403269 fe80::eea8:6bff:fef4:8183 → ff02::1:2    DHCPv6 138 Solicit XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    4 113.531804014 fe80::202:ff:fe01:5 → fe80::eea8:6bff:fef4:8183 DHCPv6 104 Advertise XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    5 223.373493365 fe80::eea8:6bff:fef4:8183 → ff02::1:2    DHCPv6 138 Solicit XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    6 223.376054151 fe80::202:ff:fe01:5 → fe80::eea8:6bff:fef4:8183 DHCPv6 104 Advertise XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413
    7 337.278429055 fe80::eea8:6bff:fef4:8183 → ff02::1:2    DHCPv6 138 Solicit XID: 0x3f9d17 CID: 00020000ab119ac9c686d8ddf413

Any ideas for why networkd isn’t requesting DHCPv6 ?

2

Even with a mostly empty config, all I see is the two above packets repeating.

[root@hjemmerouter:/etc/nixos/networking]# grep -v ^# /etc/systemd/network/11-wan.network
[Match]
Name=wan

[Network]
DHCP=yes
Domains=tanso.net

[DHCPv4]
Hostname=janfrode
UseHostname=no
3

And all I see in the systemd-networkd log is the following:

Feb 25 21:52:22 hjemmerouter systemd-networkd[8966]: wan: Link UP
Feb 25 21:52:22 hjemmerouter systemd-networkd[8966]: wan: Gained carrier
Feb 25 21:52:22 hjemmerouter systemd-networkd[8966]: wan: Gained IPv6LL
Feb 25 21:52:25 hjemmerouter systemd-networkd[8966]: wan: DHCPv4 address 81.166.85.226/20 via 81.166.80.1
Feb 25 21:54:44 hjemmerouter systemd-networkd[8966]: wan: DHCP lease lost
Feb 25 21:54:44 hjemmerouter systemd-networkd[8966]: wan: DHCPv6 lease lost
Feb 25 21:54:45 hjemmerouter systemd-networkd[10190]: wan: Link UP
Feb 25 21:54:45 hjemmerouter systemd-networkd[10190]: wan: Gained carrier
Feb 25 21:54:45 hjemmerouter systemd-networkd[10190]: wan: Gained IPv6LL
Feb 25 21:54:50 hjemmerouter systemd-networkd[10190]: wan: DHCPv4 address 81.166.85.226/20 via 81.166.80.1

4

Before switching to networkd, this seems to have been working:

2022-02-18T19:30:57.097779+01:00 hjemmerouter dhcpcd[1000]: wan: adding address 2a01:798:100:900:186a:9fd7:e249:b853/128
2022-02-18T20:41:22.967840+01:00 hjemmerouter dhcpcd[1000]: wan: deleting address 2a01:798:100:900:186a:9fd7:e249:b853/128
2022-02-18T20:50:56.390567+01:00 hjemmerouter dhcpcd[3968]: wan: ADV 2a01:798:100:900:186a:9fd7:e249:b853/128 from fe80::202:ff:fe01:5
2022-02-18T20:50:56.402353+01:00 hjemmerouter dhcpcd[3968]: wan: adding address 2a01:798:100:900:186a:9fd7:e249:b853/128
5

Enabled SYSTEMD_LOG_LEVEL = “debug”;

 systemd-networkd[11000]: wan: RADV: Next Router Advertisement in 3min 38s
 systemd-networkd[11000]: wan: NDISC: Received Router Advertisement: flags MANAGED preference medium lifetime 1800 sec
 systemd-networkd[11000]: wan: NDISC: Invoking callback for 'router' event.
 systemd-networkd[11000]: wan: Acquiring DHCPv6 lease on NDisc request
 systemd-networkd[11000]: wan: Requesting route: dst: n/a, src: n/a, gw: fe80::202:ff:fe01:5, prefsrc: n/a, scope: global, table: main(254), proto: ra, type: unicast, nexthop: 0, priority: 1024
 systemd-networkd[11000]: wan: Setting NDisc routes.
 systemd-networkd[11000]: wan: Configuring route: dst: n/a, src: n/a, gw: fe80::202:ff:fe01:5, prefsrc: n/a, scope: global, table: main(254), proto: ra, type: unicast, nexthop: 0, priority: 1024
 systemd-networkd[11000]: wan: NDisc routes set.
 systemd-networkd[11000]: wan: Removing old NDisc information obtained from fe80::202:ff:fe01:5.
 systemd-networkd[11000]: wan: DHCPv6 client: Sent SOLICIT
 systemd-networkd[11000]: wan: DHCPv6 client: Next retransmission in 31s
 systemd-networkd[11000]: wan: DHCPv6 client: ADVERTISE Status Unspecified failure
 systemd-networkd[11000]: wan: DHCPv6 client: Recv ADVERTISE

Wonder what the Unspecified failure is…

6

I’ve also had problems with SLAAC in the past. For me it turned out that the DHCP server was expecting the interface DUID to be based on link-layer-time instead of the default machine-id. Maybe this helps.

# /etc/systemd/networkd.conf.d/10-duid-llt.conf:
[DHCP]
DUIDType=link-layer-time
7

I use systemd-networkd on all my Linux systems. My router needs to use DHCPv6 for getting both an IP and a prefix, so it should work.

Are you using a firewall, and do you have the appropriate ports open? Unlike DHCPv4, you have to make sure the ports are open for the interface to receive DHCPv6 responses. I’ve attached my nftables rules below in case those are any help.

table inet filter {
  chain input {
    iifname @interface@ ip6 daddr fe80::/64 udp dport dhcpv6-client accept
  }
}
8

Link-layer-time and link-layer also failed, but DUIDType=uuid in the [DHCPv6] section worked!

Thank you!

Quite weird to see that I was getting “Unspecified failure” from the server with link-layer address plus time in client identifier, when that’s what it’s using in the server identifier…

    Server Identifier
        Option: Server Identifier (2)
        Length: 14
        DUID: 0001000119af6056001a4aa88e40
        DUID Type: link-layer address plus time (1)
        Hardware type: Ethernet (1)
        DUID Time: Aug 27, 2013 15:04:22.000000000 CEST
        Link-layer address: 00:1a:4a:a8:8e:40
9

This worked for a day, then broke again… Looks like DUIDType wasn’t really the issue… It’s the ISPs DHCP relay agent that’s failing for some unknown reason. The issue is being debugged here.