RE: networkd RetransmitSec - how to make it work on a host?

[Muggeridge, Matt]

> -Original Message-
> From: Lennart Poettering 
> Sent: Wednesday, December 13, 2023 7:32 AM
> To: Muggeridge, Matt 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: networkd RetransmitSec - how to make it work on a host?
> 
> On Mo, 11.12.23 02:49, Muggeridge, Matt (matt.muggerid...@hpe.com)
> wrote:
> 
> > The RetransmitSec option was introduced in systemd-v255, but I cannot
> > get it to work for Neighbor Solicitations from a Host. Instead, I
> > observe that the NS are always transmitted at 1 second intervals,
> > regardless of whether it was changed by:
> 
> Please file this as git issue. It sounds like a bug report, which should 
> really go to
> github.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

There's probably something about it that I've misunderstood, which is why I 
asked here.

Ok, I will raise a github issue.

Cheers,
Matt.

RE: IPv6 Compliance for networkd

[Muggeridge, Matt]

> -Original Message-
> From: Lennart Poettering 
> Sent: Wednesday, December 13, 2023 4:22 AM
> To: Muggeridge, Matt 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: IPv6 Compliance for networkd
> 
> On Mo, 11.12.23 19:14, Muggeridge, Matt (matt.muggerid...@hpe.com)
> wrote:
> 
> > Hello, networkd developer community,
> >
> > I am hoping to rally support for making networkd IPv6 compliant and
> > I'm will to help, but cannot do it alone. Is there any interest in
> > making systemd-networkd IPv6 compliant?
> 
> Well, interest is relative. I think for most people IPv6 already works well
> enough, they don't really care about compliance programs on this so much.
> But as long as the requirements are reasonable they also wouldn't mind (and
> prefer) if networkd passes those qualifications.
> 
> > There are many organizations (especially US Government) that mandate
> > IPv6 compliance (USGv6).  Products that are dependent on networkd
> > cannot be bid to these customers.
> 
> For the people currently involved with networkd upstream this is not a top
> priority. If this is important to you however, that's great, we are happy to
> review/merge patches.
> 
> > How do I engage with the right people in the developer community?
> 
> Send PRs via github.
> 
> > Thanks,
> > Matt.
> >
> > PS: Mailing list topics go unanswered and github issues get lost in
> > the noise, so I'm hoping there's a more efficient way to collaborate.
> 
> It's an Open Source project: if something matters a lot to you, then please 
> file
> PRs to get the work merged. We generally try to review PRs sooner or later,
> but we are swamped with work, so it might take a while. Just filing issues
> (while also appreciated) will usually not magically make somebody work on
> this for you though. It's kinda the same with most open source projects btw.
> 
> If this is something you'd like to see addressed soon, I'd recommend maybe
> paying some consultancy (we have worked with codethink on some projects,
> they should be willing to work on this, are capable and now hot get stuff in
> systemd done).
> 
> If you don't have the cash for that, it might work to get funding from this 
> from
> organizations such as the German STF and things like that. I am pretty sure
> that the US has something similar?
> 
> Anyway, judging by your email address I understand you work for HPE, so I'd
> assume your company actually has the funds to payroll this though, if this
> matters to you.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

Thanks Lennart.  That all makes sense.

Cheers,
Matt.
 

RE: IPv6 Compliance for networkd

[Muggeridge, Matt]

