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)
[RFC 7844#section-3.3]
- 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
[RFC 2131#section-2.2]
- 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
[RFC 2131#section-4.2]
- 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
[RFC 2131#section-4.4.1]
- Is it different the retransmission delays waiting for offer or ack/nak?,
in all states?
Timers
[RFC 2131#section-4.4.5]
- 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
[RFC 7844#section-3.3]
- 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?