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?


[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.


[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?