> -Original Message-
> From: Demi Marie Obenour 
> Sent: Tuesday, December 12, 2023 11:38 AM
> To: Muggeridge, Matt ; systemd-
> de...@lists.freedesktop.org
> Subject: Re: IPv6 Compliance for networkd
> 
> On Mon, Dec 11, 2023 at 10:52:31PM +, Muggeridge, Matt wrote:
> >
> >
> > > -Original Message-
> > > From: Demi Marie Obenour 
> > > Sent: Tuesday, December 12, 2023 7:14 AM
> > > To: Muggeridge, Matt ; systemd-
> > > de...@lists.freedesktop.org
> > > Subject: Re: IPv6 Compliance for networkd
> > >
> > > On Mon, Dec 11, 2023 at 07:14:27PM +, Muggeridge, Matt wrote:
> > > > Hello, networkd developer community,
> > > >
> > > > I am hoping to rally support for making networkd IPv6 compliant
> > > > and I'm will
> > > to help, but cannot do it alone. Is there any interest in making
> > > systemd- networkd IPv6 compliant?
> > > >
> > > > There are many organizations (especially US Government) that
> > > > mandate
> > > IPv6 compliance (USGv6).  Products that are dependent on networkd
> > > cannot be bid to these customers.
> > > >
> > > > How do I engage with the right people in the developer community?
> > > >
> > > > Thanks,
> > > > Matt.
> > > > PS: Mailing list topics go unanswered and github issues get lost
> > > > in the noise,
> > > so I'm hoping there's a more efficient way to collaborate.
> > >
> > > In what specific ways is networkd not compliant?
> > > --
> > > Sincerely,
> > > Demi Marie Obenour (she/her/hers)
> > > Invisible Things Lab
> >
> > Hi Demi,
> >
> > > In what specific ways is networkd not compliant?
> >
> > Refer to previous mailing list topics [1] and github issues, especially any
> issues opened by LiveFreeAndRoam [2].
> >
> > Are you a networkd developer?  Are you willing to collaborate on this?
> >
> > [1]
> > https://www.mail-archive.com/search?a=1=systemd-
> devel%40lists.freede
> >
> sktop.org=ipv6+compliance=0=0==
> in=1
> > d===relevance [2]
> >
> https://github.com/systemd/systemd/issues?q=is%3Aissue+author%3Alivefr
> > eeandroam
> 
> If you need these problems fixed so that you can use systemd-networkd in
> your commercial products, I recommend getting your company to pay
> developers to fix systemd-networkd.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

I appreciate that point, too. It seems prudent to request collaboration from 
others in the community, in case there is overlapping interest.

Thanks,
Matt.

RE: IPv6 Compliance for networkd

[Muggeridge, Matt]

> -Original Message-
> From: Demi Marie Obenour 
> Sent: Tuesday, December 12, 2023 7:14 AM
> To: Muggeridge, Matt ; systemd-
> de...@lists.freedesktop.org
> Subject: Re: IPv6 Compliance for networkd
> 
> On Mon, Dec 11, 2023 at 07:14:27PM +, Muggeridge, Matt wrote:
> > Hello, networkd developer community,
> >
> > I am hoping to rally support for making networkd IPv6 compliant and I'm will
> to help, but cannot do it alone. Is there any interest in making systemd-
> networkd IPv6 compliant?
> >
> > There are many organizations (especially US Government) that mandate
> IPv6 compliance (USGv6).  Products that are dependent on networkd cannot
> be bid to these customers.
> >
> > How do I engage with the right people in the developer community?
> >
> > Thanks,
> > Matt.
> > PS: Mailing list topics go unanswered and github issues get lost in the 
> > noise,
> so I'm hoping there's a more efficient way to collaborate.
> 
> In what specific ways is networkd not compliant?
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Hi Demi,

> In what specific ways is networkd not compliant?

Refer to previous mailing list topics [1] and github issues, especially any 
issues opened by LiveFreeAndRoam [2].

Are you a networkd developer?  Are you willing to collaborate on this?

[1] 
https://www.mail-archive.com/search?a=1=systemd-devel%40lists.freedesktop.org=ipv6+compliance=0=0===1d===relevance
[2] 
https://github.com/systemd/systemd/issues?q=is%3Aissue+author%3Alivefreeandroam

Thanks,
Matt.

IPv6 Compliance for networkd

[Muggeridge, Matt]

Hello, networkd developer community,

I am hoping to rally support for making networkd IPv6 compliant and I'm will to 
help, but cannot do it alone. Is there any interest in making systemd-networkd 
IPv6 compliant?

