Jump to content

Talk:Dynamic Host Configuration Protocol/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Alternative name?

I have seen DHCP referred to as "Dynamic Host Control Protocol" as well as "Dynamic Host Configuration Protocol" from many sources. Cisco even has both names on the same page. —Preceding unsigned comment added by Stealthbreed (talk • contribs) 18:37, 9 February 2009 (UTC)

It is a common misnaming. It is easy to think DHCP provides control, because the philosophy of design behind it is very much fascist "dictating from the center of control." But according to the document /that defines it/, RFC 2131, DHCP is Dynamic Host Configuration Protocol. 67.161.51.194 (talk) 00:27, 24 April 2009 (UTC)

Is DHCP really in application layer?

According to Andrew Tanenbaum's Computer Networks, DHCP is categorized as one of network layer protocols.—Preceding unsigned comment added by 158.195.97.239 (talk • contribs) 19:07, May 1, 2007

It is a protocol built on top of a transport layer protocol (UDP), hence it is an application layer protocol. Justdelegard 19:29, 18 May 2007 (UTC)

While the IETF isn't as compulsive about layering as are basic educators using the OSI model -- even OSI architects don't limit themselves to seven layers -- DHCP is definitely a network layer management protocol. It is the payload of a protocol that defines what it manages.
Routing protocols are useless if they could not affect the network layer, but ISIS runs directly over data link, OSPF and EIGRP directly over IP, RIP over UDP, and BGP over TCP. Howard C. Berkowitz 13:43, 12 July 2007 (UTC)

Ofcourse OSPF, DHCP, BGP etcetera are network management protocols, but their communication occurs at the application layer. The encapsulation into a transport layer protocol defines them as application layer. —Preceding unsigned comment added by 145.58.13.97 (talk) 09:16, 7 November 2007 (UTC)

Killing DHCP with RJ45 cat 5e connectors

Placing the 2 green wires together with the two orange wires on the outside of the green wires in the 1-4/4-8 pin connection on the RJ45 connector(Thanks phone companies for clearing up that distinction), wipes out DHCP. While straight through connections should work just fine, this particular configuration on a cat 5e cable appears as a solid LAN connection. The twisted wire pairs in this episode prevent DHCP through some undetermined cause of interference from propagating and therefore no IP no talk. Basically, fatal error when wired this way for a network.

Shows as connected, though, and repeatable on cable modem and t-1. No DHCP. Fatal Network error.

Slow? NO. Fatal Network Error!

(Time for the cat-5e people to fess up. Use as directed or fatal network errors will happen inside of 40' of wiring it up. 6 recrimps, two networks, two cables. I'm not happy.)

—The preceding unsigned comment was added by 68.218.61.120 (talk • contribs) 08:58, February 8, 2007 (UTC)

Well... I assume this post is in the DHCP article discussion because you couldn't get an address and since the link lights were on, you assumed it must be a DHCP issue? My first thought is always verify cables with a proper tester as you build them. Second thought is when you suspect DHCP is the culprit, try manually setting a valid unused IP address and ping the default gateway. If that doesn't work, then DHCP isn't your culprit. DigitalSorceress 13:38, 6 August 2007 (UTC)

Overview Grammatical Error

The first sentence in the overview is incorrect. I am not sure how it should read, but it should be revised. —The preceding unsigned comment was added by 69.179.96.238 (talk • contribs) 13:00, September 23, 2006 (UTC)

The following sentance was modified by refering to a previous version of the article: From: The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnetup or regains connectivity to the network.

to: The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default routers, and other IP parameters. The assignment usually occurs when the DHCP configured machine boots up or regains connectivity to the network.AdamJudd 11:43, 23 October 2006 (UTC)

Article is too long

The article is far too long. The lengthy tables should be removed, and replaced with a link to the information source (standards organization.) --194.237.142.10 08:25, 20 February 2006 (UTC)

Additionally, the lead is exceptionally lengthy and intimidating to the reader. — SheeEttin {T/C} 22:19, 3 July 2006 (UTC)
Please keep the tables in - this is a refernce of the standard and is EXTREMELY helpful. I don't feel like we should provide links to standardized, static content, we should be the place that people link to. Steeltoe 19:58, 6 July 2006 (UTC)
At the very least, the intro should be much shorter, I'd say two paragraphs at the most. It should be in plain English. Even the first paragraph of the current article is too technical. I work in networking, and it was almost over my head. It shouldn't take a Bachelor's in a computing field to understand the intro. --132.177.122.132 18:43, 10 July 2006 (UTC)
We should provide links to these RFCs, since they describe the matter in more depth and (mainly) because the RFCs are a standard, not some wikipedia. It does not matter if content is dynamic or static. By providing links to primary sources we allow others to check we are not lying, to complain if original idea is wrong, ... (OMG I thought that providing refereces was obvious. See Wikipedia:Verifiability.) We want to be (but not should be) the place people link for explanation of DHCP, but if they need more than just basic info, like the standard one should obey, we have to provide them. The subject is not ours. --Alvin-cs ✉ 19:47, 5 August 2006 (UTC)
On August 17, 2006, user 203.76.129.202 removed large parts of this article that were really useful. I have restored them. Perhaps this article is too long, but then the lists of extensions (for instance) should be moved to a separate article, not deleted. Ehn 17:57, 21 August 2006 (UTC)
It is a complex subject, not easily reduced to Readers Digest style abridgement, and I think being more comprehensive is warranted. Paul Robinson (Rfc1394) 20:03, 28 August 2006 (UTC)

DHCP Reservations

There is no mention of reservations. This is worth noting, as address reservations allow the management ease of DHCP while ensuring that certain nodes always get the same address. —The preceding unsigned comment was added by Dbeckman (talk • contribs) 19:26, February 22, 2006 (UTC)

  • Are you referring to the "automatic" mechanism for assigning DHCP addresses? (see RFC 2131, page 2.) I added a paragraph to describe the different mechanisms that the standard provides for allocating addresses, would you look and see if this addresses the issue? The mechanism to be used in a particular case would be controlled by a network administrator when configuring the dhcp server, and the language used to describe what he does will vary depending on which dhcp server he is using, so you may have seen different names for this. Ngriffeth 13:51, 12 July 2007 (UTC)
  • Actually, I see merit in both your points. I agree that automatic does indeed cover it, but that many people know this feature as DHCP Reservations. I'm going to put in a note in the section that describes automatic to the effect that it is sometimes referred to as reservation. I know that Microsoft Windows Server 2000/2003 (and possibly NT4 Server) use the term reservation, and that this is true of many consumer firewall/router devices. --DigitalSorceress 13:53, 6 August 2007 (UTC)

Errors

The section describing DHCP requests says a client message includes the NetBIOS name of the host. This is hardly correct (it must at least be optional)? There is many other inconsistensies throughout the Technical details section. For instance, the section starts out with stating that DHCP operations fall into four (superficial?) phases and then goes on to discuss seven different phases. Also, the DHCP requests section deals largely with DHCPDISCOVER and DHCPOFFER messages, the subject of the two preceding sections, but fails to describe DHCPREQUEST messages. --AndersFeder 02:18, 13 August 2006 (UTC)

The diagrams of message headers are nice, but the '192 octest of zeroes' is misleading. These are the FILE and SNAME fields, which still have a purpose for diskless/network-booting clients (even though there are dhcp option analogues). Even without that use, 'option overloading' permits options to be encoded in this field should an overload option be presentin the data portion of the DHCP packet. —The preceding unsigned comment was added by 204.152.187.72 (talk • contribs) 19:09, October 10, 2006 (UTC)

in "Implementations" it reads "infoblox has been shipping a DHCP server appliance since 1945." unlikely! also should not be "appliance" —The preceding unsigned comment was added by 80.229.43.106 (talk • contribs) 10:03, October 18, 2006 (UTC)

