support for ipv4 link-local addressing

Bug #1771704 reported by Steve Langasek on 2018-05-17
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
netplan
Medium
Unassigned
netplan.io (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

[Impact]
Ubuntu users who make use of IPv4 link-local addresses.

[Test case]
1) Add 'link-local: [ ipv4 ]' to the netplan configuration.
2) Run 'sudo netplan apply'

[Regression Potential]
Enabling link local means additional addresses are available on the system, usually in the form "169.254.XXX.XXX". This is, in effect, a potential security issue if it is enabled on untrusted networks (it gives systems a fairly well known, discoverable IP address as attack surface). This is not considered a regression from previous releases of Ubuntu given that avahi has been available on desktop, with the same potential issue. The availability of extra addresses might however mean that the system is considered online or reachable via the additonal addresses earlier than previously possible, which may lead to confusion for the user.

---

Per https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1717983, link-local address support was previously handled via integration between avahi-autoipd and dhclient. systemd-networkd does not invoke dhclient. It also has direct support for configuring link-local ipv4 addresses. But this support is not enabled by default.

It should be possible for a system configured via netplan to make use of link-local ipv4 addresses, without needing to configure systemd-networkd directly.

Historically we do not turn on link-local ipv4 support automatically on servers (avahi-autoipd not installed by default), and we use link-local addresses only as a fallback when dhcp gives no response. So this should likely not be enabled by default, but instead be exposed as an additional configuration option in netplan yaml.

tags: added: id-5afcc87c960c0f29bc4856ad
Steve Langasek (vorlon) on 2018-06-11
Changed in netplan:
status: New → In Progress
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netplan.io - 0.39

---------------
netplan.io (0.39) cosmic; urgency=medium

  * New upstream release:
    - Allow link-local addresses to be configured. (LP: #1771704)
    - Forces bridges with no addresses to be brought online. (LP: #1736975)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 16 Jul 2018 08:15:05 -0400

Changed in netplan.io (Ubuntu):
status: New → Fix Released
description: updated
Changed in netplan:
status: In Progress → Fix Released

Hello Steve, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40~18.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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in netplan.io (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
Łukasz Zemczak (sil2100) wrote :

Hello Steve, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40.1~18.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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

root@harmless-perch:~# dpkg -l netplan.io | grep ii
ii netplan.io 0.40.1~18.04.1 amd64 YAML network configuration abstraction for various backends

Marking verfication-done:

I have checked that the excerpt:

link-local: [ ipv4 ]

(or ipv6)

Is accepted in netplan.io configuration files, and leads to the addition of a link-local address of the right type by systemd-networkd:

root@harmless-perch:~# ip addr show eth0
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:28:64:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.230.104/16 brd 169.254.255.255 scope link eth0
       valid_lft forever preferred_lft forever
    inet 10.249.129.212/24 brd 10.249.129.255 scope global dynamic eth0
       valid_lft 3514sec preferred_lft 3514sec
    inet6 fd42:e082:20ba:6e5d:216:3eff:fe28:6402/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3178sec preferred_lft 3178sec
    inet6 fe80::216:3eff:fe28:6402/64 scope link
       valid_lft forever preferred_lft forever

tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
Daniel Axtens (daxtens) wrote :

Hi,

I added this to my netplan-config-tester and it's turned up a couple of issues with NetworkManager.

1) If a static IPv4 address is specified and link-local: [ipv4] is specified, there is no link-local address added. The documentation doesn't make this clear; it only refers to DHCP conflicting with link-local.

network:
  ethernets:
    ens7:
      addresses: [16.16.250.1/22]
      link-local: [ipv4]
      renderer: NetworkManager
  version: 2

ubuntu@netplan2:~$ sudo ip a flush dev ens7
ubuntu@netplan2:~$ sudo ip l set dev ens7 down
ubuntu@netplan2:~$ sudo netplan apply
ubuntu@netplan2:~$ sleep 15 # give LL addresses time to be set up
ubuntu@netplan2:~$ ip a show dev ens7
9: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff
    inet 16.16.250.1/22 brd 16.16.251.255 scope global noprefixroute ens7
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:feb4:26e/64 scope link
       valid_lft forever preferred_lft forever

This is doubly wrong: there's not IPv4 LL address and there is an IPv6 LL address. Which leads me to bug 2...

2) With NM, link-local: [ipv4] and link-local: [] don't disable a IPv6 LL address.

If you modify the config file above to have link-local: [] and repeat the test, you still get an IPv6 link-local address.

I don't know if you want to gate the backport on this working/being documented correctly or if you'd prefer this to go through for now while we get it fixed upstream. Let me know.

Regards,
Daniel

Steve Langasek (vorlon) wrote :

I think we should not block the SRU of the netplan that allows users to declare their intended network config. There will be some work to get the backends to catch up, and that's ok.

Hi Steve,

No worries, that sounds fair enough. I will file the bugs as separate
issues in the next few days then.

Regards,
Daniel

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers