0

On Linux Kernel 4.19.94+, I could see IPv4 private and link-local address assigned to the interface eth0 as shown below. My understanding is that Automatic Private IP Addressing (APIPA) IP address (169.254.0.0/16) is only assigned when no IP address is allocated by DHCP server.

According to Bill Manning's Documenting Special Use IPv4 Address Blocks spec:

169.254.0.0/16 has been ear-marked as the IP range to use for end node auto-configuration when a DHCP server may not be found. As such, network operations and administrators should be VERY aggressive in ensuring that neither route advertisements nor packet forwarding should occur across any media boundaries. This is true for the Internet as well as any private networks that use the IP protocols. End node administrators should be aware that some vendors will auto-configure and add this prefix to the nodes forwarding table. This will cause problems with sites that run router discovery or deprecated routing protocols such as RIP.

Following the above information, please can someone clarify the following:

What causes 169.254.0.0/16 assignment on Linux version 4.19.94 when DHCP server has successfully assigned an IPv4 address?

This is found to cause problems while sending broadcast messages.
How can this assignment of link-local be disabled when a private IP address is assigned to the interface?

Does this assignment causes duplicate network packets or increases network overhead, especially when using SSDP protocol or other service protocol.

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq qlen 1000
    link/ether 00:1c:2b:13:06:2f brd ff:ff:ff:ff:ff:ff
    inet 169.254.196.187/16 brd 169.254.255.255 scope link eth0
       valid_lft forever preferred_lft forever
    inet 192.168.0.20/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:2bff:fe13:62f/64 scope link 
       valid_lft forever preferred_lft forever
1
  • Something on your system setup (whichever distro you use) is wrong. This has nothing to do with the kernel.
    – dirkt
    Jul 4, 2020 at 14:56

1 Answer 1

1

The above behaviour is caused by having the assignment "LinkLocalAddressing=yes" in Network section of systemd/network/10-eth0.network configuration.

This is clearly a bug with systemd network; details of this bug can be viewed here https://github.com/systemd/systemd/issues/13316 ;

Due to the current systemd bug, it would not be possible to have IPV4LL (IPV4 Link-Local Address) address assigned when no DHCP server is found.

If LinkLocalAddressing=fallback is set then DHCP client will stop listening to DHCP server after assigning IPV4LL address. This violates RFC 3927 (Ref https://tools.ietf.org/html/draft-ietf-dhc-dna-ipv4-01). This would imply when DHCP server is back online, previously assigned IPV4LL address will not get dropped and new address from DHCP server will never be assigned to the client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.