There are many organizations (especially US Government) that mandate IPv6 
compliance (USGv6).  Products that are dependent on networkd cannot be bid to 
these customers.

How do I engage with the right people in the developer community?

Thanks,
Matt.
PS: Mailing list topics go unanswered and github issues get lost in the noise, 
so I'm hoping there's a more efficient way to collaborate.

networkd RetransmitSec - how to make it work on a host?

[Muggeridge, Matt]

The RetransmitSec option was introduced in systemd-v255, but I cannot get it to 
work for Neighbor Solicitations from a Host. Instead, I observe that the NS are 
always transmitted at 1 second intervals, regardless of whether it was changed 
by:


  1.  Received RA Retransmit Timer
  2.  Sysctl net.ipv6.icmp.ratelimit
  3.  Systemd.network configuration file RetransmitSec

A few questions:

  1.  Can you point me at the networkd code that generates the neighbor 
solicitations?
  2.  My router sends an RA with a Retransmit Timer = 5000ms:
 *   What is supposed to take precedence, the RA or the value in the config 
file?
 *   With debug enabled, I see networkd writes to 
/proc/sys/net/ipv6/icmp/ratelimit

   i.  However, 
that makes no difference to the retransmit rate, which is always 1 second.

  1.  Why is this option not enabled under [Network], but instead under 
[IPv6SendRA].  Hosts send NS that should also be ratelimited.

$ systemctl --version
systemd 255 (255-1-g6a9a58c^)
+PAM -AUDIT -SELINUX -APPARMOR -IMA -SMACK -SECCOMP -GCRYPT -GNUTLS -OPENSSL 
-ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP 
+LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 -BZIP2 -LZ4 +XZ -ZLIB -ZSTD 
-BPF_FRAMEWORK -XKBCOMMON -UTMP +SYSVINIT default-hierarchy=hybrid

I've tried several configuration changes, but nothing worked.  E.g. I tried to 
configure the Retransmit interval to 3 seconds. After each configuration 
change, I ran:

$ systemctl daemon-reload; systemctl restart systemd-networkd

One of my attempts:

$ networkctl cat 10-eno0.network
# /etc/systemd/network/10-eno0.network
[Match]
KernelCommandLine=!nfsroot
Name=eno0

[DHCP]
ClientIdentifier=mac
RouteMetric=10
UseDomains=yes
UseHostname=yes
UseMTU=yes

[IPv6AcceptRA]
#UseOnLinkPrefix=yes
UseDNS=yes
UseDomains=yes

[Link]
RequiredForOnline=no

[Network]
#Address=16.107.234.71/21
#DHCP=ipv6
#DNS=1.2.3.6
#Gateway=16.107.232.1
Address=10.1.1.1/24
DHCP=no
Gateway=10.1.1.2
IPv6AcceptRA=yes
IPv6SendRA=yes

[IPv6SendRA]
RetransmitSec=3


And here is the tcpdump output:

$ tcpdump -i eno0 -n --number ip6 -vv
tcpdump: listening on eno0, link-type EN10MB (Ethernet), snapshot length 262144 
bytes
1  02:23:50.607129 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
56) fe80::200:10ff:fe10:1060 > ff02::1: [icmp6 sum ok] ICMP6, router 
advertisement, length 56
hop limit 64, Flags [none], pref medium, router lifetime 9000s, 
reachable time 3ms, retrans timer 5000ms
  prefix info option (3), length 32 (4): 2001:2:0:1000::/64, Flags 
[onlink, auto], valid time 65535s, pref. time 65535s
0x:  40c0       2001
0x0010:  0002  1000    
  mtu option (5), length 8 (1):  1500
0x:    05dc

8< -- snip unrelated multicast packets  >8

4  02:24:00.932029 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
10) fe80::200:10ff:fe10:1081 > fe80::9640:c9ff:fed6:77f6: [icmp6 sum ok] ICMP6, 
echo request, id 0, seq 0
5  02:24:00.932412 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
32) fe80::9640:c9ff:fed6:77f6 > ff02::1:ff10:1081: [icmp6 sum ok] ICMP6, 
neighbor solicitation, length 32, who has fe80::200:10ff:fe10:1081
  source link-address option (1), length 8 (1): 94:40:c9:d6:77:f6
