Talk:Dynamic Host Configuration Protocol

This is the talk page for discussing improvements to the Dynamic Host Configuration Protocol article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 12 months

This article has not yet been rated on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.

Computing: Networking C‑class High‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
C	This article has been rated as C-class on Wikipedia's content assessment scale.
High	This article has been rated as High-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).

Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.

Internet C‑class High‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
C	This article has been rated as C-class on Wikipedia's content assessment scale.
High	This article has been rated as High-importance on the project's importance scale.

Client ID is starting to replace MAC address

And this article is still assuming that the client is presenting a MAC address. I've pushed in some qualifications, but haven't provided any RFC's or references.

Most of the documentation on the web still assumes that clients will be presenting either EUI-48 or EUI-64 identifiers, but that's no longer the case: current Linux distributions (including Ubuntu) are presenting to DHCP machine ID's that do not include hardware-level identifiers at all.

The reason described for this change is that a machine with wired and wireless connections should by default present and acquire the same identification on both channels. This is not true if the hardware-level id's are bound to application-level ids, which happens if hardware-level id's are bound to IP address.

I notice that a comment about this was made on the talk page in 2007, so the technology is not new, but it's becoming more widespread — Preceding unsigned comment added by 203.206.162.148 (talk) 01:59, 6 September 2018 (UTC)[reply]

DHCPACK destination address

The example DHCPACK message lists 192.168.1.100 as its destination address in the IP section which contradicts teaching literature (Kurose & Ross: Computer Networking: A Top-Down Approach, where DHCP ACK is still being broadcasted) and seems to be at odds with RFC2131, Section 3.2.3. The example might still be correct, but if so an explanation why the offered IP address may already be used would be helpful.

Paul4096 (talk) 10:21, 14 October 2018 (UTC)[reply]

RFC2131, Section 4.1 supports the example as correct:

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address (i.e not 255.255.255.255) and the link-layer destination address is set to the DHCP 'chaddr' address.

Kurose & Ross: Computer Networking: A Top-Down Approach, contradicts the standard in this respect. Techie3 (talk) 00:20, 8 October 2021 (UTC)[reply]

Hard to read sentence in section "DHCP relaying"

The following sentence is really hard to read:

In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it does not have a routable IP address, does not know the link layer address of a router and does not know the IP address of the DHCP server.

93.104.239.68 (talk) 13:10, 21 December 2018 (UTC)[reply]

History

What's the history of the protocol? I came here to look that up specifically - David Gerard (talk) 09:57, 31 January 2019 (UTC)[reply]

From checking, the history section was removed from the article on 05 December 2017. I've re-edited the information from the last version, from 01 December 2017, back into the current version of it. Cyclonius (talk) 23:26, 16 April 2019 (UTC)[reply]

@Cyclonius: You inadvertently restored a cleverly disguised advertisement for the Enterprise ISC DHCP server software. I've removed that part. DavidDelaune (talk) 17:52, 27 July 2019 (UTC)[reply]

DHCP OFFER and ACK

Moved from my talk. Johnuniq (talk) 22:25, 7 October 2021 (UTC)[reply]

No, they can and should be IP unicasted. Per the standard:

A server or relay agent sending or relaying a DHCP message directly
to a DHCP client (i.e., not to a relay agent specified in the
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
field. ... If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast 
to the IP address specified in the 'yiaddr' field and the link-layer address specified 
in the 'chaddr' field.

Techie3 (talk) 11:01, 7 October 2021 (UTC)[reply]