[systemd-networkd] IPv6 Prefix Delegation not parsing IA_PD responses from upstream RAs #15375

hermanjustnu · 2020-04-09T10:05:53Z

systemd version the issue has been seen with
systemd 245 (245.2-1ubuntu2)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

Used distribution
Ubuntu Focal Fossa

Expected behaviour you didn't see
No IPv6 addresses assigned on LAN nor WAN interfaces.

Unexpected behaviour you saw
IA_PD parsed correctly and assigned per Prefix Delegation as configured in (wan|lan).network.

Steps to reproduce the problem

# cat wan.network
[Match]
#Name=wan
MACAddress=24:f5:a2:f2:59:a7

[Network]
DHCP=yes

# cat lan.network
[Match]
#Name=lan
MACAddress=dc:a6:32:42:ef:74

[Network]
Address=172.16.1.1/24
IPForward=ipv4
IPMasquerade=yes
IPv6PrefixDelegation=dhcpv6

# ip -6 a
[...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::dea6:32ff:fe42:ef74/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::26f5:a2ff:fef2:59a7/64 scope link
       valid_lft forever preferred_lft forever

systemd-networkd.log
tcpdump-wan.log
tcpdump-lan.log

The text was updated successfully, but these errors were encountered:

ssahani · 2020-04-09T15:45:53Z

If you look closely to the tcpdump it says (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail))

https://tools.ietf.org/html/rfc8415

The client uses the addresses, delegated prefixes, and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail or NoPrefixAvail status code. The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs.

11:46:49.152125 IP6 (flowlabel 0xbd189, hlim 1, next-header UDP (17) payload length: 95) fe80::26f5:a2ff:fef2:59a7.546 > ff02::1:2.547: [bad udp cksum 0x2086 -> 0x6b59!] dhcp6 solicit (xid=1f5179 (rapid-commit) (IA_NA IAID:2705660566 T1:0 T2:0) (Client-FQDN) (IA_PD IAID:2705660566 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers rapid-commit) (client-ID vid 0000ab11c9cdee5a) (elapsed-time 0))
11:46:49.206895 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 193) fe80::ff.547 > fe80::26f5:a2ff:fef2:59a7.546: [udp sum ok] dhcp6 advertise (xid=1f5179 (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:25f8:3000::/56 pltime:54000 vltime:86400)) (client-ID vid 0000ab11c9cdee5a) (server-ID hwaddr/time type 1 time 574437592 005056a8da28) (DNS-server 2001:9b0::53:1 2001:9b0::53:2))
11:46:50.176535 IP6 (flowlabel 0xbd189, hlim 1, next-header UDP (17) payload length: 95) fe80::26f5:a2ff:fef2:59a7.546 > ff02::1:2.547: [bad udp cksum 0x2086 -> 0x0559!] dhcp6 solicit (xid=1f5179 (rapid-commit) (IA_NA IAID:2705660566 T1:0 T2:0) (Client-FQDN) (IA_PD IAID:2705660566 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers rapid-commit) (client-ID vid 0000ab11c9cdee5a) (elapsed-time 102))
11:46:50.208613 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 193) fe80::ff.547 > fe80::26f5:a2ff:fef2:59a7.546: [udp sum ok] dhcp6 advertise (xid=1f5179 (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:25f8:3000::/56 pltime:54000 vltime:86400)) (client-ID vid 0000ab11c9cdee5a) (server-ID hwaddr/time type 1 time 574437592 005056a8da28) (DNS-server 2001:9b0::53:1 2001:9b0::53:2))
11:46:52.154038 IP6 (flowlabel 0xbd189, hlim 1, next-header UDP (17) payload length: 95) fe80::26f5:a2ff:fef2:59a7.546 > ff02::1:2.547: [bad udp cksum 0x2086 -> 0x3f58!] dhcp6 solicit (xid=1f5179 (rapid-commit) (IA_NA IAID:2705660566 T1:0 T2:0) (Client-FQDN) (IA_PD IAID:2705660566 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers rapid-commit) (client-ID vid 0000ab11c9cdee5a) (elapsed-time 300))
11:46:52.207358 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 193) fe80::ff.547 > fe80::26f5:a2ff:fef2:59a7.546: [udp sum ok] dhcp6 advertise (xid=1f5179 (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:25f8:3000::/56 pltime:54000 vltime:86400)) (client-ID vid 0000ab11c9cdee5a) (server-ID hwaddr/time type 1 time 574437592 005056a8da28) (DNS-server 2001:9b0::53:1 2001:9b0::53:2))
11:46:56.075269 IP6 (flowlabel 0xbd189, hlim 1, next-header UDP (17) payload length: 95) fe80::26f5:a2ff:fef2:59a7.546 > ff02::1:2.547: [bad udp cksum 0x2086 -> 0xb756!] dhcp6 solicit (xid=1f5179 (rapid-commit) (IA_NA IAID:2705660566 T1:0 T2:0) (Client-FQDN) (IA_PD IAID:2705660566 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers rapid-commit) (client-ID vid 0000ab11c9cdee5a) (elapsed-time 692))
11:46:56.106842 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 193) fe80::ff.547 > fe80::26f5:a2ff:fef2:59a7.546: [udp sum ok] dhcp6 advertise (xid=1f5179 (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:25f8:3000::/56 pltime:54000 vltime:86400)) (client-ID vid 0000ab11c9cdee5a) (server-ID hwaddr/time type 1 time 574437592 005056a8da28) (DNS-server 2001:9b0::53:1 2001:9b0::53:2))