0x:  9440 c9d6 77f6
6  02:24:01.934639 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
32) fe80::9640:c9ff:fed6:77f6 > ff02::1:ff10:1081: [icmp6 sum ok] ICMP6, 
neighbor solicitation, length 32, who has fe80::200:10ff:fe10:1081
  source link-address option (1), length 8 (1): 94:40:c9:d6:77:f6
0x:  9440 c9d6 77f6
7  02:24:02.958599 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 
32) fe80::9640:c9ff:fed6:77f6 > ff02::1:ff10:1081: [icmp6 sum ok] ICMP6, 
neighbor solicitation, length 32, who has fe80::200:10ff:fe10:1081
  source link-address option (1), length 8 (1): 94:40:c9:d6:77:f6
0x:  9440 c9d6 77f6

$ sysctl net.ipv6.icmp.ratelimit
net.ipv6.icmp.ratelimit = 5000


Thanks,
Matt.

[systemd-devel] systemd-networkd code design documentation?

[Muggeridge, Matt]

Hi,

As I start looking at the code, is there any design documentation for 
developers that describes systemd-networkd?

Specifically, I'm looking for an overview of the data-flow when an IPv6 Router 
Advertisement is received, where it is processed and where it generates the 
reply.

I'm slowly building a picture of this flow, but if someone has already been 
down this path and is willing to share, then it will save me some time.

Thanks,
Matt.

[systemd-devel] DynamicUser=yes leads to "Too many levels of symbolic links" for /etc/.pwd.lock

[Muggeridge, Matt]

Hi,

I'm using systemd-v254.

My rdisc service fails to start when "DynamicUser=yes", and the error message 
comes from 
systemd.execute.c.
 It's complaining about the /etc/.pwd.lock file (see journal below).

I turned on debug (systemd-analyze set-log-level debug) and then attempted to 
start the rdisc.service.  This is an extract from the journal:

$ journalctl -f
:

Sep 14 03:26:19 sph-093-rmc systemd[1]: rdisc.service: Forked /sbin/rdisc as 
24873

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: Cannot open /etc/.pwd.lock: Too 
many levels of symbolic links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed to update 
dynamic user credentials: Too many levels of symboli

c links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed at step USER 
spawning /sbin/rdisc: Too many levels of symbolic

 links

Sep 14 03:26:19 sph-093-rmc systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freed

I can override it with "DynamicUser=no" and the service starts.  However, I'm 
trying to understand why it reports "too many levels of symbolic links". The 
lock file is a single-level symlink to a file in sysconfig.  (This is an 
embedded device, where /etc is read-only and /etc/sysconfig is writeable).


$ ls -l /etc/.pwd.lock

lrwxrwxrwx 1 root root 19 Apr  5  2011 /etc/.pwd.lock -> sysconfig/.pwd.lock

$ ls -l /etc/sysconfig/.pwd.lock

-rw--- 1 root root 0 Aug 16 07:25 /etc/sysconfig/.pwd.lock

For the purpose of investigation, I configured an overlay so /etc/.pwd.lock was 
a simple writeable file (not a read-only symlink) and the service starts.

Why is systemd complaining about the file being a symlink?

Regards,
Matt.

[systemd-devel] How to autoconfigure IPv4 LinkLocalAddressing

[Muggeridge, Matt]

Hi,

I’m using systemd_254.

I my ".network" configuration file (see below), I'm expecting that the “mul0” 
interface will always be assigned an IPv4 link local address. The documentation 
for LinkLocalAddressing describes:

> An IPv4 link-local address is configured when yes or ipv4 and when DHCPv4
> autoconfiguration has been unsuccessful for some time.

I don't run a DHCP Client on this interface and RFC3927 (last paragraph p.8) 
states it should be independent of DHCP:

