IPv6 support regresses with nplan transition
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| nplan (Ubuntu) |
Critical
|
Mathieu Trudel-Lapierre | ||
| Xenial |
Undecided
|
Unassigned | ||
| Zesty |
Undecided
|
Unassigned |
Bug Description
[Impact]
This is a bug tracking a regression in netplan 0.25 and later, fixed directly in the development release as of netplan 0.28. This does not affect stable releases in any way; but tracked as part of an update included in the SRU. The regressing code never made it to stable releases.
[Test case]
n/a; see bug 1655440 for test plan on IPv6 "AcceptRA" feature.
[Regression Potential]
n/a, see bug 1655440.
---
Prior to the switch to nplan, systems (in my case containers) would DHCP for IPv4 and let the kernel do IPv6 auto-configuration whenever a router advertisement comes in.
That's the exact same behavior we see on every single other Linux distribution, but ever since the switch to nplan by default in Ubuntu, we're not getting an IPv6 address anymore when a RA reaches the container.
This was spotted by a new Jenkins test we're running which ensures that every single image we have for LXD will start and get a working IPv4 (through DHCP) and IPv6 address (through RA).
```
PASS: alpine-33-priv has working IPv4 and IPv6 connectivty
PASS: alpine-33-unpriv has working IPv4 and IPv6 connectivty
PASS: alpine-34-priv has working IPv4 and IPv6 connectivty
PASS: alpine-34-unpriv has working IPv4 and IPv6 connectivty
PASS: alpine-35-priv has working IPv4 and IPv6 connectivty
PASS: alpine-35-unpriv has working IPv4 and IPv6 connectivty
PASS: alpine-36-priv has working IPv4 and IPv6 connectivty
PASS: alpine-36-unpriv has working IPv4 and IPv6 connectivty
PASS: alpine-edge-priv has working IPv4 and IPv6 connectivty
PASS: alpine-edge-unpriv has working IPv4 and IPv6 connectivty
PASS: archlinux-priv has working IPv4 and IPv6 connectivty
PASS: archlinux-unpriv has working IPv4 and IPv6 connectivty
PASS: centos-6-priv has working IPv4 and IPv6 connectivty
PASS: centos-6-unpriv has working IPv4 and IPv6 connectivty
PASS: centos-7-priv has working IPv4 and IPv6 connectivty
PASS: centos-7-unpriv has working IPv4 and IPv6 connectivty
PASS: debian-buster-priv has working IPv4 and IPv6 connectivty
PASS: debian-
PASS: debian-jessie-priv has working IPv4 and IPv6 connectivty
PASS: debian-
PASS: debian-sid-priv has working IPv4 and IPv6 connectivty
PASS: debian-sid-unpriv has working IPv4 and IPv6 connectivty
PASS: debian-stretch-priv has working IPv4 and IPv6 connectivty
PASS: debian-
PASS: debian-wheezy-priv has working IPv4 and IPv6 connectivty
PASS: debian-
PASS: fedora-24-priv has working IPv4 and IPv6 connectivty
PASS: fedora-24-unpriv has working IPv4 and IPv6 connectivty
PASS: fedora-25-priv has working IPv4 and IPv6 connectivty
PASS: fedora-25-unpriv has working IPv4 and IPv6 connectivty
PASS: fedora-26-priv has working IPv4 and IPv6 connectivty
PASS: fedora-26-unpriv has working IPv4 and IPv6 connectivty
PASS: gentoo-priv has working IPv4 and IPv6 connectivty
PASS: gentoo-unpriv has working IPv4 and IPv6 connectivty
PASS: opensuse-422-priv has working IPv4 and IPv6 connectivty
PASS: opensuse-422-unpriv has working IPv4 and IPv6 connectivty
PASS: opensuse-423-priv has working IPv4 and IPv6 connectivty
PASS: opensuse-423-unpriv has working IPv4 and IPv6 connectivty
PASS: oracle-6-priv has working IPv4 and IPv6 connectivty
PASS: oracle-6-unpriv has working IPv4 and IPv6 connectivty
PASS: oracle-7-priv has working IPv4 and IPv6 connectivty
PASS: oracle-7-unpriv has working IPv4 and IPv6 connectivty
PASS: plamo-5x-priv has working IPv4 and IPv6 connectivty
PASS: plamo-5x-unpriv has working IPv4 and IPv6 connectivty
PASS: plamo-6x-priv has working IPv4 and IPv6 connectivty
PASS: plamo-6x-unpriv has working IPv4 and IPv6 connectivty
PASS: sabayon-priv has working IPv4 and IPv6 connectivty
PASS: sabayon-unpriv has working IPv4 and IPv6 connectivty
FAIL: ubuntu-artful-priv doesn't have an IPv6 address
FAIL: ubuntu-
PASS: ubuntu-core-16-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-
PASS: ubuntu-precise-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-
PASS: ubuntu-trusty-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-
PASS: ubuntu-xenial-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-
PASS: ubuntu-zesty-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-zesty-unpriv has working IPv4 and IPv6 connectivty
Test failed
```
Changed in nplan (Ubuntu): | |
importance: | Critical → High |
Stéphane Graber (stgraber) wrote : | #1 |
Stéphane Graber (stgraber) wrote : | #2 |
Just looked at what netplan generates in networkd:
[Match]
Name=eth0
[Network]
DHCP=ipv4
IPv6AcceptRA=no
[DHCP]
RouteMetric=100
So that shows it's explicitly disabling IPv6 RA handling on the interface, causing the regression.
Michael Hudson-Doyle (mwhudson) wrote : | #3 |
This is caused by the fix for https:/
Stéphane Graber (stgraber) wrote : | #4 |
What we're expecting for LXC at least is:
- IPv4 -> DHCP (and block until you get something)
- IPv6 -> passive kernel SLAAC (don't block on lack of IPv6)
Is that something the current yaml can do?
With the current YAML, despite the disabled processing of RAs, you could add a dummy IPv6 address and thus let RAs be processed; but I'm going to revert that and instead provide a way to toggle RA processing.
Changed in nplan (Ubuntu): | |
importance: | High → Critical |
status: | New → In Progress |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
Launchpad Janitor (janitor) wrote : | #6 |
This bug was fixed in the package nplan - 0.29
---------------
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkMan
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
-- Mathieu Trudel-Lapierre <email address hidden> Tue, 19 Sep 2017 15:24:17 -0400
Changed in nplan (Ubuntu): | |
status: | In Progress → Fix Released |
description: | updated |
description: | updated |
Hello Stéphane, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
Changed in nplan (Ubuntu Zesty): | |
status: | New → Fix Committed |
tags: | added: verification-needed verification-needed-zesty |
Brian Murray (brian-murray) wrote : | #8 |
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
Changed in nplan (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: | added: verification-needed-xenial |
Verification-done for xenial with nplan 0.29~16.04.1:
The bug this is fixing is a regression in 0.26~16.04.1, which is a version that only landed in -proposed. 0.23~16.04.1 (the previous released nplan) does not show this bug, and 0.29~16.04.1 does not show IPv6 issues.
I set up a container with the new nplan version, verified that once netplan is configured the container can successfully get both an IPv4 and IPv6 address; which is displayed in 'lxc ls' on the host.
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Verification-done for zesty with nplan 0.29~17.04.1:
As for xenial, this is a fix for a regression introduced in a package that never actually made it to zesty. The regression does not appear in netplan 0.29~17.04.1 at all, I verified that the container with nplan upgraded properly gets both IPv4 and IPv6 addresses; and those are displayed in 'lxc ls'.
tags: |
added: verification-done-zesty removed: verification-needed verification-needed-zesty |
Scott Moser (smoser) wrote : | #11 |
I am confused by Stephane's orginal opening statement that
| Prior to the switch to nplan, systems (in my case containers) would
| DHCP for IPv4 and let the kernel do IPv6 auto-configuration whenever a
| router advertisement comes in.
I opened bug 1732002 with information to the contrary.
On my system, 16.04 images do *not* get ipv6 addresses, but current
artful and bionic images do.
I'm raising this because it seems that it was used for justification
of a change to a stable release.
$ lxc network show lxdbr0
config:
ipv4.address: 10.75.205.1/24
ipv4.nat: "true"
ipv6.address: fd42:eee5:
ipv6.
$ lxc list "(artful|
+------
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------
| artful-demo | RUNNING | 10.75.205.208 (eth0) | fd42:eee5:
+------
| xenial-demo | RUNNING | 10.75.205.143 (eth0) | | PERSISTENT | 0 |
+------
Stéphane Graber (stgraber) wrote : | #12 |
That's because you're using stateful DHCP which the kernel doesn't do.
My comment was about a stock setup which comes with stateless DHCP, in which case all Linux distros do get a configured IPv6 address regardless of what their userspace does, so long (and that was the problem with nplan) as the interface hasn't been directly configured not to do auto config.
Łukasz Zemczak (sil2100) wrote : | #13 |
Hello Stéphane, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
tags: |
added: verification-needed verification-needed-zesty removed: verification-done-zesty |
Łukasz Zemczak (sil2100) wrote : | #14 |
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
tags: |
added: verification-needed-xenial removed: verification-done-xenial |
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the code skipping the test_routes_v6 test in the NetworkManager case. Therefore, it can't possibly pass SRU verification.
tags: |
added: verification-failed-xenial removed: verification-needed-xenial |
Brian Murray (brian-murray) wrote : | #16 |
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
tags: |
added: verification-needed-xenial removed: verification-failed-xenial |
Autopktests still failing for xenial; the test is still not being skipped (we know it won't work on Xenial due to the version of NM shipped there). Marking verification-
tags: |
added: verification-failed-xenial removed: verification-needed-xenial |
Łukasz Zemczak (sil2100) wrote : | #18 |
Hello Stéphane, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
tags: |
added: verification-needed-xenial removed: verification-failed-xenial |
verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
IPv6 addresses are handled correctly through the lxd bridge; AcceptRA is not longer set by default but the option is available to users.
tags: |
added: verification-done-xenial verification-done-zesty removed: verification-needed verification-needed-xenial verification-needed-zesty |
Launchpad Janitor (janitor) wrote : | #20 |
This bug was fixed in the package nplan - 0.32~16.04.3
---------------
nplan (0.32~16.04.3) xenial; urgency=medium
* tests/integrati
backend.
nplan (0.32~16.04.2) xenial; urgency=medium
* tests/integrati
the skip rules for 16.04 after merging in 0.32.
nplan (0.32~16.04.1) xenial; urgency=medium
* Backport netplan 0.32 to 16.04. (LP: #1713142)
* debian/control: Depend on systemd (>= 229-4ubuntu20) for the PrimarySlave
feature backported in that revision.
* tests/integrati
nplan (0.32) bionic; urgency=medium
* src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.
nplan (0.31) bionic; urgency=medium
[ Mathieu Trudel-Lapierre ]
* src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
* debian/
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
* tests/integrati
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)
[ Dimitri John Ledkov ]
* Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564
[ Dan Streetman ]
* Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)
nplan (0.30) artful; urgency=medium
* Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkMan
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
nplan (0.28) artful; urgency=medium
* Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
* Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)
nplan (0.27) artful; urgency=medium
[ Mathieu Trudel-Lapierre ]
* Fix crash in systemd generator if called by an user on the command-line
* coverage: fix exclusions to properly not cover our "never reached defaults"
[ Dimitri John Ledkov ]
* tests/integrati
* src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
* tests/integrati
nplan (0.26) artful; urgency=medium
...
Changed in nplan (Ubuntu Xenial): | |
status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for nplan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Launchpad Janitor (janitor) wrote : | #22 |
This bug was fixed in the package nplan - 0.32~17.04.1
---------------
nplan (0.32~17.04.1) zesty; urgency=medium
* Backport 0.32 to 17.04. (LP: #1713142)
nplan (0.32) bionic; urgency=medium
* src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.
nplan (0.31) bionic; urgency=medium
[ Mathieu Trudel-Lapierre ]
* src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
* debian/
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
* tests/integrati
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)
[ Dimitri John Ledkov ]
* Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564
[ Dan Streetman ]
* Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)
nplan (0.30) artful; urgency=medium
* Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkMan
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
nplan (0.28) artful; urgency=medium
* Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
* Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)
nplan (0.27) artful; urgency=medium
[ Mathieu Trudel-Lapierre ]
* Fix crash in systemd generator if called by an user on the command-line
* coverage: fix exclusions to properly not cover our "never reached defaults"
[ Dimitri John Ledkov ]
* tests/integrati
* src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
* tests/integrati
nplan (0.26) artful; urgency=medium
* Bonding:
- Add support for specifying a primary slave. (LP: #1709135)
* Rebind:
- Fix brcmfmac harder. Treat any 'brcmfmac' driver as not supporting
rebind. (LP: #1712224)
* Autopkgtests:
- Add allow-stderr. Systemd now bleats about a the networkd socket still
being around and enabled when we restart the service; but we don't need
to care since we're /restarting/ the service to load the new config.
- Fix the autostart package to be more sensible: we don't really care if
...
Changed in nplan (Ubuntu Zesty): | |
status: | Fix Committed → Fix Released |
The nplan.yaml which is included in our containers is:
root@artful:~# cat /etc/netplan/ 10-lxc. yaml
network:
ethernets:
eth0: {dhcp4: true}
version: 2
/etc/network/ interfaces used to be:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
Right now this seems to only affect the LXC images, not the one generated by CPC as that one is still using ifupdown with a /etc/network/ interfaces similar to that above and without a netplan .yaml.