hermanjustnu · 2020-04-09T15:58:55Z

The client uses the addresses, delegated prefixes, and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail or NoPrefixAvail status code. The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs.

From the logs:
[..](IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:25f8:3000::/56 pltime:54000 vltime:86400))[..]

So there is a IA_PD prefix in the respone? Should not that be used to assign addresses through prefix delegation to the interfaces?

ssahani · 2020-04-09T16:31:50Z

The same can be seen in the tcpdump too. If you read the next part of the RFC "The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs."

hermanjustnu · 2020-04-09T18:54:29Z

I have a Ubiquity commodity router that is connected to the same ISP on another port in the fiber box, that takes the IA_PD supplied /56 prefix, makes a /64 out of it, assigns ::1 to itself, and hand out IPv6 addresses to the LAN clients with SLAAC.

I trying to replicate the same functionality with systemd-networkd, or at least get a /64 from the /56 assigned to the LAN interface.

Reading on page 70 in the RFC:

For each delegated prefix, the client assigns a subnet to each of the links to which the associated interfaces are attached.
When a client subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the client in Figure 1 were delegated 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2001:db8:0:2::/64 for assignment to the two links in the subscriber network.

And under WPD-6 in RFC 7084 (page 12):

If the IPv6 CE router requests both an IA_NA and an IA_PD option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 Advertise/Reply messages, even if the message does not contain any addresses, unless configured to only obtain its WAN IPv6 address via DHCPv6

If I read the tcpdump logs correctly, IA_NA is indeed without any address, but IA_PD does contain one routable prefix. Should IPv6PrefixDelegation=dhcpv6 be used for my usecase, or any other option that I might have missed, or is it a feature request?

ssahani · 2020-04-09T22:30:48Z

All this is valid if you would not have received the status code NoAddrsAvail . You are receiving an advertise with status code option of NoAddrsAvail, indicating no addresses are available.
A CE Router that received the NoAddrsAvail option in the DHCP Advertise will not process the remaining options.

hermanjustnu · 2020-04-11T14:20:50Z

Why is not the NoAddrsAvail for IA_NA discarded, and then the IA_PD processed?

Anyway, if I disable systemd-networkd and use ifupdown interfaces;

iface eth1 inet6 dhcp
    request_prefix 1

dhclient gets a lease of the /56 prefix, and I can assign /64:s to my interfaces:

PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Rebind, 0 ms elapsed.
XMT:  X-- IA_PD a2:f2:59:a7
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAPREFIX 2001:9b1:25f9:3a00::/56
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_PD appended.
XMT: Rebind on eth1, interval 940ms.
RCV: Reply message on eth1 from fe80::ff.
RCV:  X-- IA_PD a2:f2:59:a7
RCV:  | X-- starts 1586613425
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  | | X-- IAPREFIX 2001:9b1:25f9:3a00::/56
RCV:  | | | X-- Preferred lifetime 7200.
RCV:  | | | X-- Max lifetime 78544.
RCV:  X-- Server ID: 00:01:00:01:22:3d:38:d8:00:50:56:a8:da:28
PRC: Bound to lease 00:01:00:01:22:3d:38:d8:00:50:56:a8:da:28.

