NetworkConfiguration
wording of 'inform' option in man page may be misleading
The wording of the 'inform' option in the dhcpcd man page seems to be at odds with RFC 2131.
man 8 dhcpcd:
inform [address[/cidr[/broadcast_address]]] … sends a DHCP INFORM instead of DISCOVER/REQUEST. This does not get a lease as such, just notifies the DHCP server of the address in use.
but RFC 2131 3.4 states that DHCPINFORM is used to obtain information from the server, not to inform it of anything.
If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message … [without] checking for an existing binding The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.
Granted, nothing in the spec forbids a DHCP server from inferring the source address of a DHCPINFORM should not be leased, but the manpage seems to describe a different behaviour than what seems to be intended: for the client to obtain DNS/gateway etc. addresses when already configured with an IP.
You should quote the whole text :)
RFC2131 3.4
The servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message.
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.
There is nothing to infer on the server - the DHCP client INFORMS the server what IP it will use. This can either be ACKed or NAKed.
DHCPv6 on the other hand fixed this - no IP address is sent during the INFORMATIONREQUEST.
Thanks Roy. I only selectively quoted for brevity, not to hide anything. I still don't think the full text of 3.4 provides for the interpretation:
the DHCP client INFORMS the server what IP it will use
Section 3.1:
DHCPINFORM Client to server, asking only for local configuration parameters; client already has externally configured network address.
DHCPINFORM message
The server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes other parameters in the DHCPACK message as defined in section 4.3.1.
So the IP address of the client MUST be in the ciaddr field of the BOOTP message. Just like a RENEW or REBIND message.
That doesn't seem to contradict my reading of the above. Anyway, my intention is not to argue with you. My concern is that users might think that dhcpcd's inform option allows them to safely help themselves to IPs from within a server's lease pool, and that this may not be effective with every DHCP server, depending on how they've interpreted the spec.
Unless anyone can bring anything else to the discussion, I'll defer to your expertise and judgement, if it were a widespread problem you'd already be aware of it. Thanks for the chat.
That doesn't seem to contradict my reading of the above. Anyway, my intention is not to argue with you. My concern is that users might think that dhcpcd's
informoption allows them to safely help themselves to IPs from within a server's lease pool, and that this may not be effective with every DHCP server, depending on how they've interpreted the spec.
Well, that's how I've interpreted the spec. And yes, the INFORM mechanism does allow them to help themselves to an IP address from the pool. But to get there you have to know the pool range. On NetBSD IPv4 DAD is baked into the OS so you can't take someone else's IP address over by default unless you disable the kernel DAD. With dhcpcd creating the address you also get DAD checking on other OS's. But with dhcpcd just informing without managing the address then yes, it can be taken over.
But this is no different from statically assigning an address from the pool without any DHCP. The inform process is just being nice and stating you have taken it so the server doesn't offer it.
Unless anyone can bring anything else to the discussion, I'll defer to your expertise and judgement, if it were a widespread problem you'd already be aware of it.
It's one of the reasons why they removed the sending of the address in DHCPv6. And it's actually less of a widespread problem than someone just adding every IP address in the subnet to their interface and watching the sparks fly.
Thanks for the chat.
Welcome :)