From my experience implementing the protocol, the "magic cookie" used to denote the start of the options section is actually 0x63538263, not 0x63825363 (note the slight difference in the byte order). This was determined from tests done in a Windows environment, can somebody either confirm or refute this observation? Is there a reference for this? --Sflanker (talk) 00:52, 10 December 2007 (UTC)

This is an annoying quality of the magic cookie DHCP/BOOTP selected; the first and last octet are the same (99 or 0x63), so a high to low endian swap only switches the inner two bytes and makes spotting a byte order mismatch hard. Suffice to say, the correct order is defined in references; RFC2131 and before that RFC1497, and it is the one cited in this wiki article. What you are looking at is your host byte order in an integer, which is a strange way to look at the cookie...it really is just a 4 octet magic string, not a number. —Preceding unsigned comment added by 204.152.187.72 (talk) 18:19, 18 December 2007 (UTC)

The article makes continuous mention of MAC Addresses as the means through which a server identifies a client. The truth is that this is a fallback if the client fails to produce a Client-Identifier option. Be careful to avoid a rathole here; there are clients (Windows) which emit a Client-Identifier option that is identical to their MAC Address, and there are some incompatible server/client interaction behaviours as a result particularly involving multi-stage network bootloaders (eg WinCE over PXE). Suffice to say, I think virtually every mention of the word 'mac address' should be replaced with 'client identity' or 'client identifier'. 204.152.187.72 (talk) 19:39, 18 December 2007 (UTC)

Simple Summary

I have changed the original first paragraph of the article to be under "Introduction" and inserted a (one sentence!) summary of the purpose of the protocol. I think this makes the article more useful to those who simply want to know what the term means, without having to read an overly prolix description. Paul Robinson (Rfc1394) 20:03, 28 August 2006 (UTC)

Linux computer

"An alternative to a home router is to use a Linux computer with a fixed IP address as a DHCP server" Why this emphasis on Linux? Is it impossible, or much rarer, to use another OS for this purpose ? Apokrif 16:33, 1 September 2006 (UTC)

how create web server with DNS

i have a problem with my compcvbcvb i try o setting me network with DHCP But I've got new problem with them how i can create 2 or more web site in my server with DHCP

thx before —Preceding unsigned comment added by 125.163.224.11 (talk • contribs) 01:57, October 19, 2006

Why??

This article is quite complex to read - It's got too many complicated words in it. From what I understand from reading, DHCP server stores tables of information about the subnet masks, ip addresses, mac addresses, and the dhcp protocol is used to communicate with the dhcp server???

Even If I do understand what is happening - it is still worded very badly.

The other thing is, I don't know why you use a DHCP Server, and protocol -what is the purpose of using it, what benefits does it have, give a scenario of where you would use this, and the steps that would occur.

There's no use writing an article that only people with the knowledge of the article's contents can understand!!!! —The preceding unsigned comment was added by 203.97.116.147 (talk • contribs) 21:33, October 30, 2006 (UTC)

If you dont understand these basic concepts look at the other Wiki pages that explain them. Or just get a tutor.

I agree. There's a horrid tendency in these technical articles to "say it exactly right" when "exactly right" is just gibberish. I have an M.S. Computer Science from an engineering university and don't know who could possibly be interested the bit settings of the protocol; those settings make up about half the article. A half dozen device driver engineers on the entire planet might be interested but who else?????
Even a term like "protocol" may be out of place in an encyclopedia.
Couldn't the article say, "Each computer or printer on an Ethernet network has an identification number assigned to it These numbers allow the router to direct messages, which are small portions of web pages, data, parts of images, sounds, print images, to the computer or printer. When the computer or printer starts up, it asks the router for an identification number. The router gives each computer or printer a unique identifier. This act of requesting and assigning numbers is called DHCP, or Dynamic Host Configuration Protocol (but who-the-F-cares.)"

no. higher level languages are needed to express higher level ideas. As i mentioned above... if u dont know what protocol means look it up in wiki or anywhere on the internet or a book.

"For a home or small business network, the numbers usually start with 192.168.1.1; the next number in the sequence would be 192.168.1.2, and so on."
"This is true for both wired and wireless networks. The identification numbers, 192.168.1.3 and so on, are properly called IP Addresses, Internet Protocol Addresses. A router is usually the DHCP server but some networks use computers."
Even mentioning "Layers", as in "OSI Layers" seems silly. That's an abstraction that might be interesting to an academic but it's meaningless and conveys zero information to most readers. Quite frankly "Layers" do not exist. Why does the physical layer include Wifi? I know it's the same as 10-100baseT, in concept but darn it, you can't see it, touch it, leave it out.
And so on. -kh —The preceding unsigned comment was added by 63.125.4.210 (talk • contribs) 16:56, January 16, 2007 (UTC)

How will i configure a fix IP address to the PC? i want to give a fix IP add to my PC but dont know how. —The preceding unsigned comment was added by 210.23.184.160 (talk • contribs) 18:43, January 21, 2007 (UTC)

DHCP

1.Can BOOTP client boot from a DHCP server?

yes. backward compatibility is mentioned in the article.

2.Can DHCP client boot from a BOOT server? —The preceding unsigned comment was added by 124.82.47.26 (talk • contribs) 19:58, January 24, 2007 (UTC)

no. obviously not.

Actually, it's not that obvious. There's no reason a BOOTP server couldn't reply to a DHCP query made by a client with a BOOTREPLY, addressing the client. There's no reason a client couldn't support receiving and digesting such responses. In practice? No one does this, and there's no good reason to start because BOOTP servers are very few and very far between. 204.152.187.72 (talk) 19:19, 18 December 2007 (UTC)
Actually, it is that obvious. Just not to you. J/k. Seriously: A DHCP client can 'notice a BOOTP reply and downgrade', but realistically no one does this for at least two reasons; 1) BOOTP is dead and gone. 2) It represents a 'downgrade attack vector' if you also implement DHCP authorization extensions. 67.161.51.194 (talk) 00:31, 24 April 2009 (UTC)

BOOTP relay and DHCP agent remote id.

I think this article confuses BOOTP relay and DHCP agent remote ids. Many datacenter and enterprise environments use BOOTP relay to forward broadcasted DHCP packets to a configured DHCP server in another subnet. The article is in error in stating that option 82 is used to identify the source network. The Gateway field of the DHCP packet identifies the source subnet and is used by the DHCP server to identify the scope to allocate from. Option 82 is used with 'agent remote id' information to provide multiple DHCP configurations, over different vlans, often to the same device or CPE. This is most often used in Triple-play applications where customer ONT devices require separate IP addresses and vlans for voice, video and data; as it allows better QoS and SLA control. Cantuse 19:28, 14 February 2007 (UTC)


The graphic is wrong, re: broadcast and unicast

