Does the current master branch support binding the local link address of 169.254.x.x assigned by the DHCP server?

[Novazhangquan]

Does the current master branch support binding the local link address of 169.254.x.x assigned by the DHCP server?

[rsmarples]

No.

https://datatracker.ietf.org/doc/html/rfc3927#section-1.6

[1.6]  Alternate Use Prohibition

   Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
   manually or by a DHCP server.  Manual or DHCP configuration may cause
   a host to use an address in the 169.254/16 prefix without following
   the special rules regarding duplicate detection and automatic
   configuration that pertain to addresses in this prefix.  While the
   DHCP specification [[RFC2131](https://datatracker.ietf.org/doc/html/rfc2131)] indicates that a DHCP client SHOULD
   probe a newly received address with ARP, this is not mandatory.
   Similarly, while the DHCP specification recommends that a DHCP server
   SHOULD probe an address using an ICMP Echo Request before allocating
   it, this is also not mandatory, and even if the server does this,
   IPv4 Link-Local addresses are not routable, so a DHCP server not
   directly connected to a link cannot detect whether a host on that
   link is already using the desired IPv4 Link-Local address.

   Administrators wishing to configure their own local addresses (using
   manual configuration, a DHCP server, or any other mechanism not
   described in this document) should use one of the existing private
   address prefixes [[RFC1918](https://datatracker.ietf.org/doc/html/rfc1918)], not the 169.254/16 prefix.

[Novazhangquan]

At which step is the actual binding of IP address to the network card performed? Is it within the child process?

[Novazhangquan]

dhcpcd eth1 --debug dhcpcd-8.1.6 starting eth1: executing /usr/libexec/dhcpcd-run-hooks' PREINIT eth1: executing /usr/libexec/dhcpcd-run-hooks' CARRIER DUID 00:01:00:01:2f:c1:3e:1c:54:b5:6c:1b:ec:4e eth1: IAID 6c:1b:ec:4e eth1: delaying IPv6 router solicitation for 0.8 seconds eth1: delaying IPv4 for 0.7 seconds eth1: using ClientID 01:54:b5:6c:1b:ec:4e eth1: reading lease /var/db/dhcpcd/eth1.lease' eth1: rebinding lease of 169.254.237.208 eth1: sending REQUEST (xid 0x790d2c43), next in 3.2 seconds eth1: acknowledged 169.254.237.208 from 169.254.237.207 eth1: probing address 169.254.237.208/16 eth1: probing for 169.254.237.208 eth1: ARP probing 169.254.237.208 (1 of 1), next in 1.0 seconds eth1: soliciting an IPv6 router eth1: sending Router Solicitation eth1: DAD completed for 169.254.237.208 eth1: leased 169.254.237.208 for 216000 seconds eth1: renew in 86400 seconds, rebind in 86400 seconds eth1: writing lease /var/db/dhcpcd/eth1.lease' eth1: adding IP address 169.254.237.208/16 broadcast 169.254.255.255 eth1: adding route to 169.254.0.0/16 eth1: adding default route via 169.254.237.207 eth1: ARP announcing 169.254.237.208 (1 of 2), next in 1.0 seconds eth1: executing `/usr/libexec/dhcpcd-run-hooks' BOUND forking to background forked to background, child pid 4327 dhcp_bind: Cannot assign requested address

[BedRockJie]

The reference in RFC 3927 should indicate that this address SHOULD NOT be configured manually or via a DHCP server, as this address segment has specific special attributes. On Windows, APIPA (Automatic Private IP Addressing) is used to implement this protocol, while most network management tools on Linux have adopted this standard, such as systemd-networkd and NetworkManager.

Why doesn't dhcpcd consider implementing this reference standard?

[rsmarples]

The reference in RFC 3927 should indicate that this address SHOULD NOT be configured manually or via a DHCP server, as this address segment has specific special attributes. On Windows, APIPA (Automatic Private IP Addressing) is used to implement this protocol, while most network management tools on Linux have adopted this standard, such as systemd-networkd and NetworkManager.

Why doesn't dhcpcd consider implementing this reference standard?

dhcpcd fully supports RFC 3927 and has done since before systemd was invented. The issue being reported is that the IPv4 LL address range may not entirely work if set by DHCP instead.

[BedRockJie]

The reference in RFC 3927 should indicate that this address SHOULD NOT be configured manually or via a DHCP server, as this address segment has specific special attributes. On Windows, APIPA (Automatic Private IP Addressing) is used to implement this protocol, while most network management tools on Linux have adopted this standard, such as systemd-networkd and NetworkManager. Why doesn't dhcpcd consider implementing this reference standard?

dhcpcd fully supports RFC 3927 and has done since before systemd was invented. The issue being reported is that the IPv4 LL address range may not entirely work if set by DHCP instead.

I understand.

I think the 169.254/16 IP offered by DHCP should be rejected. Stick with the 169.254/16 IP we report for setup and conflict detection.

[Novazhangquan]

Should the client terminate the communication with the DHCP server and directly select the IPv4LL address after receiving the local link address assigned by DHCP, rather than reporting an error when applying the IP after the DHCP process is completed?

[rsmarples]

Should the client terminate the communication with the DHCP server and directly select the IPv4LL address after receiving the local link address assigned by DHCP, rather than reporting an error when applying the IP after the DHCP process is completed?

It doesn't report an error as such, it does get confused a little though. I am testing a small patch right now.

[Novazhangquan]

OK

[Novazhangquan]

Have your modifications yielded any results?

[Novazhangquan]

I am using the master branch. I can assign the allocated IP address 169.254.x.x to the network card.

[perkelix]

@Novazhangquan Does the 10.3.0 that was released a few days ago fix the issue?