IPv6 support regresses with nplan transition

Bug #1717404 reported by Stéphane Graber on 2017-09-15
10
This bug affects 1 person
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-buster-unpriv has working IPv4 and IPv6 connectivty
PASS: debian-jessie-priv has working IPv4 and IPv6 connectivty
PASS: debian-jessie-unpriv has working IPv4 and IPv6 connectivty
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-stretch-unpriv has working IPv4 and IPv6 connectivty
PASS: debian-wheezy-priv has working IPv4 and IPv6 connectivty
PASS: debian-wheezy-unpriv has working IPv4 and IPv6 connectivty
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-artful-unpriv doesn't have an IPv6 address
PASS: ubuntu-core-16-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-core-16-unpriv has working IPv4 and IPv6 connectivty
PASS: ubuntu-precise-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-precise-unpriv has working IPv4 and IPv6 connectivty
PASS: ubuntu-trusty-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-trusty-unpriv has working IPv4 and IPv6 connectivty
PASS: ubuntu-xenial-priv has working IPv4 and IPv6 connectivty
PASS: ubuntu-xenial-unpriv has working IPv4 and IPv6 connectivty
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 :

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.

Stéphane Graber (stgraber) wrote :

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 :

This is caused by the fix for https://bugs.launchpad.net/maas/+bug/1655440. I guess netplan needs some way of spelling all of "do dhcp6", "use kernel default for RA", "do not configure ipv6 at all". My inclination is that we should add syntax for the last one, which would break 1655440 again but well. People are hard :)

Stéphane Graber (stgraber) wrote :

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 :

This bug was fixed in the package nplan - 0.29

---------------
nplan (0.29) artful; urgency=medium

  * Fix autopkgtests in a world where /run/NetworkManager/conf.d already
    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://launchpad.net/ubuntu/+source/nplan/0.29~17.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nplan (Ubuntu Zesty):
status: New → Fix Committed
tags: added: verification-needed verification-needed-zesty
Brian Murray (brian-murray) wrote :

Hello Stéphane, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.29~16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

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-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nplan (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed-xenial
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers