全部博文(930)
分类: LINUX
2008-10-27 17:06:51
尝试的翻译了点,实在头大.能懒就懒,这是我一贯的风格,没办法大多数就都还是copy的e文,当做是学英语喽^_^
DHCP的报文格式,如图1,
OP(1) |
Htype(1) |
Hlen(1) |
Hops(1) |
Transaction ID(4) |
|||
Seconds(2) |
Flags(2) |
||
Ciaddr(4) |
|||
Yiaddr(4) |
|||
Siaddr(4) |
|||
Giaddr(4) |
|||
Chaddr(16) |
|||
Sname(64) |
|||
File(128) |
|||
Options(variable) |
(图1 DHCP的 报文格式)
DHCP uses the same two assigned ports as : 67/udp for the , and 68/udp for the .
DHCP operations fall into four basic phases. These phases are IP discovery, IP lease offer, IP request, and IP lease acknowledgement.
After the client obtained an IP address, the client may start an to prevent IP conflicts caused by address pool overlapping of DHCP servers.
The client broadcasts on the physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
When the DHCP server receives the DHCPREQUEST message from the client, which is basically a unicast packet unlike the DHCPDISCOVER packet as the client now knows who the server is. This initiates the final phase of the configuration process. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
|
|
|
|
The client to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use DHCP Inform to obtain web proxy settings via . Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
client's network address client's network
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'options' options options (unused)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
INIT-REBOOT,
BOUND, RENEWING
or REBINDING)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MAY MAY MUST NOT
Use of broadcast and unicast想想应该也就是这么个道理吧.你在有ip的情况下server发包,server就应该unicast了吧.
The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server. The
client unicasts DHCPRELEASE messages to the server. Because the
client is declining the use of the IP address supplied by the server,
the client broadcasts DHCPDECLINE messages.
When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
The client may also use unicast to send DHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP
messages sent to the IP address of a known DHCP server, the DHCP
client reverts to using the IP broadcast address.