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?