ssahani · 2020-04-11T14:25:23Z

Please contact dhclient .

hermanjustnu · 2020-04-11T14:28:33Z

I rather use systemd-networkd.

hermanjustnu · 2020-04-11T15:04:58Z

I still don't understand why my use case of DHCP Prefix Delegation as described in RFC 8415 Section 6.3 would not work with my ISP. If I understand your last comment correctly dhclient is not compliant with the RFC? Or why would I contact dhclient?

Anyway, thank you for your time answering my questions.

arvidjaar · 2020-04-12T07:10:18Z

@ssahani

https://tools.ietf.org/html/rfc8415

The client uses the addresses, delegated prefixes, and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail or NoPrefixAvail status code. The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs.

The quoted text does not apply here at all. The Status Code in reply has IA_NA option scope, so the correct behavior is to ignore IA_NA option and continue with the next valid option.

A CE Router that received the NoAddrsAvail option in the DHCP Advertise will not process the remaining options.

Reference please. You were already pointed at RFC 7084 that says exactly the opposite.

While the server may be non-compliant by first setting M bit and then providing no addresses, it is not the reason to punish its users.

ssahani · 2020-04-12T08:31:21Z

@ssahani

https://tools.ietf.org/html/rfc8415

The client uses the addresses, delegated prefixes, and other
information from any IAs that do not contain a Status Code option
with the NoAddrsAvail or NoPrefixAvail status code. The client
MAY include the IAs for which it received the NoAddrsAvail or
NoPrefixAvail status code, with no addresses or prefixes, in
subsequent Renew and Rebind messages sent to the server, to retry
obtaining the addresses or prefixes for these IAs.

The quoted text does not apply here at all. The Status Code in reply has IA_NA option scope, so the correct behavior is to ignore IA_NA option and continue with the next valid option.

As it says it should it may retry. It does not say ignore. Does it ? That is what the client is doing. Where it says ignore and process. I am happy to make the changes it the RFC says so. https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-10

Replace Section 17.1.3 of RFC 3315: (existing errata)

 The client MUST ignore any Advertise message that includes a Status
 Code option containing the value NoAddrsAvail, with the exception
 that the client MAY display the associated status message(s) to the
 user.

A CE Router that received the NoAddrsAvail option in the DHCP Advertise will not process the remaining options.

Reference please. You were already pointed at RFC 7084 that says exactly the opposite.

see https://www.networkworld.com/article/2184317/testing-shows-ipv6-is-becoming-deployable-in-customer-edge-routers.html?page=2 . Header No Addresses Available

Does RFC 7084 talk about NoAddrsAvail ?

arvidjaar · 2020-04-12T09:03:59Z

RFC 3315

This is obsolete and text you quoted no more exists. Let's start with valid RFC 8415, OK? So quoting RFC 8415.

Server behavior (18.3.9. Creation of Advertise Messages):

   If the server will not assign any addresses to an IA_NA or IA_TA in
   subsequent Request messages from the client, the server MUST include
   the IA option in the Advertise message with no addresses in that IA
   and a Status Code option (see Section 21.13) encapsulated in the IA
   option containing status code NoAddrsAvail.

   If the server will not assign any prefixes to an IA_PD in subsequent
   Request messages from the client, the server MUST include the IA_PD
   option (see Section 21.21) in the Advertise message with no prefixes
   in the IA_PD option and a Status Code option encapsulated in the
   IA_PD containing status code NoPrefixAvail.

So server complies with this requirement, assuming it is unwilling to assign addresses. It is willing to provide delegated prefixes though.

Client behavior (18.2.9. Receipt of Advertise Messages):

   The client MUST ignore any Advertise message that contains no
   addresses (IA Address options (see Section 21.6) encapsulated in
   IA_NA options (see Section 21.4) or IA_TA options (see Section 21.5))
   and no delegated prefixes (IA Prefix options (see Section 21.22)
   encapsulated in IA_PD options (see Section 21.21)), with the
   exception that the client:

Well, server advertise message contains IA_PD, server is willing to provide delegated prefix, so client is allowed to request prefix as the next step.