All DHCP frames are Broadcast and there are no unicast frames either in DHCPOFFER and DHCPACK. Please refer to the RFC2131, and all material subsequent to Table 2 (online reference, http://www.faqs.org/rfcs/rfc2131.html). I don't know how to change the graphics. —The preceding unsigned comment was added by 216.31.219.19 (talk • contribs) 00:50, March 13, 2007 (UTC)

There *are* unicast DHCP packets; this is used when companies have a single DHCP server provide IP addresses for multiple subnets. A router for such a subnet receives the DHCP broadcasts, converts them to unicast (with a destination MAC/IP address of the configured DHCP server, source MAC/IP of the router itself. The field identified as the GIADDR in the main DHCP page is populated with the IP address of the interface on the router it received the DHCP request on. The DHCP server uses the GIADDR field to identify the subnet the device and select an IP address from the correct pool. The DHCP server then sends the DHCP OFFER back to the router via unicast which then converts it back to a Broadcast and out to the correct subnet containing the device requesting an address.

Cisco generally refers to the process as 'helper ip' addresses, whereas general network vendors often refer to it as 'bootp relay'. 71.164.13.180 18:18, 14 April 2007 (UTC)

Yes the graphic is wrong - and grossly over-simplified - the simplest thing to do would be to delete the unicast and broadcast annotations. This oversimplifies it even further, but it least it doesn't contain any actual errors. Ngriffeth 14:13, 12 July 2007 (UTC)
But that said -- Actually, there are other unicast messages in the process according to RFC 2131. For example, "At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." My comments: The DISCOVER message has to be broadcast because the client doesn't know anything, so it doesn't know the server address, but the OFFER message can be unicast. There is a client flag to specifically request a broadcast message if the client can't accept unicast messages before the IP address has been assigned. (There's no logical problem here, since the message is unicast at the hardware layer.) However, as a somewhat informed guess from watching lots of DHCP servers, I would guess that most servers will broadcast the offer in any case. Also, the ACK for a RENEW must be unicast according to the standard. For some additional background on DHCP, The DHCP Handbook by Droms and Lemon is a great and authoritative reference. (Droms wrote the standard, Lemon has been important in implementing the ISC version of the standard.) Ngriffeth 14:13, 12 July 2007 (UTC)
I hope I'm not arguing with myself in an empty room :-) I think that addressing the question of unicast versus broadcast in DHCP messages requires too much explanation to be of use in wikipedia, we could just say that the use of broadcast or unicast varies with the environment and see the standard for the details. Ngriffeth 14:17, 12 July 2007 (UTC)
This is truth; DHCP packets can be broadcast or unicast, end of story. 204.152.187.72 (talk) 19:22, 18 December 2007 (UTC)
It IS incorrect to state that dhcp traffic is Broadcast - unicast - broadcast - unicast. There is some situations where this would happen, but it should be stated that this is not the normal operation. —Preceding unsigned comment added by 84.217.1.101 (talk) 20:59, 24 October 2007 (UTC)

Just to bring this topic back to attention. On graphic about typical DHCP session there should be no broadcast/unicast text, at least for server responses.--Irić Igor -- Ирић Игор -- K♥S (talk) 08:43, 3 June 2008 (UTC)

The text for the image is incorrect, as the image does not show a "typical DHCP session". A typical DHCP session is either all broadcast (address leased for the first time) or all unicast (renewal), but the combined broadcast/unicast most involve for example a router with DHCP relay agent, and could not be seen as a "typical" example. Best is perhaps to replace the image and remove the broadcast/unicast details. —Preceding unsigned comment added by 84.217.0.60 (talk) 08:19, 20 June 2008 (UTC)

It's been two years since it's been reported as wrong, and one year since any more discussion here so I have updated the diagram by removing the broadcast and unicast text. Thomas d stewart (talk) 07:35, 2 June 2009 (UTC)

iptables example

It seems a little outdated to have an ipfw ruleset there but no iptables. Can somebody add an IPTables example. —Preceding unsigned comment added by 69.3.37.2 (talk • contribs) 19:50, May 24, 2007

I'm puzzled by the presence of an iptables discussion here. Wouldn't a link work better? Or is the nature of the interaction between firewalling and dhcp so important and so complex that it needs detailed discussion here? And if so, should there be a link from iptables to this article? A quick text search didn't show me any mention of dhcp on that page. Just wondering. Ngriffeth 14:20, 12 July 2007 (UTC)

IMHO invalid extended acl

IMHO this extended ACL is invalid:
1)because 10,20,30 are ACL numbers dedicated for standard ACL
2)I think only one ACL may be applied to one interface and this is 3 ACLs, so if s.b. wants to apply all of them, he should apply each on different interface.
3) I am not sure about syntax of this ACL...
I think :10 permit udp host 0.0.0.0 "eq bootpc" host 10.32.73.129 eq bootps
"eq bootpc" isn`t IMHO according to extended ACL syntax.
4) maby access-list 110 permit any any should be added to prevent from implicit usage of deny any any

MABY I AM WRONG, IF SO, I APOLOGIZE...

10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps
20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps
30 permit udp any eq bootpc host 255.255.255.255 eq bootps


I think this is correct syntax for extended ACL according to CISCO IOS

access-list 110 permit udp host 0.0.0.0 host 10.32.73.129 eq bootps
access-list 110 permit udp 10.32.73.128 0.0.0.63 host 10.32.73.129 eq bootps
access-list 110 permit udp any host 255.255.255.255 eq bootps
access-list 110 permit any any
interface e0
ip access-group 110

83.208.137.129 03:30, 4 June 2007 (UTC) GHIROS

Does Cisco-specific configuration belong in Wikipedia? Howard C. Berkowitz 13:45, 12 July 2007 (UTC)
Maybe. I recall that other routing vendors advertise "IOS-compatible" interfaces. But, it's a good question. Ngriffeth 14:22, 12 July 2007 (UTC)

The just previous access-list permits anything and is essentially useless (look at the 4th permit - it permits anything), but the syntax is correct. Also, I agree with H. Berkowitz's questioning of including "Cisco-specific ..." in this DHCP article. —Preceding unsigned comment added by Johndoeemail (talk • contribs) 23:44, 9 August 2008 (UTC)

This article is not about how to configure DHCP on Unix

This is a article about the protocol DHCP, still some of the authors must have mistaken it for a manual for configuring DHCP on a Linux / Unix server. Some very long parts talks about specific configuration files on Linux, which is not in the DHCP protocol standard.

Examples:

"When the DHCP server (dhcpd) starts, it reads a configuration file, which by default is /etc/dhcp.conf, but can be changed when the server is started using the -cf option."

More:

"The DHCP server needs a way to manage the leases over reboots to the server and the clients. This is accomplished by the dhcpd.leases files, which are typically inside of the /var/state/dhcp directory. After reading the dhcpd.conf file at system startup, the server reads the file as dhcpd.leases and knows what machines which have active leases accordingly."

And even more out of context:

"Therefore, you should block DHCP traffic through your firewall. If your firewall is running on a Linux machine, you can use the ipfwadm program to block port 67 (which the DHCP listen port) and port 68 (which the DHPC transmit port)."

There are countless firewalls available on the market. Yet the Linux ipfwadm is mentioned without any reason. All firewalls in the world can block upd/67 and udp/68. —Preceding unsigned comment added by 84.217.1.101 (talk) 21:10, 24 October 2007 (UTC)

I agree, and I've taken out those sections because Wikipedia is not a manual on configuring DHCP daemons in UNIX/Linux. — EagleOne\Talk 14:45, 9 November 2007 (UTC)

Perhaps there is also a need for disambiguation between "IETF DHCP", which is a wire format protocol (and what I think this article should be written about), and "ISC DHCP", which is a software suite primarily intended for use on Unix-like systems. They are not the same thing, and for some reason talking about one tends to beg discussion of the other. 204.152.187.72 (talk) 19:28, 18 December 2007 (UTC)

RfC

Large quantities of text have been added to this article, and should be reviewed for accuracy and general applicability. The article also appears to require significant copyediting for style and tone, and formatting by someone familiar with the topic. Acroterion (talk) 12:33, 31 October 2007 (UTC)

I've started some cleaning up, though it will take a while. My main focus will be on readability (i.e. English) and accuracy - though I will need extensive help in both fields. I will be relying on the two current RFCs for accuracy. Note that I will be going first for readability (as this is easier to correct), pruning the article down to get rid of the excess text that has no place here and then analysing the remaining bits for accuracy and potential expansion. Everyone: please help! Nachmore 15:13, 7 November 2007 (UTC)
Hi, I just came to this article from the RfC page. I noticed that the "Basic Server Configuration" sections goes into some pretty specific details about configuring some dhcpd.conf file, without actually explaining what that files, where its used, etc. I think that whole section can go, under the provisions of what wikipedia is not; specifically, section 2.7, WP is not a manual. Client Configuration can go, too. — EagleOne\Talk 21:26, 8 November 2007 (UTC)
Responding to RfC. Problem seems to have been fixed. I have therefore removed to tag.Labongo 13:05, 16 November 2007 (UTC)

Intro text

I recently reverted the intro text that was restored (I won't do it again, to avoid warring). The reasoning is that it makes the intro to long, burdening the reader with lots of facts that are repeated throughout the article. If there was anything in that text that should be in the article (I checked quickly and couldn't see much) then please integrate it into the rest of the article. - Nachmore (talk) 00:19, 22 November 2007 (UTC)

It is more important that an introduction cover the motivation for the technology, rather than simply comply with an arbitrary length. Without the text I added, it was established that that DHCP could dynamically assign addresses, but not why dynamically assigned addresses were an operational advantage. Indeed, I consider it more important to state what problem is being solved rather than to state, in the introduction, how an ill-defined problem is being solved.
The existing introduction tells the reader that DHCP supplies certain parameters, but the necessity of those parameters and the need for efficient administration is not touched upon. Even less important is the history of the protocol and the relationship to BOOTP. I will try again, but I'm going to focus, in the introduction, on the problem to be solved and move the history and the protocol principles of operation into the body. Howard C. Berkowitz (talk) 00:42, 22 November 2007 (UTC)
True, apologies regarding the length statement - it needs to be long enough to explain the point of the protocol. I really like what you have done! - Nachmore (talk) 02:03, 22 November 2007 (UTC)

Client configuration parameters

I removed DHCP options that are taking from http://www.iana.org/assignments/bootp-dhcp-parameters because this list is not correct and should be updated. It's better to look at the source of information, not at the old copy of this. —Preceding unsigned comment added by Tcb (talk • contribs) 11:42, 14 December 2007 (UTC)

Contradictory Terminolgy

The sections "Basic Protocol Operation" ("BPO") & "IP address allocation" contradict each other on the names for the 3 modes/methods for allocating IP addresses. They agree that there are 3, & call them "dynamic", "automatic", & "manual". They each use "dynamic" the same way; not so for the other 2.

"BPO" uses "automatic" (aka DHCP Reservation) where the dhcpd docs use "fixed", & "manual" for what I am used to seeing called "static" -- see: http://wiki.riteme.site/wiki/Static_IP#Static_and_dynamic_IP_addresses .

These terms may be different, but they are not confusing; perhaps clearer than what I am used to.

"IP address allocation", OTOH, uses the same 3 terms, but w/ different meanings: "automatic" seems to be a restatement of "BPO" "dynamic", while "manual" seems to be the same as "BPO" "automatic"; & IMO wrong. —Preceding unsigned comment added by 206.180.152.36 (talk) 17:09, 3 March 2008 (UTC)


This user is correct that there is some misinformation being spread here. The methods of IP allocation seem to be covered twice and wrong.

Dynamic Allocation means 'I the server give you the host requesting an IP address a random available IP from a pool of addresses' Manual Allocation means 'I the systems/network administrator have an 'important' device, and hard coded that a specific IP address is reserved for a specific MAC address'.

Automatic Allocation means 'I the server give you the host requesting an IP, an address from a pool, and will keep that IP address available to you (your MAC address) after your lease expires so that next time you request an IP you will be given the same address as last time.

I lack some flare for wiki posting or I would clean this mess up.

On the related note of contradictions and misinformation DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK is sent on layer 2 and not layer 3! In the example the DHCPOFFER with Dest IP is matching the flag 50 requested IP is misleading. The packet reaches the destination via layer 2 information, and the IP information at this point is not relevant. There is no IP routing taking place, you can put 1.1.1.1 in there if you felt like. The DHCP server and the host can talk to each other because of MAC addresses, with a layer 2 Broadcast DHCPDISCOVER, and the MAC src address being provided for the DHCP server to reply. Before the DHCPACK the host has no official IP regardless of option 50, so you can't expect any sort of reply from that host on that IP address yet, it is only getting offered an IP address inside the packet's YIADDR field, which in this example is being displayed in hex (confusing people again). [This unsigned comment was added on 7 March 2008 from IP 65.110.1.7]

I've changed "manual" to "static" in the "IP address allocation" section, and added a note about the many & varied terms used for this feature. NCdave (talk) 12:30, 7 June 2008 (UTC)


Applicability section confused

The following sentence is hopelessly confusing: "For devices such as routers and firewalls, that should not use DHCP, it can be useful to put Trivial File Transfer Protocol (TFTP) or SSH servers on the same machine that runs DHCP, which also serves to centralize administration."

At a minimum, it should be changed to: "To more easily configure devices that should not use DHCP, such as routers and firewalls, it can be useful to put Trivial File Transfer Protocol (TFTP) or SSH servers on the same machine that runs DHCP." This at least is clear, but it doesn't explain why DCHP should not be used on routers and firewalls and doesn't properly explain why putting TFTP on a DHCP machine will help with firewall configuration. Not sure what the original author had in mind, so can't really fix this without more input.

Ross Fraser (talk) 22:35, 28 July 2008 (UTC)

Should this be included at all? Noting why DHCP is not normally used on those devices would be relevant, but the other information is somewhat speculative and off-topic (albeit related).

Erratio (talk) 12:53, 14 October 2008 (UTC)

DHCP and IPv6

DHCP for IPv6 has two modes, stateful and stateless. This should be added to the article. Some information is available on http://www.cisco.com/en/US/products/ps6553/products_white_paper09186a00801e199d.shtml. ZorroIII (talk) 19:29, 19 September 2008 (UTC)

It is incorrect to say that RFC 3315 defines 'extensions' for DHCP for IPv6. DHCPv6 is a completely separate protocol, learning from DHCPv4, but not duplicating it. 67.161.51.194 (talk) 00:23, 24 April 2009 (UTC)

unicast/broadcast DHCPREQUEST

One of the conflicting pieces of information in the article is the description of the DHCPREQUEST within the ACK which is described as unicast although this flies in the face of the diagram above, and also the concept in the REQUEST section itself which indicates alerting all other DHCP servers. I'm guessing it's just an unfortunate choice of verbiage where "unicast" should be something more like "addressed". I'm not correcting it myself since I'm not sure, but I'll be poking around the RFC's as time allows and will come back to it if it hasn't been adjusted or my claim dismissed. —Preceding unsigned comment added by Erratio (talk • contribs) 12:46, 14 October 2008 (UTC)

DHCPNAK

The article doesn't mention the DHCPNAK, which is quite important I suppose. And is it 100% sure that the client recives it's IP address with DHCPOFFER ? According to this website it is recived with DHCPACK: http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm —Preceding unsigned comment added by 88.3.143.190 (talk) 13:07, 14 December 2008 (UTC)

You're right that it doesn't mention NAK; it should probably be included. Regarding your second question, each DHCPOFFER offers (hence the name) an IP address for the client. The client then picks (there may only be one offer) and reports its choice via a DHCPREQUEST. Finally, the server grants the request in the DHCPACK. So if everything goes "right" the client IP address is in both the DHCPOFFER and DHCPACK. However, it is not safe to start using it until the DHCPACK comes. I think the article makes this clear. It says, "At this point [after DHCPACK], the IP configuration process is complete." Superm401 - Talk 01:22, 31 January 2009 (UTC)

Option 6, DNS Server

I added a option 6 giving three DNS servers to the example. I think this is a fairly common use of DHCP in real practice. If I made a mistake, let me know and I'll correct it. Superm401 - Talk 01:22, 31 January 2009 (UTC)

Use of Transaction ID

I'm not pretty sure about the info. about the "Transaction ID" field " that the article gives. I thought it was used by the clients to distinguish which DHCP Server messages should they listen to. —Preceding unsigned comment added by 84.121.177.239 (talk) 23:11, 21 April 2009 (UTC)

I WANT LEARN MORE ABOUT DHCP.IT MEANS DYNAMIC HOST CONFIGURATION PROTOCAL.I THINK IT PROVIDES ONLY IP ADDRESS . IT USED THE HOST THAT IS REQUESTING FOR IP ADRESS OF THAT NETWORK. 

        IT IS DIVIDED IN TO CLASS.

  CLASS A -0-127
  CLASS B -128-191
  CLASS C -192-223
  CLASS D -224-239
  CLASS E -240-255
  CLASS A,B,C USE FOR PUBLIC IP
  CLASS D USE DEFANCE, SCIENSTIST OF NASA.
EVERY CLASS IN 4 GROUP.

  ACLASS

N H H H 

     255      255     255

255 IS MAXIMUM LIMIT OF HPOST


10.0.0.1- 255 10.0.0.2-255 10.0.0.3-255 .;;;;;;;;

10.0.0.254-255 10.0.1.0 10.0.2.0

10.0.254.0 AT LAST 255*255*255*PC WILL BE CONNECT WITH ONE NUMBER SO IT WILL BE HAPPENED 1----127OK AS LIKE BCLASS,C CLASS ALSO

GENERALY WE USE C CLASS HOST BECAUSE MAXIMUM WE USE 255- 1000 PC SO IT IS MORE FOR US. D CLASS IS USE FOR NASA SCIENSTIST. E CLASS IS NOT USED NOW IT IS STORE FOR FUTURE. —Preceding unsigned comment added by 122.163.149.251 (talk) 14:16, 9 July 2009 (UTC)

The DHCP renewal process is not very well documented

I would like to propose that the DHCP lease renewal process (timers etc) is better documented in this article. —Preceding unsigned comment added by Reinier.Kleipool (talk • contribs) 12:13, 25 November 2009 (UTC)

Merge proposal

I notice this article is lacking a History section. It could be implemented explaining the evolution from Bootstrap Protocol, merging that stub here. We get the main article right, then think about splitting again if needed. Thoughts? --M4gnum0n (talk) 11:26, 30 November 2009 (UTC)

well, why don't you write some new prose specific to DHCP. Merging is not acceptable, BOOTP is a separate protocol, each stand on their own. Kbrose (talk) 15:41, 30 November 2009 (UTC)
Technically, DHCP is a superset of BOOTP. The proposed DHCP history section would say, "We had BOOTP and we wanted it to do more so we added additional information to the end of the BOOTP packet". In this context, I support the merge. --Kvng (talk) 16:33, 30 November 2009 (UTC)

Updates to Introduction and History

I just updated the intro, since it said some things that weren't true. My update tries to address some of the criticisms raised above, but I don't know if I succeeded. Comments and criticisms are solicited. Sorry for the lack of an edit summary--I didn't notice that input field until it was too late. Abhayakara (talk) 04:25, 12 July 2010 (UTC)

Stateless address autoconfiguration

Trying to figure out IP version neutral terminology for this sort of last-resort automatic address assignment. Stateless address autoconfiguration is suggest by the article but points to an IPv6-only topic. Link-local address discusses both IPv4 and IPv6. Perhaps inclusion of IPv6 there is an error. I'm not an IPv6 expert but it appears that IPv6 automatic addresses are different because they can be used for communication beyond the subnet. Primary sources for this are RFC 3927 for IPv4 and RFC 4862 for IPv6. --Kvng (talk) 13:58, 30 July 2010 (UTC)

In IPv4, you have two competing protocols: Zeroconf, and Bonjour (formerly Rendezvous). Stateless configuration is common to both, but you can be doing Zeroconf or Bonjour with a regular IP address as well--not only with stateless. So you can't say "zeroconf" or "bonjour" to mean stateless. I think stateless address autoconfiguration is actually a pretty good term to use for IPv4, because it simply says what you are doing. But you're right that it's confusing in the sense that the term is not normally used that way. Abhayakara (talk) 16:03, 2 August 2010 (UTC)
I agree, Bonjour (software) has nothing to do with this. Automatic IP assignement is just one component of Zeroconf. --Kvng (talk) 16:40, 2 August 2010 (UTC)

Review of RFC 4862 indicates that Stateless address autoconfiguration includes separate means for generating Link-local addresses and Global addresses. RFC 3927 only mentions stateless address autoconfiguration in reference to IPv6. Since it is not otherwise used in RFC 3927, Stateless address autoconfiguration is not an appropriate term to apply to IPv4 networks. On the other hand, Link-local address appears in both RFCs and does apply to both IPv4 and IPv6. --Kvng (talk) 16:40, 2 August 2010 (UTC)

You can't infer by omission in an RFC that the term doesn't apply. IPv6 RFCs don't specifically define the term either, nor is it a proper noun anywhere. RFCs are often quite vague when it comes to usage of language. Even technical descriptions are often misinterpreted by others no less competent than the authors. The IPv6 RFC somehow even appears to mix global routing prefix assignment into 'stateless' autoconfiguration, although you need another server to send the prefix announcements, and then it all depends on whether you consider that stateless or not. The existence and proper functioning of another server would perhaps by many be considered stateful. After all, IPv4 autoconfiguration appears more stateless than IPv6. So unless someone in the IETF community specifically states that stateless address autoconfiguration is a term solely defined in IPv6 we should interpret it as a common noun that describes a general stateless method of configuration of addresses. What we can say though is that the concept surely had its origin in the IPv6 development, correcting many shortcomings of IPv4. I don't think I had even heard of autoconfiguration in IPv4 until after IPv6 was already underway, nor was there much of a perceived need for that as home networks were almost none-existent and everything else was managed by corporate network managers. The first reservation of the IPv4 address block was in RFC 3330, I believe, that was in 2002. It was mentioned there for the purpose of address autoconfiguration. Kbrose (talk) 18:19, 2 August 2010 (UTC)

IPv4 saac is link-local. So it's actually quite similar to IPv6 stateless link-local autoconfiguration, although the mechanism for allocating the address is quite different (ipv6 link-local autoconfiguration starts with the device's MAC address, converts it into an EUI64 address, and puts that in the bottom 64 bits of the address. Only if some other device answers a neighbor discovery request for the address does the node have to come up with a new address. In IPv4 link-local, there are only 16 bits of address available for autoconfiguration, so the device needs to use some kind of random-number generator to come up with an address to use.
"Stateless" refers specifically to state about a device that is not on the device. Stateless global IPv6 autoconfiguration is stateless in the sense that the only state about the autoconfiguration is on the device that has autoconfigured. It is not stateless in the sense that there is no state on that device, and it is also not stateless in the sense that there is no dependency on the external state of the network.
This meaning of "stateless" is common to a lot of protocols--e.g., NFS, where there is clearly state on the server--the contents of the file. But the server doesn't keep track of which clients have what data, so for instance if one client modifies the contents of a block in a file, and another client has that block cached, the change will not immediately be reflected to the second client. Fortunately, stateless address allocation is a lot less conflict-prone than NFS... :') Abhayakara (talk) 19:56, 2 August 2010 (UTC)
I started this discussion because it was not clear to me from reading the phrase in context what Stateless address autoconfiguration exactly means. It is defined to any degree is in by RFC 4862 as two separate methods for assigning IPv6 addresses in the absence of a DHCPv6 server. We're either going to go with that definition or we're going to interpret it as a common noun which also describes what goes on in IPv4. In that case we need to lay down a few more words in this article or in Link-local address (target for Stateless address autoconfiguration redirect) explaining what it means. Abhayakara has some suggestions above. I personally think it is a bulky and non-self-explanatory phrase. If we're going the common noun route, I prefer Auto-IP. But I have to say that deviation from the RFC 4862 "definition" of Stateless address autoconfiguration does feel like a potential WP:ORIGINAL issue. --Kvng (talk) 20:27, 2 August 2010 (UTC)
I can sympathize with that position, but it's important to remember that english is a language, not just an agglomeration of jargon. You are objecting to the use of stateless address autoconfiguration because it's jargon that means something specific in IPv6. But the words also mean something independent of their meaning as jargon, and what they mean is what we are trying to convey here. But I also agree with you that we shouldn't be coining new jargon in a wikipedia article, and I agree that we are riding the ragged edge of doing just that. That's why I pulled in the APIPA stuff in my latest edit. What I'm trying to do in this paragraph is describe the alternatives to DHCP, and to exclude APIPA as a potential alternative for DHCP. Maybe some text like "although APIPA performs a function similar to IPv6 stateless address autoconfiguration, it only works for communications on the local link, and thus is not an alternative to DHCP." Abhayakara (talk) 20:57, 2 August 2010 (UTC)

I put back the sentence User:Kbrose took out of the introduction that talked about saac vs. DHCP, because I think it's relevant to talk about other protocols that perform related tasks in the intro, but I am not particularly in love with the resulting paragraph, and would love to see it tightened up if someone has ideas for how to do it. Abhayakara (talk) 20:15, 2 August 2010 (UTC)

User:Kbrose, sorry for reverting your edit, but the resulting text was way too verbose, and basically said the same thing that the text said prior to your edit. It's okay for the intro to say what the article says. It's true that the article doesn't justify the position stated in the intro yet, but the way to fix this is to fix the article, not to fix the intro. The article as it stands needs a _lot_ of work--it's not very accurate, doesn't talk about DHCPv6 at all, and has a lot of stuff in it that's basically copied out of the DHCP Handbook. As one of the co-authors, I don't particularly mind, but in an encyclopedia-length article I don't think that's the right way to approach the subject. Abhayakara (talk) 21:26, 2 August 2010 (UTC)

Unfortunately the way it stands now is factually incorrect and gives the impression that there is some opportunity to use either DHCP *OR* stateless address autoconfiguration, when in fact the latter is mandatory in IPv6 and essential for proper operation of IPv6 internally. You state that only APIPA (which is really a MS-ism) is useful only on the link, when in fact IPv6 link-local addresses are no different. Further the acronym SLAAC is virtually nowhere used in the literature, and we shouldn't create new acronyms, particularly in a summary. My formulate was not verbose and avoided the ambiguities by staying more focused on the DHCP protocol, the subject of the article. Kbrose (talk) 21:46, 2 August 2010 (UTC)
Considering the comments, I've taken my own stab at this. New new acronyms. Used existing articles as hand holds. DHCP specific with limitations mentioned. Let me know what you think. --Kvng (talk) 22:06, 2 August 2010 (UTC)

One or more portions of this article duplicated other source(s). The material was copied from: http://www.tcpipguide.com/free/t_DHCPSecurityIssues.htm. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. VernoWhitney (talk) 14:05, 1 September 2010 (UTC)

The copyrighted material was largely inaccurate and/or irrelevant anyway, as was the material that remained after your edit, so I just rewrote the whole section using RFC2131, 3118 and 3046 as a source. I will need to add some additional citations, as noted in the article--I will try to get to these later on today. Please let me know if you feel I removed any text that you think actually is relevant. Abhayakara (talk) 16:21, 1 September 2010 (UTC)
Your rewrite looks good. I didn't take the time to review the section for anything other than the copyright issue, so thanks for cleaning up after me! VernoWhitney (talk) 22:12, 10 September 2010 (UTC)

Terminology: unicast as a verb, unused versus disused.

This in response to User:Kbrose' recent edit. There were two main changes

  • Use of disused versus unused. There is actually a distinction here. A disused address is an address that was in use, but is no longer. That is, it has fallen into disuse. An unused address is an address that was never used. So please don't change disused to unused—you are changing the meaning of the text, not correcting an accidental misuse of a term.
  • Use of unicast. The edit tries to get rid of the use of unicast as a verb, claiming that unicast is a form of addressing. The new phrasing is awkward and wordy, and does not represent typical use in network standards, nor is it necessary for clarity. Cast is a verb. Broadcast is a verb. Multicast is a verb. If you look at the wiki article on unicast, you'll see the term "multicasting" used. Multicasting is a gerund: a noun made from a verb. Hence multicast is a verb, and hence unicast is also a verb. So please don't change this again. Abhayakara (talk) 05:36, 15 September 2010 (UTC)
Abhayakara is a bit brusque with his comments, but overall I agree with his reasoning. I agree with his description of the difference between 'disused' and 'unused'. Disused sounds like UK English to me, but being from Canada—straddling the line between UK and US English—sometimes I get confused about which words are regional.
As for unicast as a verb, I have certainly read unicast being used as a verb amongst network engineers; on NANOG mailing lists, for example. While at first this seems an informal, slangy style, it's possible that going to far the other way is of no value; I mean that adding words may not really add clarity, it may in fact just be a more roundabout way of saying something directly. So I come down on the side of Abhayakara, but I can understand why Kbrose made the edits he did. Cheers —fudoreaper (talk) 06:28, 15 September 2010 (UTC)
Urk, you're right. I was a bit brusque. Sorry about that. Abhayakara (talk) 14:36, 15 September 2010 (UTC)
On the first point I would suggest smoothing this over by using the full familiar phrase "fallen into disuse". "Disused" is more clever than necessary here.
On the second point, while you make a good argument for the language police, I believe there are readers who will not be familiar with "unicast" and even less familiar with its use as a verb. The safe route is to use it as a noun. Perhaps Kbrose's language was clumsy. There are other ways to fix this besides using the verb. Have a look at how it is handeled in on of the unicast references [1] for an example. --Kvng (talk) 14:51, 15 September 2010 (UTC)
"Disused" isn't clever. It's a term of art. And it's in the dictionary, so if someone is confused about what it means, there's an easy cure. Likewise with unicast, we have a wiki page that describes what unicast means, and now the first use of the term links to that page. So if someone is confused, their confusion can easily be resolved. More to the point, though, seeing the word used in the context in which it is used, is there some alternative meaning they might take from the text because of the use of the term? It seems to me that you either know what unicast means, in which case the meaning of the sentence will be obvious, or else you don't know what unicast means. In that case, regardless of whether it is used as a verb or a noun or an adjective, you're going to have to either make an intuitive leap from "broadcast" to "multicast," or else you're going to have to look it up. So changing the wording doesn't help. Brevity is the soul of wit—why add words when they don't help anyone? Abhayakara (talk) 15:21, 15 September 2010 (UTC)
Er, I meant "unicast," not "multicast" in the sentence about intuitive leaps... Abhayakara (talk) 15:24, 15 September 2010 (UTC)
My comments were geared towards improving the accessibility of the article. Neither of you are wrong here. The best solution is to take the good ideas from each of you and make something even better. That's also the best way to achieve consensus. --Kvng (talk) 16:01, 15 September 2010 (UTC)
A wise sentiment. However, the way you've put it leaves me wondering if you think your change is necessary, or are just trying to come up with a compromise in order to avoid a change war. If you don't have a strong opinion one way or the other on how this should be resolved, then let's let User:Kbrose speak for him- or herself. Kbrose has a pretty good reputation, so I think it's premature to be concerned about this devolving. Since the gist of my "good idea" is to be brief rather than verbose, a compromise that makes the text even more verbose is not really a compromise from my perspective. If you really think your change is the right one, then we should certainly discuss about that, though—please don't take this as an attempt to suppress your proposal. Abhayakara (talk) 16:15, 15 September 2010 (UTC)

Security contribution

The following was contributed by 171.70.223.109 (talk · contribs) but removed by Kbrose (talk · contribs) (out of context, non-encyclopedic, not from secondary sources). Needs work and review but maybe someone will be up to it someday. --Kvng (talk) 14:09, 22 September 2010 (UTC)

S.Majumdar, D.Kulkarni and C.Ravishankar proposes a new method to traceback the origin of DHCP packets in ICDCN 2011. Their method adds a new DHCP option that contains the mac-address and the ingress port of the edge switch which had received the DHCP packet. This new option will be added to the DHCP packet by the edge switch. This solution follows DHCP-RFCs. Previous IP-Traceback mechanisms have overloaded IP header fields with traceback information and thus are violating IP RFCs. Like other mechanisms, this paper also assumes that the network is trusted. The paper presents various performance issues in routers/switches that were considered while designing this practical approach. However, this approach is not applicable to any general IP packet.[1]

contradiction: DHCPREQUEST is broadcasted / unicasted

Harry van Dijk (talk) 18:32, 2 January 2011 (UTC)Harry van Dijk The section 'Options' contains the phrase "If the DHCP server is unreachable for an extended period of time,[specify] the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it." This is a contradiction with the statement above which states that the DHCPREQUEST is broadcasted. Correction: sorry, I didn't read well the part above the phrase I quotes. My remark can be removed from this discussion. This article is excellent as it is.

Security section - citations not needed

This is in response to the "citations needed" tags in the Security section.

I would like to remove the "citations needed" tags. The statements are self-explanatory and stand on their own. No additional information is needed to prove or substantiate the facts stated.

for example: "Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can be operated on networks, providing incorrect information to DHCP clients. This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity"

- no additional information is required to understand or substantiate this. The unauthorized DHCP server would provide incorrect information, preventing the client from gaining access to network connectivity, exactly as stated.

The same goes for the other two "citation needed" tags. No additional information is required to understand or substantiate the statements. It is all contained in the sentences.

I rather suspect the same person who added those tags added the "too technical to understand" tag. I suggest it is that individual's reading / reasoning capabilities, and not the article that has a shortcoming

Does anyone disagree with removing the "citation needed" and "too technical" tags?

Cheers

Eric Ericcoll (talk) 16:36, 15 June 2011 (UTC)

Actually, I put in those "citation needed" tags when I rewrote that section; the reason I put them there was that I intended to go back and add citations, but was trying to flesh out the article first. Then circumstances intervened, and I haven't gotten around to finishing the work yet. If you feel strongly that they should go away, I won't object. But in fact Wikipedia isn't supposed to say new things—it's supposed to collect relevant citations and use them as a basis for writing encyclopedic articles. So I would argue that in fact citations are needed here, whether you think what is said is self-evident or not. If you really think it would be self-evident to a reader who is not already familiar with these issues, then the citations aren't needed. I don't think the article is too technical, but it really needs some serious rewriting—it's kind of rambling at the moment. Abhayakara (talk) 19:06, 15 June 2011 (UTC)

DHCP Options

It'd be nice to have the non-vendor specific DHCP Options specified in rfc2132. As always a wiki page is much easier to read than IETF's RFCs — Preceding unsigned comment added by Aguirrem (talk • contribs) 19:41, 24 October 2011 (UTC)

DHCP Options added

I've just added tables listing the available options in DHCP, grouped into tables as listed on RFC2132. If anyone wants to clean it up a bit or add details to some of the options, go right ahead - I might add some more myself later, but out of time at the moment. Hope this helps! Frosty the Snownoob (talk) 09:37, 10 June 2012 (UTC)

General changes

Regarding the notification that this article needs improvement: can someone please indicate what changes are required and the relevant issues be identified? It would be constructive in that the necessary changes could then be made. Polymath uk (talk) 20:44, 5 September 2011 (UTC)

No mention at all of the flags field (which just contains the broadcast flag). All the packet examples assume the broadcast flag is set, although in every case it isn't. DHCPREQUEST description states it is sent unicast to the server, the packet example shows it being sent broadcast. Adsbenham (talk) 09:57, 6 July 2012 (UTC)

What is the purpose of this article?

It's been bothering me for a while that this article has so much low-level protocol detail and feels like it doesn't have enough high-level exposition. The large, blocky diagrams of DHCP packets and the image from a Windows DHCP UI seem out of place. I don't want to criticize people for good work they're trying to do, but I do feel that the addition of DHCP options in the form they have been added is moving in the wrong direction. Many of the options documented in RFC2132 are never used—they were added because the authors were asked to provide options for configuring every parameter in the IP stack, but in general other automatic mechanisms for configuring these values were used, and so these options are never used in practice.

So I'd like editors of this article to contemplate this question. Is the article intended to inform people who don't know what DHCP is as to what it is? Give people a general understanding of how it works? Provide examples of scenarios where it's used? Document the protocol in enough detail that a reader could get a good start on an implementation? Fully document the protocol? Who is the intended audience?

I think for this to be encyclopedic, it ought to be the case that the reader can read three or four paragraphs and come away with a pretty good understanding of what DHCP is. I really question the point of a detailed exposition about the low-level encoding of the protocol. Abhayakara (talk) 16:57, 14 June 2012 (UTC)

Hi, as a non-expert user who was puzzled by the second half of the article, the section headed 'Technical Overview' met my needs. I wanted to know how DHCP works and why I keep getting given the same (conflicting) IP by my router. Now I understand what is probably happening. This section met my requirement which was exactly as you say, to "read three or four paragraphs and come away with a pretty good understanding of what DHCP is". Job done. 62.49.196.35 (talk) —Preceding undated comment added 23:44, 3 July 2012 (UTC)

Recent updates to introduction

I edited the introduction because the previous version seemed lacking. Someone editing anonymously made further changes to the introduction to clarify that DHCP can be used to configure devices even on isolated networks. The edits were technically accurate, but by adding all this technical detail, you obscure the meaning of the introduction, making it harder for a layperson to grasp. The point of the introduction is not to give the reader a perfect grasp of every subtlety of the protocol, but to give him or her a general overall understanding. This article in general is much too technical for an encyclopedia audience; making the introduction more technical is not a step in the right direction.

In addition, it's worth noting that DHCP is not really necessary for isolated broadcast domains. IP autoconfiguration works perfectly well in such circumstances. In order for DHCP to be useful, it must be the case that there is some routing infrastructure. If there is some routing infrastructure, then what you have is an internet, not a local-area network. It is not the internet, but it most definitely is an internet. So the introduction isn't really so inaccurate after all. Abhayakara (talk) 03:31, 9 July 2012 (UTC)

Security section - confidentiality added

I've added a short discussion of confidentiality, which we may expand (or contract!) later Davecb (talk) 17:00, 12 December 2012 (UTC)

CONFUSING HERE PLEASE (ooyuks@yahoo.com)

Which statement is correct regarding the operation of DHCP?

  • A. A DHCP client uses a ping to detect address conflicts.
  • B. A DHCP server uses a gratuitous ARP to detect DHCP clients.
  • C. A DHCP client uses a gratuitous ARP to detect a DHCP server.
  • D. If an address conflict is detected, the address is removed from the pool and an administrator must resolve the conflict.
  • E. If an address conflict is detected, the address is removed from the pool for an amount of time configurable by the administrator.
  • F. If an address conflict is detected, the address is removed from the pool and will not be reused until the server is rebooted. — Preceding unsigned comment added by 41.203.67.50 (talk) 22:21, 26 November 2012 (UTC)
It's unclear if this question was asked in the spirit of improving wikipedia. I'm not sure any of these suggestions happen on a regular basis, but really, most of the answers would be specific to the implementation of the protocol in software. —fudoreaper (talk) 14:44, 4 January 2013 (UTC)
Agreed, I'm pretty sure this is just someone asking for help for quiz/test/exam questions. Frosty the Snownoob (talk) 15:46, 7 January 2013 (UTC)

ummm... wtf

about the confidentiality section: "In an ISP context, dhcp logs of address assignments either contain or are links to personally identifying confidential information, the contact details of the client."

What is this even trying to say? Obviously DHCP request (like any other bit of data sent from a customer through his ISP) can be correlated to the customer. Perhaps this quote means that the DHCP packets have identifying information such as hostname/OS in them?

"These are attractive to spammers, and may be sought for "fishing expeditions" by police agencies or litigators."

What is attractive to spammers? What is a fishing expedition?

"At least one implementation[citation needed] mimics the Canadian Library Association policy for book circulation and does not retain identifying information once the "loan" has ended.""

WTF is a loan? A DHCP lease? Or a loan of a book from a library?

Using small talk, vagueness, and tounge in cheek, in an article about a protocol nobody fully understands doesn't help anyone understand it more...

The previous unsigned edits were made by 207.35.173.122

FWIW, I think these observations make sense, and the editor who made them ought to be bold. — Preceding unsigned comment added by Abhayakara (talk • contribs) 03:52, 21 January 2013 (UTC)

I think the quote is quite clear in its meaning, that the ISP's DHCP logs would naturally contain a record of the identifier linked to the device the address was linked to, which would be able to be linked back to the customer, but I do agree that the section seems mostly pointless - the first sentence is an okay start but the rest seems to be completely useless.

In addition, does anyone know what this 'one implementation' that deletes the logs once the lease finishes is?

Frosty the Snownoob (talk) 04:06, 23 January 2013 (UTC)

Confusing DHCP generally with the operation of home gateways specifically

User:ImperfectlyInformed recently made some edits that add information about DHCP as it relates to home gateways. These edits are interesting, but are offtopic. It would be helpful to discuss the goal of these edits here, so that we can figure out a way to address the need User:ImperfectlyInformed was trying to address, but without making the article more confusing than it already is (which is to say, considerably). Abhayakara (talk) 03:54, 21 January 2013 (UTC)

People are going to come to this topic when they are working on their router and see "turn DHCP on". Typically there's not much else about it. If we want readers to understand the topic (which we do), we have to provide context - and there is plenty of context which they will be very familiar with, if it is introduced in non-technical jargon. So we can say that the router acts as a DHCP server and the clients are PCs, and similarly the ISP acts as a DHCP server. These are quite correct and serve to demonstrate the real-world significance of the protocol. Adding a little more: home gateways are clearly not "offtopic". DHCP is a significant part of home networks. Prior to my edits, this article basically did not provide the real-world context and actual effect of DHCP at all. II | (t - c) 04:18, 21 January 2013 (UTC)
I agree that the new edits that describe the use of DHCP in a home networking environment confuse the issue. The content is good, but misplaced. It should not be at the very beginning of the article, but in its own subsection entitled something like "Typical Deployment Scenarios - Home Routing." So, in my opinion, move the content from "In a typical..." through "port forwarding may be used" to that subsection, and let the main introductory section focus on what the protocol is, not what one particular use of it is. — Preceding unsigned comment added by 68.83.217.182 (talk) 10:38, 5 February 2013 (UTC)

I'm thinking the provision of DHCP in home networks should be discussed in a larger context--to wit: what are the options for providing DHCP service in various network configurations. That should be addressed in its own section, which should include a link to the Residential gateway article, which should in turn provide more information about how they assign IP addresses. In any event, this information does not belong in the very first paragraph of this article. Joeldbenson (talk) 05:17, 16 April 2013 (UTC)

If you have a better idea of a real-world example, I'm all ears. However, I will not accept removing any real-world examples from the lead. This article has a long history of being too technical and abstract (to the point of unintelligibility) rather than not technical enough. This is not a technical manual. I realize it is a page which system admins mostly look at, but that doesn't mean it should not be written for a general audience. II | (t - c) 15:47, 16 April 2013 (UTC)
So your answer to Abhayakara's original complaint is that your goal was to lighten up the article for non-technical readers? I certainly agree that is needed, and thinking about it that way an example would probably help. So we just need to make sure it's viewed as an example rather than a confusion of the article's main purpose. Your taking it out of the very first paragraph was at least a step in that direction, possibly all that was needed.
None-the-less, I am still thinking it wouldn't hurt to discuss the provision of DHCP services in networks of varying sizes, and to reference (and provide more DHCP info in) the Residential gateways article for the sake of your hypothetical user who comes to this article when working on his/her router and wants to know what DHCP is, etc.
In a larger sense, we really do need to address Abhayakara earlier question: #What is the purpose of this article? I also think it has way too much technical detail that actually obscures the information the article should provide (although I can't help but wonder if it's possible to be both too technical and too abstract ). I would hope that this and other networking protocol articles are not intended for and primarily read by system admins (or, worse yet, programmers coding DHCP software), because they should already know this stuff and in any event should not be trying to learn it from Wikipedia. I'm thinking our target audience should be home users, hobbyists and high school students who don't want or need to see packet payload diagrams. Let's just direct those more technical readers to more appropriate information sources such as the RFCs. Joeldbenson (talk) 02:44, 17 April 2013 (UTC)
Home networks are just one example of DHCP use, and this whole query seems to want a howto for home networking, which seems a bit WP:NOT#HOWTO, but may be OK to put in home networking. Widefox; talk 15:38, 10 July 2013 (UTC)

I'm all about technical understanding of DHCP. It is a fundamental part of the internet. However, I do not see the purpose of these diagrams written in hexadecimal relating to DORA. I've just never seen DORA explained in this way. Why give the tables here in hexadecimal when computers send out these broadcasts in binary and people interpret them in decimal? Thanks 76.126.184.117 (talk) 09:06, 22 August 2013 (UTC)

Microsoft even has a simple little table for DORA here. http://support.microsoft.com/kb/169289 Maybe there's a compelling reason why this hexadecimal junk should stay, but at the very least I think this should have some charts and illustrations of the process. Kind of spice DHCP up a little bit on here. ^.^ And of course, add to clarity! Rousseaua001 (talk) 09:19, 22 August 2013 (UTC)

Merge

Closing per a WP:ANRFC request.
The result of the discussion was no consensus. Armbrust The Homunculus 05:46, 10 July 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I'm proposing the merge because DHCP snooping is a DHCP-related feature akin to DHCP relaying and we don't have a separate article for DHCP relaying. Spoofing is an attack technique and so is not a feature of the protocol and so arguably deserves a separate article. ~KvnG 14:22, 10 July 2013 (UTC)

The security section looks like the target for this proposed merge. Much of the material is already here so I don't think we'd be increasing the size of the article substantially. When you discount the tables, the article is not actually that large. ~KvnG 23:51, 7 November 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What is the "CHADDR (Client hardware address)"?

Is that the same thing as the "MAC address"? I know in my router's settings, IP addresses are assigned based on MAC address. But the term "MAC address" isn't used in this article, but a term I've never heard before "client hardware address" is used. Are these two things the same? Or is this yet another address which is associated with your computer? Benhut1 (talk) 01:37, 17 April 2015 (UTC)

Hello! In contemporary (Ethernet) networks, that's almost always a MAC address. However, not all networks are Ethernet, let's just remember TokenRing, for example, in which physical addresses are still six bytes long but aren't called "MAC addreses". Thus, the RFC uses CHADDR as a more universal term. — Dsimic (talk | contribs) 01:45, 17 April 2015 (UTC)
There are other fields that are labelled but not defined. The XID field, for example. What is it for and how is its value determined? Likewise the SECS and FLAGS fields. Mention of what the magic cookie is for would be helpful too. 83.104.249.240 (talk) 20:43, 23 August 2015 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Dynamic Host Configuration Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:19, 26 July 2017 (UTC)

DHCP disabled?

In the first paragraph (Overview) the explanation for manual DHCP begins with: 

"The DHCP server is disabled and"

Which is clearly wrong and should be deleted.

Of course the DHCP-server is enabled. I assume the person who wrote this wanted to say, that the DHCP-server is not giving leases to clients which are not listed in the DHCP-configuration with a MAC-address and an according IP-address. — Preceding unsigned comment added by 212.149.48.42 (talk) 09:22, 11 August 2016 (UTC)

1234 Mahdiaziz (talk) 21:47, 29 December 2017 (UTC)

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)

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)

  1. ^ Majumdar, Saugat (2011). "DHCP Origin Traceback in Ethernet Switched Networks" (PDF). ICDCN. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:Dynamic_Host_Configuration_Protocol/Archive_1&oldid=1146521747"