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. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 12 months |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
DHCPACK destination address
editThe 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)
- RFC2131, Section 4.1 supports the example DHCPOFFER and DHCPACK message 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.
- Techie3 (talk) 05:56, 9 October 2021 (UTC)
History
editWhat's the history of the protocol? I came here to look that up specifically - David Gerard (talk) 09:57, 31 January 2019 (UTC)
- 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)
- @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)
DHCP OFFER and ACK
edit- Moved from my talk. Johnuniq (talk) 22:25, 7 October 2021 (UTC)
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)
- OK, thanks. I missed two points. First, the examples shown at Dynamic Host Configuration Protocol#Operation are for a renewal (the DHCPDISCOVER includes that 192.168.1.100 is requested). Second, the network captures that I have (which confirmed the broadcasts previously shown in the article) are old and are for a client booting with no previous IP. Johnuniq (talk) 08:55, 8 October 2021 (UTC)
IPv4 addresses used
editThe address used in article are in 192.168.1.0/24.
Should the addresses comply RFC 5737 - IPv4 Address Blocks Reserved for Documentation? It reserves blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) and 203.0.113.0/24 (TEST-NET-3) for documentation purposes. — Preceding unsigned comment added by Cfturkja (talk • contribs) 12:04, 20 November 2021 (UTC)
DHCP OP codes / message types
editShould the OP byte in the listed DHCP packet examples only be one of the two defined types in RFC2131: BOOTREQUEST (0x01) or BOOTREPLY (0x02)? 96.38.135.89 (talk) 01:13, 26 June 2024 (UTC)