> The assignment of an IPv4 Link-Local address on an interface is
> based solely on the state of the interface, and is independent
> of any other protocols such as DHCP.

How do I autoconfigure an IPv4 link local address on this interface?

FWIW: In case my procedure for reconfiguring is wrong, after changing the 
".network" file, I run:

  $ networkctl reload; entworkctl reconfigure mul0; ip a show dev mul0

Here's my config file:


$ networkctl cat 50-mul0.network
# /lib/systemd/network/50-mul0.network
[Match]
Name=mul0

[Network]
# DHCP=ipv4
LinkLocalAddressing=ipv4
ConfigureWithoutCarrier=true

#[DHCPv4]
#MaxAttempts=1

$ ip a show dev mul0
7: mul0:  mtu 1500 qdisc pfifo_fast state 
DOWN group default qlen 1000
link/ether 00:50:b6:15:53:4d brd ff:ff:ff:ff:ff:ff
altname enu1

$ networkctl status mul0
● 7: mul0  
 Link File: /lib/systemd/network/99-default.link
  Network File: /lib/systemd/network/50-mul0.network
 State: no-carrier (configuring)
  Online state: offline
  Type: ether
  Path: platform-xhci-hcd.0.auto-usb-0:1:1.0
Driver: asix
Vendor: ASIX_Elec._Corp.
 Model: AX88772B
 Alternative Names: enu1
  Hardware Address: 00:50:b6:15:53:4d
   MTU: 1500 (max: 65535)
 QDisc: pfifo_fast
  IPv6 Address Generation Mode: none
  Number of Queues (Tx/Rx): 1/1
  Auto negotiation: yes
 Speed: 100Mbps
Duplex: full
  Port: tp
 Activation Policy: up
   Required For Online: yes

Aug 31 23:28:14 sph-018-rmc systemd-networkd[3942]: mul0: DHCPv6 lease lost
Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with 
/lib/systemd/…ork.
Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: DHCPv6 lease lost
Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with 
/lib/systemd/ne…ork.
Aug 31 23:32:01 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with 
/lib/systemd/…ork.
Aug 31 23:32:01 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with 
/lib/systemd/ne…ork.
Aug 31 23:50:09 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with 
/lib/systemd/…ork.
Aug 31 23:50:09 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with 
/lib/systemd/ne…ork.
Aug 31 23:55:45 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with 
/lib/systemd/…ork.
Aug 31 23:55:45 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with 
/lib/systemd/ne…ork
--

Thanks,
Matt.

Re: [systemd-devel] Networkd's IPv6 Compliance Issues

[Muggeridge, Matt]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Thursday, July 27, 2023 2:04 AM
> To: Muggeridge, Matt 
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Networkd's IPv6 Compliance Issues
> 
> On Wed, 26 Jul 2023 03:23:14 +
> "Muggeridge, Matt"  wrote:
> 
> > Hi,
> >
> > Recently, we ran a test suite to check networkd's conformance to IPv6
> Protocol (see
> https://www.ipv6ready.org/resources.html
> NpxR!nFJaK0aGQPinj4D6Vhsk6r-oxzcFLJzPNuYIoelLyAa9wFlQ2Eass0RiLOldLz-
> OIADX3SogGJEfZSwSSDPLAFgna4U$ ).  I found a large number of test failures
> (more than 80) and after examining a small number of them, it became clear
> that networkd's implementation of IPv6 protocol does not meet various RFC's
> MUST and SHOULD requirements.
> >
> > With so many IPv6 protocol compliance failures, it's not practical for me to
> raise an issue for every failing case. Instead, I created a summary in
> https://github.com/systemd/systemd/issues/28502.
> >
> > How would you like to handle these failing cases?
> >
> > Is there any more information you need from me?
> >
> > Kind regards,
> > Matt.
> > PS: Credit to the developers for quickly responding to a couple of the 
> > issues.
> >
> >
> 
> Why do you think these are systemd issues?
> A quick look at the list shows most of these are from Linux kernel
> implementation

