[Bug 1655440] Re: "unconfigured" NIC can still get IPv6 addresses via RA

[Launchpad Bug Tracker]

This bug was fixed in the package nplan - 0.25

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

  * tests/generate.py: add a test to validate that correct blacklist entries
    are added when creating virtual devices.
  * tests/integration.py: clean up after br0 in networkd's test_bridge_mac; as
    the remaining interface and udev configuration can confuse NetworkManager
    now that it seems to manage random devices it did not create again.
    (LP: #1699371)
  * src/nm.c: set the MTU even though we also specify it in systemd-networkd
    for consumption by udev. NetworkManager will try to set it and might
    otherwise default to the wrong value.
  * src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
    same config, SLAAC), and don't have static addresses set. This should fix
    the cases where unconfigured devices still get an IPv6 address.
    (LP: #1655440)
  * src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is otherwise not
    configured; this follows the same logic as setting IPv6AcceptRA=no in
    networkd, with the exception that NM does not currently disable RAs. When
    it does, an unconfigured device for IPv6 will truly be left with no config.

 -- Mathieu Trudel-Lapierre <cyphermox at ubuntu.com>  Thu, 13 Jul 2017
16:22:18 -0400

** Changed in: nplan (Ubuntu)
       Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nplan in Ubuntu.
https://bugs.launchpad.net/bugs/1655440

Title:
  "unconfigured" NIC can still get IPv6 addresses via RA

Status in curtin:
  New
Status in MAAS:
  Triaged
Status in netplan:
  Triaged
Status in nplan package in Ubuntu:
  Fix Released

Bug description:
  TL;DR A MAAS NIC that is set to "unconfigured" (or "link up") will get
  no IPv4 address, but it might still get an IPv6 address via router
  advertisements (RA), if there is such a service in that network
  segment.

  Whether this is a bug or not is up for discussion. That's the point of
  this ticket, actually, so that this discussion can be had and be
  recorded.

  We found out about this when we couldn't get any connectivity to
  instances of an openstack cloud deployed by the autopilot.

  After much debugging, we found that the problem was with the br-data
  bridge on the neutron-gateway node: it didn't have the external NIC
  (eth1) as part of the bridge.

  The neutron-gateway charm, before adding any NIC to a bridge, performs
  certain checks to see if it's really unused. One of these checks looks
  for IP addresses on the NIC, both IPv4 and IPv6. In MAAS, that node
  had eth1 set to "unconfigured", so that eth1 is just "up", but has no
  IP (v4) address. Turns out this NIC had gotten an IPv6 ULA from an
  openwrt router in that network segment. That was enough for the charm
  to not add it to the br-data bridge, thus breaking connectivity to
  openstack instances that were later brought up.

  We shut down the RA service on the openwrt router and then everything
  worked as expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1655440/+subscriptions