Summary of questions regarding the RFCs and the implementations¶
This is a summary of the questions stated in RFC7844 DHCPv4 restricted version summary
Message Options¶
Requested IP Address Option (code 50)¶
Is there a way to know
if
the link-layer address changed without leaking the link-layer?
Not specified in RFC7844, but in RFC2131¶
Probe the offered IP¶
does any implementation issue an ARP request to probe the offered address?
is it issued after DHCPOFFER and before DHCPREQUEST, or after DHCPACK and before passing to BOUND state?
Retransmission delays¶
Sending DHCPDISCOVER [RFC 2131#section-4.4.1]
is the DISCOVER retranmitted in the same way as the REQUEST
[RFC 2131#section-3.1], [RFC 2131#section-4.4.5], [RFC 2131#section-4.1]
the delay for the next retransmission is calculated with respect to the type of DHCP message or for the total of DHCP messages sent indendent of the type?
without this algorithm being mandatory, it’d be possible to fingerprint the the implementation depending on the delay of the retransmission
how does other implementations do?
Selecting offer algorithm¶
what is a “no acceptable offer”?
which are the “strategies” to select OFFER implemented?
how many offers to wait for?
different algorithms to select an OFFER could fingerprint the implementation
Is it different the retransmission delays waiting for offer or ack/nak?, in all states?
Timers¶
what’s the fixed value for the fuzz and how is it calculated?
The “fuzz” range is not specified, the fuzz chosen could fingerprint the implementation.
Leases¶
is there a way to know if the network the client is connected to is the same to which it was connected previously?
Not specified in any RFC¶
is it needed to check that the ACK options match with the OFFER ones?
is it needed to check that all options make sense?, which ones?