Hi Stephen,

We ran the same test suite with systemd-networkd stopped and the tests passed. 
i.e. the kernel implementation is conformant, the networkd implementation is 
not.

Evidently, systemd-networkd injects itself into the protocol exchange by 
intercepting IPv6 RAs. In fact, it configures the kernel to disable the sysctl 
accept_ra attribute, so the kernel is taken out of the RA conversation. 
Unfortunately, networkd does not handle the RAs in a compliant fashion.

Rather than take my word for it, as an example, look at the solutions for 
issues: #28437 fixed by PR#28446 and #28439 fixed by PR#28496. I started by 
posting issues for each failing case, but there are too many of them.

In summary, networkd is part of the IPv6 protocol and it is not IPv6 compliant.

Matt.
PS: as much as you are dismayed by this, as was I.

[systemd-devel] Networkd's IPv6 Compliance Issues

[Muggeridge, Matt]

Hi,

Recently, we ran a test suite to check networkd's conformance to IPv6 Protocol 
(see https://www.ipv6ready.org/resources.html).  I found a large number of test 
failures (more than 80) and after examining a small number of them, it became 
clear that networkd's implementation of IPv6 protocol does not meet various 
RFC's MUST and SHOULD requirements.

With so many IPv6 protocol compliance failures, it's not practical for me to 
raise an issue for every failing case. Instead, I created a summary in 
https://github.com/systemd/systemd/issues/28502.

How would you like to handle these failing cases?

Is there any more information you need from me?

Kind regards,
Matt.
PS: Credit to the developers for quickly responding to a couple of the issues.

 

[systemd-devel] IPv6 Compliance Issues witih networkd

[Muggeridge, Matt]

Hi there,

I am noticing networkd has a number of IPv6 compliance issues, where it is not 
meeting various RFC's "must" requirements.  For comparison, when I stop 
networkd and configure the network via legacy methods, the protocol exchanges 
comply with the RFCs.

Would you prefer I raise the issues in your github or discuss the failures in 
this mailing list?

Kind regards,
Matt.

[systemd-devel] IPv6AcceptRA: RDNSS Lifetime is not expiring

[Muggeridge, Matt]

Hello there!

In our IPv6 network, the address of a Recursive DNS Server (RDNSS) is supplied 
in a Router Advertisement (RA), with a lifetime of 60 seconds.

It appears that RDNSS lifetime is not being honoured (RFC 8106, section 
5.1).  I reviewed the code 
and can see where the RDNSS lifetime is being 
saved,
 though I was unable to determine how it was being handled upon expiry.

How do I configure networkd so that the RA's RDNSS lifetime is honoured?

Here is a summary of the simple protocol exchange:


  1.  Router:  Send RA [RDNSS address of "nameserver60s", lifetime: "60"]
  2.  Host: "resolvectl" shows the link's DNS server now lists the RDNSS 
address of "nameserver60s"
  3.  ** Wait for more than 60 seconds - the RDNSS entry should expire **
  4.  Host:
 *   "resolvectl" continues to list the address of "nameserver60s" on the 
link.
 *   Using tcpdump to trace "ping test.example.com", the "nameserver60s" is 
still being used.  It never timed out.

Here is my network configuration, showing UseDNS and UseDomains both set to 
"yes":


$ cat /etc/systemd/network/10-eno0.network
[Match]
KernelCommandLine=!nfsroot
Name=eno0

[DHCP]
ClientIdentifier=mac
RouteMetric=10
UseDomains=yes
UseHostname=yes
UseMTU=yes

[Network]
#DHCP=ipv6
Address=10.1.1.1/24
#DNS=1.2.3.6
Gateway=1.1.1.2
IPv6AcceptRA=yes

[IPv6AcceptRA]
UseDNS=yes
UseDomains=yes


Grateful for any suggestions.

Kind regards,
Matt.
PS: We're on systemd 250.  I've searched later versions of the release 
notes and it seems there have been 
no changes in this area.