The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Page 2
Dynamic Host Control Protocol (DHCP) provides a framework for passing configuration information dynamically to hosts on a TCP/IP network. A DHCP client is a host that uses DHCP to obtain configuration parameters such as an IP address.
A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP datagrams are switched between networks somewhat transparently. By contrast, relay agents receive DHCP messages and then generate a new DHCP message to send on another interface.
The figure below shows the basic steps that occur when a DHCP client requests an IP address from a DHCP server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a DHCP server. A relay agent forwards the packets between the DHCP client and server. A DHCP server offers configuration parameters (such as an IP address, a MAC address, a domain name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.
A DHCP client may receive offers from multiple DHCP servers and can accept any one of the offers; however, the client usually accepts the first offer it receives. Additionally, the offer from the DHCP server is not a guarantee that the IP address will be allocated to the client; however, the server usually reserves the address until the client has had a chance to formally request the address.
The client returns a formal request for the offered IP address to the DHCP server in a DHCPREQUEST broadcast message. The DHCP server confirms that the IP address has been allocated to the client by returning a DHCPACK unicast message to the client.
The formal request for the offered IP address (the DHCPREQUEST message) that is sent by the client is broadcast so that all other DHCP servers that received the DHCPDISCOVER broadcast message from the client can reclaim the IP addresses that they offered to the client.
If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP server are invalid (a misconfiguration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP server.
The DHCP server will send to the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, if an error has occurred during the negotiation of the parameters or the client has been slow in responding to the DHCPOFFER message (the DHCP server assigned the parameters to another client) of the DHCP server.
Page 3
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Page 4
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
A DHCP server is responsible for assigning IP addresses to clients. A DHCP client sends a packet to the server to apply for configurations such as the IP address, subnet mask, and default gateway. After receiving the request, the server replies with a packet that carries required configuration information according to policies. Both DHCP Request packets and Response packets are encapsulated through UDP. The DHCP client listens to packets through port 68; the DHCP server listens to packets through port 67.
Figure 3-1 shows DHCP packet exchange.
Figure 3-1 DHCP packet exchange
The DHCP client communicates with the DHCP server in any of three modes.
To obtain a valid dynamic IP address, the DHCP client communicates with the DHCP server in any of the following modes in different phases:
The DHCP client accesses the network for the first time.
When the DHCP client accesses the network for the first time, the DHCP client undergoes the following stages to set up a connection with the DHCP server:
Discover stage: The DHCP client searches for the DHCP server. The DHCP client broadcasts a DHCP Discover packet, and only DHCP servers reply the Discover packet.
Offer stage: The DHCP servers offer IP addresses to the DHCP client. After receiving the DHCP Discover packet from the client, DHCP servers select available IP addresses from their IP address pools, and then send DHCP Offer packets carrying the leased IP addresses and other settings to the DHCP client.
Select stage: The DHCP client selects an IP address. If multiple DHCP servers send DHCP Offer packets to the client, the DHCP client accepts only the DHCP Offer packet that arrives first, and then broadcasts a DHCP Request packet to all the DHCP servers. The Request packet contains the IP address that the client requires the selected DHCP server to offer.
Acknowledge stage: The DHCP server acknowledges IP address offering. After receiving the DHCP Request packet from the DHCP client, the selected DHCP server sends a DHCP ACK packet to the client. The DHCP ACK packet contains the offered IP address and other settings. Then, the DHCP client binds its TCP/IP protocol components to the network interface card (NIC).
IP addresses offered by the other DHCP servers are available for the other clients.
The DHCP client accesses the network for the second time.
When the DHCP client accesses the network for the second time, the DHCP client undergoes the following stages to set up a connection with the DHCP server:
If the DHCP client has correctly accessed the network, it just needs to broadcast a DHCP Request packet that carries the previously-assigned IP address when it accesses the network again. The DHCP client does not need to send a DHCP Discover packet.
After receiving the DHCP Request packet, the DHCP server sends a DHCP ACK packet, instructing the DHCP client to continue to use the original IP address if the IP address is not assigned to another DHCP client.
If the IP address cannot be assigned to the DHCP client (for example, it has been assigned to another client), the DHCP server responds with a DHCP NAK packet. After receiving the DHCP NAK packet, the DHCP client sends a DHCP Discover packet to apply for a new IP address.
The DHCP client extends the IP address lease.
Generally, there is a validity period (also called a lease) for the IP address dynamically assigned to the client. The DHCP server calls back the IP address after the lease expires. If the DHCP client intends to continue to use this IP address, it needs to extend the IP address lease.
In practice, the DHCP client sends a DHCP Request packet to the DHCP server automatically to update the IP address lease when the DHCP client starts or there is only half of the lease duration left. If lease renewal succeeds, the server replies with a DHCP ACK packet to inform the client of the new IP address lease. If lease renewal fails, the DHCP client resends a DHCP Request packet to the DHCP server when 7/8 of the IP address lease has expired.
During the master/slave switchover of the MPU, the lease status of DHCP users does not change.
Figure 3-2 DHCP packet format
The description of each of the fields in a DHCP packet is as follows:
op: indicates the message type. The value 1 indicates the Request packet and the value 2 indicates the Reply packet.
htype: indicates the hardware address type. The value 1 indicates the hardware address of the Ethernet.
hlen: indicates the hardware address length. In an Ethernet, the value of this field is 6.
hops: indicates the number of hops. On the client, the value of this field must be set to 0. It can be set on a relay agent optionally.
xid: indicates the transaction ID. The value is a random number chosen by the client and used by the client and the server to associate requests and responses. It is chosen by the client and returned by the server. The value is a 32-digit integer.
secs: indicates the seconds elapsed since the client starts applying for an IP address or extends the IP address lease. This field is filled by the client.
flags: indicates the flags. This field contains 16 bits and only the leftmost bit is useful. If the bit is 0, it indicates unicast; if the bit is 1, it indicates broadcast.
ciaddr: indicates the client IP address. This field is filled in only when the client is in the state of Bound, Renew, or Rebinding and can reply with an ARP Request.
yiaddr: indicates 'your' (client) IP address.
siaddr: indicates the IP address of the next server to be used in the next phase of DHCP.
giaddr: indicates the IP address of the DHCP relay agent.
chaddr: indicates the client hardware address. The client must set its hardware address. The Ethernet frame header in a UDP packet also contains this field. It is difficult or even impossible to obtain the value of this field by viewing a UDP packet. If this field is set in a UDP-bearing DHCP packet, the user process can easily obtain the value of this field.
sname: indicates the optional server host name. The value of this field is a null terminated string. This field is to be filled by the DHCP server.
file: indicates the boot file name. The value of this field is a null terminated string. In a DHCP Discover packet, this field is a "generic" name or null whereas in a DHCP Offer packet, this field is a fully qualified directory-path name.
options: indicates the optional parameters field, which is in the format of "code+length+data."
The DHCP client reports an address conflict.
After receiving a DHCP ACK packet from the DHCP server, the DHCP client checks the IP address allocated by the DHCP server through duplicate address detection (DAD). If the DHCP client finds an address conflict or that the allocated address is unusable for a certain reason, the DHCP client sends a DHCP DECLINE packet to the DHCP server informing that the allocated IP address is unusable.
The DHCP client releases the allocated IP address.
If the DHCP client no longer needs to use the assigned IP address, it sends a DHCP Release message to the DHCP server to request IP address release. In this case, the DHCP server releases the bound lease.
Static and dynamic allocation of IP addresses
Policies for IP address allocation
Different hosts may require different IP address leases. For a server, a fixed IP address is required for a long term; for some hosts, IP addresses that are dynamically assigned are needed for a long term; for some PCs, IP addresses are temporarily assigned on demand.
To meet the preceding requirements, the DHCP server provides the following IP address allocation policies:
Manual allocation: An administrator assigns fixed IP addresses to a few specific hosts, such as WWW servers.
Automatic allocation: The server assigns fixed IP addresses to some hosts who are connected to the network for the first time. These IP addresses can be used by the hosts for a long time.
Dynamic allocation: The server assigns IP addresses with leases to clients. The clients need to reapply for IP addresses when the leases expire. This address allocation policy is widely accepted by most clients.
Sequence of IP address allocation
A DHCP server selects IP addresses in the following sequence and allocates an available address to the client:
IP address that is in the database of the DHCP server and is statically bound to the MAC address of the client.
IP address assigned to the client before, that is, the IP address in the requested IP Addr option of the DHCP Discover packet sent by the client.
IP address first found when the server searches for available IP addresses in the DHCP address pool.
Pseudo DHCP server detection
If a private DHCP server exists on a network, clients cannot obtain correct IP addresses and therefore cannot go online because this private DHCP server interacts with the DHCP clients during address application. Such a private DHCP server is called a pseudo DHCP server. By running commands, you can detect pseudo DHCP servers.
IP address reservation
DHCP supports IP address reservation for clients. The IP addresses in or outside an address pool can be reserved. If an address in the address pool is reserved, the address is no longer assignable. Addresses are reserved for DNS servers.
User-defined options
The options field in a DHCP packet is used to carry control information and parameters that are not defined in certain protocols. If the DHCP server is configured with options, when a DHCP client applies for an IP address, the client can obtain the configuration information in the options field of the DHCP REPLY packet from the server. The value of a DHCP option ranges from 0 to 255. At present, the device supports explicit configuration of the common options of the DHCP server: Option 1 (Subnet Mask), Option 3 (router), Option 6 (DNS Server), Option 15 (Domain Name), Option 44 (NetBIOS name server), Option 46 (NetBIOS node type), Option 51 (Lease), Option 58 (Renewal Time), Option 59 (Rebinding Time), Option 121 (Classless Static Routes), Option 120 (SIP Server), and Option121 (Routing Information Option). In addition, the device supports user-defined options.
Option resolution
The DHCP server supports resolution of certain options carried in a packet sent from a DHCP client for client authentication and address allocation policies. At present, the options that the device can resolute include: Option 12 (Host Name), Option 50 (Requested IP Address), Option 53 (DHCP Message Type), Option 55 (Parameter Request List), Option 60 (Vendor class identifier), Option 61 (Client-identifier), and Option 82 (DHCP Relay Agent Information Option).
Where the options field applies varies with the functions of the options field. For example, Option 77 is used on a DHCP client to identify user types of the DHCP client. The DHCP server selects an address pool to allocate an IP address and other configuration parameters to the DHCP client based on the User Class in the options field. Option 77 is manually configured only on the DHCP client but not on the server.
IP address lease
The DHCP server can specify different leases for addresses in different address pools. The addresses in an address pool must be of the same lease.
Generally, there is a valid period for the IP address dynamically allocated to the client. The DHCP server calls back the IP address after the valid period expires. If the client intends to continue using this IP address, it needs to extend the IP address lease.
When obtaining an IP address, the DHCP client enters the binding state. The client has three timers to control lease update, rebinding, and lease expiration. When assigning an IP address to the client, the DHCP server can set the timers. If the DHCP server does not set the values for the timers, the client uses the default values. Table 3-1 lists the default values of the timers.
Table 3-1 Default values of timers
Timer
Default Value
Lease renewal timer
50% of the overall lease
Rebinding timer
87.5% of the overall lease
Lease expiration timer
Overall lease
When the lease renewal timer expires, the DHCP client must renew its IP address lease. The DHCP client automatically sends a DHCP Request packet to the DHCP server that assigns the currently-used IP address to the DHCP client. If the IP address is valid, the DHCP server replies with a DHCP ACK packet to inform the client of a new lease, and then the client re-enters the binding state. If the DHCP client receives a DHCP NAK packet from the server, it enters the initializing state.
After the DHCP client sends a DHCP Request packet for extending the lease, the client remains in the updating state and waits for a response. If the client does not receive a response from the server after the rebinding timer expires, the client considers that the original DHCP server is unavailable and starts to broadcast a DHCP Request packet.
Any DHCP server on the network can reply to this request with a DHCP ACK or DHCP NAK packet.
If receiving a DHCP ACK packet, the client returns to the binding state and re-sets the lease renewal timer and binding timer; if all the received packets are DHCP NAK packets, the client goes back to the initializing state. At this time, the client must stop using this IP address immediately, return to the initializing state, and request a new IP address.
If the client does not receive any response before the lease expiration timer expires, the client must stop using the current IP address immediately and return to the initializing state.
Hot backup
If the router has two MPUs, the system backs up the DHCP data on both MPUs in a real-time manner. When a master/slave switchover occurs, the DHCP server on the standby board still works normally.
DHCP relay agent
The early DHCP protocol applies to only the situation that the DHCP client and DHCP server are on the same network segment. Therefore, it is necessary but uneconomical to configure a DHCP server on each network segment. The DHCP relay function is therefore introduced to address this problem. Through a DHCP relay agent, a DHCP client can communicate with the DHCP server on another network segment and apply for a valid IP address. In this manner, DHCP clients on multiple network segments can share one DHCP server. This saves costs and facilitates centralized management. The DHCP relay agent forwards a DHCP broadcast packet to the DHCP server that is in another network segment and fills the giaddr field of the DHCP broadcast packet with the IP address of the relay interface to identify the network segment to which the allocated address belongs. Both the DHCP relay agent and the DHCP server listen to packets through port 67.
Page 2
- About This Document
- AAA and User Management (Access User)
- IPv4 Address Allocation and Management
- IPv6 Address Allocation and Management
- IPoE Access
- PPPoE Access
- 802.1X Access
- L2TP Access
- User Access Multi-Device Backup
- VXLAN Tunnel-based Access
- Appendix: RADIUS Attributes
- RADIUS Attribute Dictionary
- Attributes Carried in RADIUS Packets
- RADIUS Attribute Prohibition, Conversion, and Default Carrying Status
- Description of RADIUS Attributes
- RADIUS Attributes Defined by RFC
- Private RADIUS attribute defined by the Huawei RADIUS 1.1 protocol. The attribute number is 26, vendor ID is 2011, and sub-attribute ranges from 1 to 255. For details, see the following:
- Private RADIUS attribute defined by Microsoft. The attribute number is 26, vendor ID is 311, and sub-attribute ranges from 1 to 255. For details, see the following:
- RADIUS attribute defined by the DSL forum. The attribute number is 26, vendor ID is 3561, and sub-attribute number ranges from 1 to 255. For details, see the following:
- Private RADIUS attribute defined by Redback. The attribute number is 26, vendor ID is 2352, and sub-attribute ranges from 1 to 255. For details, see the following:
- Private RADIUS attribute defined by Ascend (the attribute may conflict with the standard RADIUS attribute). The attribute number is 26, Vendor ID is 3561, and sub-attribute number ranges from 1 to 255. For details, see the following:
- Private RADIUS attribute defined by the Huawei RADIUS 1.0 protocol (the attribute may conflict with the standard RADIUS attribute and is used only for interconnection with IPHotel). The attribute number is 26, vendor ID is 2011, and sub-attribute ranges from 1 to 255. For details, see the following:
- Private RADIUS Attributes Defined by China Mobile, Vendor ID 28357 (These Attributes May Conflict with Standard Attributes)
- RADIUS Server Selection
- Description for the Attributes of OWN Type
- Reasons for User Offline
- More Information About HW-Data-Filter (82)
- More Information About NAS-Port-Id (87)
- More Information About HW-Dhcp-Option (187)
- More Information About HW-Avpair (188)
- More Information About HW-DHCPv6-Option (189)
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
When two hosts whose addresses have the same prefix communicate with each other, they do not search routing tables. Instead, one of them sends a Neighbor Solicitation (NS) packet to obtain the link layer address corresponding to the destination address, and then uses the link layer address to encapsulate data packets.
In practice, hosts whose addresses have the same prefix may not belong to the same broadcast domain. In this case, the NS packet cannot be sent to the destination host. Therefore, the hosts cannot communicate with each other.
To make these hosts communicate with each other, you can enable ND proxy on the BRAS so that the BRAS rather than a host can reply with a Neighbor Advertise (NA) packet that carries the link layer address of the BRAS. With the help of the BRAS, two hosts whose addresses have the same prefix can communicate with each other.
Figure 4-1 Principle of ND proxy
This Document Applies to these Products