Talk:Dynamic Host Configuration Protocol
From Wikipedia, the free encyclopedia
Hi How r u —Preceding unsigned comment added by 61.246.47.211 (talk) 05:38, 6 March 2008 (UTC)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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://en.wikipedia.org/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]