Nowhere RFC8415 requires client to ignore advertise message that contains NoAddrsAvail status code for IA_NA option.

ssahani · 2020-04-12T09:30:26Z

Client behavior (18.2.9. Receipt of Advertise Messages):
The client MUST ignore any Advertise message that contains no
addresses (IA Address options (see Section 21.6) encapsulated in
IA_NA options (see Section 21.4) or IA_TA options (see Section 21.5))
and no delegated prefixes (IA Prefix options (see Section 21.22)
encapsulated in IA_PD options (see Section 21.21)), with the
exception that the client:
Well, server advertise message contains IA_PD, server is willing to provide delegated prefix, so client is allowed to request prefix as the next step.

It also says retry for address so it's not preceding further and retring for the address as I quoted already.

Nowhere RFC8415 requires client to ignore advertise message that contains NoAddrsAvail status code for IA_NA option.

Client behavior (18.2.9. Receipt of Advertise Messages):

The client MUST ignore any Advertise message that contains no
 addresses (IA Address options (see Section 21.6) encapsulated in
 IA_NA options (see Section 21.4) or IA_TA options ?

ssahani · 2020-04-12T09:33:52Z

But the lib can be tweaked to accommodate half of this thing. But I am not very sure about it.

arvidjaar · 2020-04-12T10:43:22Z

Client behavior (18.2.9. Receipt of Advertise Messages):

The client MUST ignore any Advertise message that contains no
 addresses (IA Address options (see Section 21.6) encapsulated in
 IA_NA options (see Section 21.4) or IA_TA options ?

Of course, if you chose to ignore half of the paragraph ...

The client MUST ignore any Advertise message that contains no
addresses (IA Address options (see Section 21.6) encapsulated in
IA_NA options ... AND no delegated prefixes (IA Prefix options)

ssahani · 2020-04-12T11:25:54Z

Client behavior (18.2.9. Receipt of Advertise Messages):
The client MUST ignore any Advertise message that contains no
 addresses (IA Address options (see Section 21.6) encapsulated in
 IA_NA options (see Section 21.4) or IA_TA options ?
Of course, if you chose to ignore half of the paragraph ...

Again it's retrying.

Nowhere RFC8415 requires client to ignore advertise message that contains NoAddrsAvail status code for IA_NA option.

Can you explain what does this mean ?

hermanjustnu · 2020-04-12T12:03:52Z

Is it possible to use only a single IA_PD option and no IA_NA in the solicit message from systemd-networkd?

ssahani · 2020-04-12T12:17:27Z

yes we can do it. As I said we need to ignore error and continue parsing.

arvidjaar · 2020-04-12T15:22:07Z

Can you explain what does this mean ?

MUST in this paragraph refer to the *WHOLE sentence. You arbitrarily omit the second half of the sentence and chose to attribute MUST to only the first half of it. My understanding of RFC is "client MUST ignore advertise message if it contains NEITHER IA_NA/IA_TA NOR IA_PD options". Of course I am not native English speaker so I stay corrected.

Your interpretation (and previous RFC wording) is correct as long as client never solicits for multiple different options. It is self-inflicted issue - systemd-networkd sends solicitation message with both IA_NA and IA_PD. What do you expect server to do if it can (will) provide one and can (will) not provide another? If you want to stick to your interpretation, send two separate solicitations, one for IA_NA, another for IA_PD, as two separate DHCP transactions.

arvidjaar · 2020-04-12T18:36:41Z

Your interpretation (and previous RFC wording) is correct as long as client never solicits for multiple different options.

See RFC 7550, 4.2. Advertise Message Processing by a Client:

   [RFC3315] specifies that a client must ignore an Advertise message if
   a server will not assign any addresses to a client, and [RFC3633]
   specifies that a client must ignore an Advertise message if a server
   returns the NoPrefixAvail status to a requesting router.  Thus, a
   client requesting both IA_NA and IA_PD, with a server that only
   offers either addresses or delegated prefixes, is not supported by
   the current protocol specifications.

   Solution: a client SHOULD accept Advertise messages, even when not
   all IA option types are being offered.  And, in this case, the client
   SHOULD include the not offered IA option types in its Request.  A
   client SHOULD only ignore an Advertise message when none of the
   requested IA options include offered addresses or delegated prefixes.

ssahani · 2020-04-12T19:50:14Z

MUST in this paragraph refer to the *WHOLE sentence. You arbitrarily omit the second half of the sentence and chose to attribute MUST to only the first half of it.

That was for your

Nowhere RFC8415 requires client to ignore advertise message that contains NoAddrsAvail status code for IA_NA option.

Client behavior (18.2.9. Receipt of Advertise Messages):

The client MUST ignore any Advertise message that contains no
addresses (IA Address options (see Section 21.6) encapsulated in
IA_NA options (see Section 21.4) or IA_TA options ?

RFC 7550 make clear that " A
client SHOULD only ignore an Advertise message when none of the
requested IA options include offered addresses or delegated prefixes."

ssahani · 2020-04-16T15:10:33Z

Fix is . #15451. I don't have a setup hence not tested it . @hermanjustnu please test it.

hermanjustnu · 2020-04-27T09:22:51Z

@ssahani Sorry for the delay.

Still no working prefix delegation. Log is flooded with DHCPv6 CLIENT: IA status No addresses available.

There are no other log messages, at least not while I grep -v <message above>, except for this:

Apr 27 11:08:34 tic systemd-networkd[2630]: DHCPv6 CLIENT: IA status No addresses available
Apr 27 11:08:34 tic systemd-journald[667]: Suppressed 632608 messages from systemd-networkd.service
Apr 27 11:08:30 tic systemd-networkd[2630]: eth1: DHCPv4 address 100.65.185.24/19 via 100.65.160.1
Apr 27 11:08:30 tic systemd-networkd[2630]: eth0: IPv6 successfully enabled
Apr 27 11:08:30 tic systemd[1]: Finished Wait for Network to be Configured.
Apr 27 11:08:30 tic systemd-networkd[2630]: eth1: IPv6 successfully enabled
Apr 27 11:08:30 tic systemd[1]: Starting Wait for Network to be Configured...
Apr 27 11:08:30 tic systemd[1]: Started Network Service.
Apr 27 11:08:30 tic systemd-networkd[2630]: Enumeration completed
Apr 27 11:08:30 tic systemd-networkd[2630]: eth0: Gained IPv6LL
Apr 27 11:08:30 tic systemd-networkd[2630]: eth1: Gained IPv6LL
Apr 27 11:08:29 tic systemd[1]: Starting Network Service...

tcpdump:

11:08:31.406191 IP6 (flowlabel 0x142ad, hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::2868:54ff:fed3:ae8b > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 2a:68:54:d3:ae:8b
            0x0000:  2a68 54d3 ae8b
11:08:32.501143 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::ff > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
        hop limit 64, Flags [managed], pref medium, router lifetime 4500s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): 00:00:5e:00:01:11
            0x0000:  0000 5e00 0111
11:08:32.505068 IP6 (flowlabel 0x251ab, hlim 1, next-header UDP (17) payload length: 95) fe80::2868:54ff:fed3:ae8b.546 > ff02::1:2.547: [bad udp cksum 0x28be -> 0x04bc!] dhcp6 solicit (xid=24afd9 (rapid-commit) (IA_NA IAID:2705660566 T1:0 T2:0) (Client-FQDN) (IA_PD IAID:2705660566 T1:0 T2:0) (option-request DNS-server DNS-search-list NTP-server SNTP-servers rapid-commit) (client-ID vid 0000ab11c9cdee5a) (elapsed-time 0))
11:08:32.536726 IP6 (class 0xc0, hlim 255, next-header UDP (17) payload length: 193) fe80::ff.547 > fe80::2868:54ff:fed3:ae8b.546: [udp sum ok] dhcp6 advertise (xid=24afd9 (IA_NA IAID:2705660566 T1:0 T2:0 (status-code NoAddrsAvail)) (IA_PD IAID:2705660566 T1:0 T2:0 (IA_PD-prefix 2001:9b1:26ff:1700::/56 pltime:54000 vltime:86400)) (client-ID vid 0000ab11c9cdee5a) (server-ID hwaddr/time type 1 time 574437592 005056a8da28) (DNS-server 2001:9b0::53:1 2001:9b0::53:2))

ssahani · 2020-04-27T09:52:25Z

Thanks for testing. Can you provide a DHCP server configuration for this to replicate the same test .

hermanjustnu · 2020-04-27T09:56:53Z

This is live testing against my ISP, so I only have client side configuration.

ssahani · 2020-05-02T13:45:21Z

I could not do the full test but somewhat . Can you please test ?

hermanjustnu · 2020-05-15T10:04:07Z

@ssahani some success, but no working ipv6 yet.

systemd-networkd:

May 15 11:52:24 tic systemd-networkd[702]: eth0: Gained carrier
May 15 11:52:24 tic systemd-networkd[702]: eth0: Discovering IPv6 routers
May 15 11:52:24 tic systemd-networkd[702]: NDISC: Started IPv6 Router Solicitation client
May 15 11:52:24 tic systemd-networkd[702]: eth0: Starting IPv6 Router Advertisements
May 15 11:52:24 tic systemd-networkd[702]: RADV: Started IPv6 Router Advertisement daemon
May 15 11:52:24 tic systemd-networkd[702]: eth0: Requesting DHCPv6 prefixes to be delegated for new link
May 15 11:52:24 tic systemd-networkd[702]: eth1: Requesting re-assignment of delegated prefixes after adding new link
May 15 11:52:24 tic systemd-networkd[702]: eth1: Configuring route: dst: 2001:9b1:26fe:d800::/56, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: 0, type: unreachable
May 15 11:52:24 tic systemd-networkd[702]: eth1: Configuring unreachable route for 2001:9b1:26fe:d800::/56
May 15 11:52:24 tic systemd-networkd[702]: eth1: Assigning up to 256 prefixes from 2001:9b1:26fe:d800::/56
May 15 11:52:24 tic systemd-networkd[702]: RADV: Stopping IPv6 Router Advertisement daemon
May 15 11:52:24 tic systemd-networkd[702]: RADV: Updated prefix 2001:9b1:26fe:d800::/64 preferred 14h 55min 13s valid 23h 55min 13s
May 15 11:52:24 tic systemd-networkd[702]: eth0: Configuring route: dst: 2001:9b1:26fe:d800::/64, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: 0, type: unicast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Adding prefix route 2001:9b1:26fe:d800::/64
May 15 11:52:24 tic systemd-networkd[702]: RADV: Started IPv6 Router Advertisement daemon
May 15 11:52:24 tic systemd-networkd[702]: eth0: Assigned prefix 1/256 2001:9b1:26fe:d800::/64 from 2001:9b1:26fe:d800::/56 to link
May 15 11:52:24 tic systemd-networkd[702]: eth0: State changed: configured -> configuring
May 15 11:52:24 tic systemd-networkd[702]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=32 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
May 15 11:52:24 tic systemd-networkd[702]: eth0: Setting addresses
May 15 11:52:24 tic systemd-networkd[702]: RADV: Next Router Advertisement in 7s
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering route: dst: 2001:9b1:26fe:d800::/64, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: boot, type: unicast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering updated address: 172.16.1.1/24 (valid forever)
May 15 11:52:24 tic systemd-networkd[702]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=33 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering route: dst: 172.16.1.1/32, src: n/a, gw: n/a, prefsrc: 172.16.1.1, scope: host, table: local, proto: kernel, type: local
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering route: dst: 172.16.1.255/32, src: n/a, gw: n/a, prefsrc: 172.16.1.1, scope: link, table: local, proto: kernel, type: broadcast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering route: dst: 172.16.1.0/24, src: n/a, gw: n/a, prefsrc: 172.16.1.1, scope: link, table: main, proto: kernel, type: unicast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Remembering route: dst: 172.16.1.0/32, src: n/a, gw: n/a, prefsrc: 172.16.1.1, scope: link, table: local, proto: kernel, type: broadcast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Addresses set
May 15 11:52:24 tic systemd-networkd[702]: eth0: State changed: configuring -> configured
May 15 11:52:24 tic systemd-networkd[702]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=34 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
May 15 11:52:25 tic systemd-networkd[702]: rtnl: received non-static neighbor, ignoring.
May 15 11:52:25 tic systemd-networkd[702]: rtnl: received non-static neighbor, ignoring.
May 15 11:52:25 tic systemd-networkd[702]: NDISC: Sent Router Solicitation, next solicitation in 3s
May 15 11:52:25 tic systemd-networkd[702]: LLDP: Invoking callback for 'refreshed' event.
May 15 11:52:25 tic systemd-networkd[702]: LLDP: Successfully processed LLDP datagram.
May 15 11:52:26 tic systemd-networkd[702]: LLDP: Invoking callback for 'refreshed' event.
May 15 11:52:26 tic systemd-networkd[702]: LLDP: Successfully processed LLDP datagram.
May 15 11:52:28 tic systemd-networkd[702]: RADV: Sent solicited Router Advertisement to fe80::4c8:1319:a02d:36cf
May 15 11:52:29 tic systemd-networkd[702]: NDISC: Sent Router Solicitation, next solicitation in 8s

ip -6 a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::dea6:32ff:fe42:ef74/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::58e2:e8ff:fef7:18ba/64 scope link
       valid_lft forever preferred_lft forever

ip -6 route

::1 dev lo proto kernel metric 256 pref medium
2001:9b1:26fe:d800::/64 dev eth0 metric 1024 pref medium
unreachable 2001:9b1:26fe:d800::/56 dev lo metric 1024 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::ff dev eth1 proto ra metric 1024 expires 4282sec pref medium

lan.network

[Match]
Name=eth0

[Network]
Address=172.16.1.1/24
IPForward=ipv4
IPMasquerade=yes
IPv6PrefixDelegation=dhcpv6

wan.network

[Match]
Name=eth1

[Network]
DHCP=yes
IPForward=ipv6
IPv6AcceptRA=yes

ssahani · 2020-05-21T07:23:27Z

May 15 11:52:24 tic systemd-networkd[702]: eth0: Requesting DHCPv6 prefixes to be delegated for new link
May 15 11:52:24 tic systemd-networkd[702]: eth1: Requesting re-assignment of delegated prefixes after adding new link
May 15 11:52:24 tic systemd-networkd[702]: eth1: Configuring route: dst: 2001:9b1:26fe:d800::/56, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: 0, type: unreachable
May 15 11:52:24 tic systemd-networkd[702]: eth1: Configuring unreachable route for 2001:9b1:26fe:d800::/56
May 15 11:52:24 tic systemd-networkd[702]: eth1: Assigning up to 256 prefixes from 2001:9b1:26fe:d800::/56
May 15 11:52:24 tic systemd-networkd[702]: RADV: Stopping IPv6 Router Advertisement daemon
May 15 11:52:24 tic systemd-networkd[702]: RADV: Updated prefix 2001:9b1:26fe:d800::/64 preferred 14h 55min 13s valid 23h 55min 13s
May 15 11:52:24 tic systemd-networkd[702]: eth0: Configuring route: dst: 2001:9b1:26fe:d800::/64, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: 0, type: unicast
May 15 11:52:24 tic systemd-networkd[702]: eth0: Adding prefix route 2001:9b1:26fe:d800::/64
May 15 11:52:24 tic systemd-networkd[702]: RADV: Started IPv6 Router Advertisement daemon
May 15 11:52:24 tic systemd-networkd[702]: eth0: Assigned prefix 1/256 2001:9b1:26fe:d800::/64 from 2001:9b1:26fe:d800::/56 to link
May 15 11:52:24 tic systemd-networkd[702]: eth0: State changed: configured -> configuring
May 15 11:52:24 tic systemd-networkd[702]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=32 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
May 15 11:52:24 tic systemd-networkd[702]: eth0: Setting addresses

Ok now from the logs it's getting processed not assigning address to the interface right ? That can be done via #15259

hermanjustnu · 2020-05-21T07:35:32Z

Not sure about the unreachable 2001:9b1:26fe:d800::/56 dev lo metric 1024 pref medium? Should routes be set up on the lo interface?

Is it possible to test #15451 and #15259 together?

ssahani · 2020-05-21T08:24:05Z

yes

hermanjustnu · 2020-05-21T12:18:52Z

@ssahani Having trouble building the latest commit, failure in test: 465/783 test-dhcp6-client FAIL 0.53 s (killed by signal 6 SIGABRT).

ssahani · 2020-05-21T12:59:05Z

I made changes to the return value of the function and missed the tests to fix those returns. Now updated. Sorry.

hermanjustnu · 2020-05-22T07:41:26Z

@ssahani With #15451 and #15259 merged together it works very well, an IP address is assigned to the lan interface, and IPv6 traffic is routable. Thank you!!

My current configuration:

wan.network:

[Match]
Name=eth1

[Network]
DHCP=yes
IPv6AcceptRA=yes

lan.network:

[Match]
Name=eth0

[Network]
Address=172.16.1.1/24
IPForward=yes
IPMasquerade=yes
IPv6PrefixDelegation=dhcpv6

[DHCPv6]
AssignAcquiredDelegatedPrefixAddress=true

Let me know if there are any additional tests or logs you want me to provide.

ssahani · 2020-05-22T08:23:53Z

Thanks for testing.

Avamander · 2021-10-26T17:07:18Z

Just mentioning for others searching, Ubuntu 20.04 ships with systemd 245 and this feature broken. People using e.g. Telia in Europe probably can't get IPv6 working.

sem-hub · 2023-12-08T00:15:42Z

Hi. Looks like I have the same issue.
I thought a fix was committed, but when I build systemd 255 (last one) I got "Unknown key name 'AssignAcquiredDelegatedPrefixAddress' in section 'DHCPv6', ignoring." Any plans to merge it?

yuwata · 2023-12-08T05:24:01Z

In recent releases, we have DHCPPrefixDelegation= boolean setting in [Network] section, and several settings in [DHCPPrefixDelegation] section to control the default behavior.
See below:
https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#DHCPPrefixDelegation=
https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#%5BDHCPPrefixDelegation%5D%20Section%20Options
https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#Examples

poettering added the network label Apr 9, 2020

hermanjustnu closed this as completed Apr 11, 2020

hermanjustnu reopened this Apr 12, 2020

ssahani mentioned this issue Apr 16, 2020

sd-network: Rectify Advertise Message Processing by a Client #15451

Merged

ssahani mentioned this issue May 22, 2020

network: DHCPv6 Assign delegated prefix to LAN interface #15259

Merged

yuwata closed this as completed in #15451 May 29, 2020

[systemd-networkd] IPv6 Prefix Delegation not parsing IA_PD responses from upstream RAs #15375

[systemd-networkd] IPv6 Prefix Delegation not parsing IA_PD responses from upstream RAs #15375

Comments

hermanjustnu commented Apr 9, 2020

ssahani commented Apr 9, 2020

hermanjustnu commented Apr 9, 2020

ssahani commented Apr 9, 2020

hermanjustnu commented Apr 9, 2020

ssahani commented Apr 9, 2020

hermanjustnu commented Apr 11, 2020 • edited

ssahani commented Apr 11, 2020

hermanjustnu commented Apr 11, 2020

hermanjustnu commented Apr 11, 2020

arvidjaar commented Apr 12, 2020

ssahani commented Apr 12, 2020

arvidjaar commented Apr 12, 2020

ssahani commented Apr 12, 2020

ssahani commented Apr 12, 2020

arvidjaar commented Apr 12, 2020

ssahani commented Apr 12, 2020 • edited

hermanjustnu commented Apr 12, 2020 • edited

ssahani commented Apr 12, 2020

arvidjaar commented Apr 12, 2020

arvidjaar commented Apr 12, 2020

ssahani commented Apr 12, 2020 • edited

ssahani commented Apr 16, 2020

hermanjustnu commented Apr 27, 2020

ssahani commented Apr 27, 2020

hermanjustnu commented Apr 27, 2020

ssahani commented May 2, 2020 • edited

hermanjustnu commented May 15, 2020 • edited

ssahani commented May 21, 2020

hermanjustnu commented May 21, 2020

ssahani commented May 21, 2020

hermanjustnu commented May 21, 2020

ssahani commented May 21, 2020

hermanjustnu commented May 22, 2020

ssahani commented May 22, 2020

Avamander commented Oct 26, 2021

sem-hub commented Dec 8, 2023

yuwata commented Dec 8, 2023

hermanjustnu commented Apr 11, 2020 •

edited

ssahani commented Apr 12, 2020 •

edited

hermanjustnu commented Apr 12, 2020 •

edited

ssahani commented Apr 12, 2020 •

edited

ssahani commented May 2, 2020 •

edited

hermanjustnu commented May 15, 2020 •

edited