Which destination IP address is used when an IPv6 host sends a DHCPv6 solicit message to locate a DHCPv6 servers and relay agents?

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).

Similar to DHCP for IPv4, DHCPv6 clients and DHCPv6 servers exchange DHCPv6 messages using the User Datagram Protocol (UDP). DHCPv6 clients only process DHCPv6 messages with UDP port number 546. DHCPv6 servers and relay agents only process DHCPv6 messages with UDP port number 547.

Format of messages exchanged between DHCPv6 clients and DHCPv6 servers

Figure 8-2 shows the format of messages exchanged between DHCPv6 clients and DHCPv6 servers.

Figure 8-2 Format of messages exchanged between DHCPv6 clients and DHCPv6 servers

Table 8-1 Fields of messages exchanged between DHCPv6 clients and DHCPv6 servers

Field

Length

Description

msg-type

1 byte

Indicates the packet type. The value ranges from 1 to 11. For details, see the DHCPv6 Packet Type.

transaction-ID

3 bytes

Identifies packet transaction between DHCPv6 clients and servers. For example, a DHCPv6 client initiates a Solicit/Advertise transaction or a Request/Reply transaction. Their transaction IDs are different. Transaction IDs have the following characteristics:

The transaction ID is randomly generated by a DHCPv6 client.
Transaction IDs of request and reply packets must be the same.
The transaction ID of a packet initiated by a DHCPv6 server is 0.

Options

Variable

Indicates the option field in a DHCPv6 packet. The option field contains configurations that the DHCPv6 server assigns to IPv6 hosts, such as the IPv6 address of the DNS server.

For details, see Options Field in a DHCPv6 Message.

Format of messages exchanged between DHCPv6 relay agents and DHCPv6 servers

Figure 8-3 shows format of messages exchanged between DHCPv6 relay agents and DHCPv6 servers.

Figure 8-3 Format of messages exchanged between DHCPv6 relay agents and DHCPv6 servers

Table 8-2 Fields of messages exchanged between DHCPv6 relay agents and DHCPv6 servers

Field	Length	Description
msg-type	1 byte	Indicates the message type. The value ranges from 12 (RELAY-FORW) to 13 (RELAY-REPL). For details, see DHCPv6 Message Type.
hop-count	1 byte	Indicates the number of DHCPv6 relay agents that a DHCPv6 message has passed through.
link-address	16 bytes	Indicates an IPv6 global unicast or link-local address that will be used by a server to identify the link to which a client is connected.
peer-address	16 bytes	Indicates the IPv6 address of a client or relay agent from which the message to be relayed was received.
options	Variable	Indicates the Options field in a DHCPv6 message. The Relay Message option must be included. For details, see Options Field in a DHCPv6 Message.

DHCPv6 defines 13 types of packets. A DHCPv6 server and a DHCPv6 client communicate by exchanging these types of packets. Table 8-3 lists DHCPv6 packets and their corresponding DHCPv4 packets and describes the DHCPv6 packets.

Table 8-3 Comparisons between DHCPv6 packets and DHCPv4 packets

DHCP Packet Type	DHCPv6 Packet	DHCPv4 Message	Description
1	SOLICIT	DHCP DISCOVER	A DHCPv6 client sends a Solicit packet to locate DHCPv6 servers.
2	ADVERTISE	DHCP OFFER	A DHCPv6 server sends an Advertise packet in response to a Solicit packet to declare that it can provide DHCPv6 services.
3	REQUEST	DHCP REQUEST	A DHCPv6 client sends a Request packet to request IPv6 addresses and other configuration parameters from a DHCPv6 server.
4	CONFIRM	-	A DHCPv6 client sends a Confirm packet to any available DHCPv6 server to check whether the obtained IPv6 address applies to the link that the DHCPv6 client is connected to.
5	RENEW	DHCP REQUEST	A DHCPv6 client sends a Renew packet to the DHCPv6 server that provides the IPv6 addresses and other configuration parameters to extend the lifetime of the addresses and to update configuration parameters.
6	REBIND	DHCP REQUEST	A DHCPv6 client sends a Rebind packet to any available DHCPv6 server to extend the lifetime of the assigned IPv6 address and to update configuration parameters when the client does not receive a response to its Renew packet.
7	REPLY	DHCP ACK/NAK	A DHCPv6 server sends a Reply packet in the following situations: A DHCPv6 server sends a Reply packet containing IPv6 addresses and configuration parameters in response to a Solicit, Request, Renew or Rebind packet received from a DHCPv6 client. A DHCPv6 server sends a Reply packet containing configuration parameters in response to an Information-Request packet. A DHCPv6 server sends a Reply packet in response to a Confirm, Release, or Decline packet received from a DHCPv6 client.
8	RELEASE	DHCP RELEASE	A DHCPv6 client sends a Release packet to the DHCPv6 server that assigns IPv6 addresses to the DHCPv6 client, indicating that the DHCPv6 client will no longer use the obtained addresses.
9	DECLINE	DHCP DECLINE	A DHCPv6 client sends a Decline packet to a DHCPv6 server, indicating that the IPv6 addresses assigned by the DHCPv6 server are already in use on the link to which the DHCPv6 client is connected.
10	RECONFIGURE	-	A DHCPv6 server sends a Reconfigure packet to a DHCPv6 client, informing the DHCPv6 client that the DHCPv6 server has new addresses or updated configuration parameters.
11	INFORMATION-REQUEST	DHCP INFORM	A DHCPv6 client sends an Information-Request packet to a DHCPv6 server to request configuration parameters except for IPv6 addresses.
12	RELAY-FORW	-	A DHCPv6 relay agent sends a Relay-Forward packet to relay Request packets to DHCPv6 servers.
13	RELAY-REPLY	-	A DHCPv6 server sends a Relay-Reply packet to a DHCPv6 relay agent. The Relay-Reply packet carries a packet that the DHCPv6 relay agent needs to deliver to a DHCPv6 client.

This Document Applies to these Products

Page 2

The Options field in a DHCP message carries control information and parameters that are not defined in common protocols. When a DHCP client requests an IP address from a DHCP server configured with the Options field, the server replies a message containing the Options field. Figure 3-3 shows the format of the Options field.

Figure 3-3 Format of the Options field

The Options field consists of Type, Length, and Value. The following table provides the details.

Table 3-3 Description of the Options field

Field	Length	Description
Type	1 byte	Indicates the type of the message content.
Length	1 byte	Indicates the length of the message content.
Value	Variable	Indicates the message content. The length varies depending on the Length field.

The value of the Options field ranges from 1 to 255. Table 3-4 lists common DHCP options.

Table 3-4 Description of the Options field in DHCP messages

Options No.	Function
1	Specifies the subnet mask.
3	Specifies the gateway address.
6	Specifies the DNS server IP address.
12	Specifies the hostname of a DHCP client.
15	Specifies the domain name suffix.
33	Specifies a group of classful static routes. When a DHCP client receives DHCP packets with this option, it adds the classful static routes contained in the option to its routing table. In classful routes, masks of destination addresses are natural masks and masks cannot be used to divide subnets. If Option 121 exists, Option 33 is ignored.
44	Specifies the NetBIOS server name.
46	Specifies the NetBIOS object type.
50	Specifies the requested IP address.
51	Specifies the IP address lease time.
52	Specifies the additional option.
53	Specifies the DHCP message type.
54	Specifies the server identifier.
55	Specifies the requested parameter list. It is used by a DHCP client to request specified configuration parameters.
58	Specifies the lease renewal time (T1), which is 50% of the lease time.
59	Specifies the lease renewal time (T2), which is 87.5% of the lease time.
60	Specifies the vendor classification information, which identifies the DHCP client type and configuration.
61	Specifies the client identifier.
66	Specifies the TFTP server name allocated to DHCP clients.
67	Specifies the startup file name allocated to DHCP clients.
77	Specifies the user type.
121	Specifies a group of classless routes. After a DHCP client receives DHCP messages with this option, it adds the classless static routes contained in the option to its routing table. Classless routes are routes of which masks of destination addresses can be any values and masks can be used to divide subnets.

The objects of this field vary depending on 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 configuration parameters to the DHCP client based on the User Class in the Option field. Option 77 is manually configured only on a DHCP client but not on the server.

For more information about common DHCP options, see related RFC document.

Some options, such as Option 82, are not defined in RFC and can be customized.

The Option 82 field is called the DHCP relay agent information field. It records the location of a DHCP client. A DHCP relay agent or a DHCP snooping-enabled device appends the Option 82 field to a DHCP Request message sent from a DHCP client, and then forwards the DHCP Request message to a DHCP server.

An administrator can use the Option 82 field to locate a DHCP client and implement control over security and accounting of the DHCP client. According to information in the Option 82 field, a DHCP server can make a policy for allocating IP addresses and other parameters and provide flexible address allocation schemes.

The Option 82 field contains a maximum of 255 suboptions. If the Option 82 field is defined, at least one suboption must be defined.

The content of the Option 82 field is not uniformly defined, and vendors fill in the Option 82 field as needed. The device supports the following Option 82 field formats:

Type1: This is the Telecom format of Option 82.
Type2: This is the NMS format of Option 82.
Cn-telecom: This is the Option 82 format defined by China Telecom.
Self-define: This is the user-defined format of DHCP Option 82.

This Document Applies to these Products

Page 3

ARP-Ping includes ARP-Ping IP and ARP-Ping MAC. ARP-Ping sends ARP Request packets or ICMP Echo Request packets to check whether a specified IP address or MAC address is used.

ARP-Ping IP checks whether an IP address is used by another device on the LAN by sending ARP packets.

Before configuring an IP address for a device, configure ARP-Ping IP on the device to check whether this IP address has been used by sending ARP Request packets.

You can also run the ping command to check whether this IP address is used by another device on the network. However, if the switch or host that uses the IP address is enabled with the firewall function and the firewall is configured not to respond to ping packets, you may be misled into thinking that this IP address is not used. To solve the problem, use ARP-Ping IP. ARP is a Layer 2 protocol. Therefore, ARP packets can pass through the firewall that is configured not to respond to ping packets.

ARP-Ping IP sends ARP Request packets. ARP-Ping IP is implemented as follows:

After an IP address is specified for a host using the ping arp ip command, the host sends an ARP Request packet and starts a timer of waiting for an ARP Reply packet.
After receiving the ARP Request packet, the switch or host that uses this IP address in the LAN returns an ARP Reply packet.
The sender performs the following two operations based on whether it receives the ARP packet:
- If the sender receives an ARP Reply packet, the sender compares the source IP address carried in the ARP Reply packet with the IP address specified using the arp-ping ip command. If the two IP addresses are the same, the MAC address corresponding to the specified IP address is displayed and the timer is disabled.
- If the sender does not receive an ARP Reply packet before the timer of waiting for an ARP Reply packet expires, the sender displays a message indicating that the IP address is not used by another switch device or host.

The ARP-Ping MAC process is similar to the ping process. The difference is that ARP-Ping MAC applies only to directly connected Ethernet LANs or Layer 2 VPN Ethernet networks.

ARP-Ping MAC sends ICMP Echo Request packets. ARP-Ping MAC is implemented as follows:

After a MAC address is specified for a host using the ping arp mac command, the host sends an ICMP Echo Request packet and starts a timer of waiting for an ICMP Echo Reply packet.
After receiving the ICMP Echo Request packet, the switch device or host that uses this MAC address in the LAN returns an ICMP Echo Reply packet.
The sender performs the following two operations based on whether it receives the ICMP packet:
- If the sender receives an ICMP Echo Reply packet, the sender compares the source MAC address carried in the ICMP Echo Reply packet with the MAC address specified using the arp-ping mac command. If the two MAC addresses are the same, the sender displays the source IP address of the ICMP Echo Reply packet and displays a message indicating that the MAC address is used by another switch device or host. The timer is disabled.
- If the sender does not receive an ARP Reply packet before the timer of waiting for an ICMP Echo Reply packet expires, the sender displays a message indicating that the MAC address is not used by another switch device or host.

This Document Applies to these Products

Page 4

Figure 2-1 shows the format of an ARP Request or Reply packet.

Figure 2-1 Format of an ARP Request or Reply packet

Description of the main fields is as follows:

Hardware Type: indicates the hardware address type. For an Ethernet, the value of this field is 1.
Protocol Type: indicates the type of the protocol address to be mapped. For an IP address, the value of this field is 0x0800.
Hardware Length: indicates the hardware address length. For an ARP Request or Reply packet, the value of this field is 6.
Protocol Length: indicates the protocol address length. For an ARP Request or Reply packet, the value of this field is 4.
OP: indicates the operation type. The value 1 indicates ARP requesting, and the value 2 indicates ARP replying.
Ethernet Address of sender: indicates the MAC address of the sender.
IP Address of sender: indicates the IP address of the sender.
Ethernet Address of destination: indicates the MAC address of the receiver.
IP Address of destination: indicates the IP address of the receiver.

ARP completes address resolution through two processes: ARP request process and ARP reply process.

Figure 2-2 ARP request process

As shown in Figure 2-2, HOSTA and HOSTB are on the same network segment. HOSTA needs to send IP packets to HOSTB.

HOSTA searches the local ARP table for the ARP entry corresponding to HOSTB. If the corresponding ARP entry is found, HOSTA encapsulates the IP packets into Ethernet frames and forwards them to HOSTB based on its MAC address.

If the corresponding ARP entry is not found, HOSTA caches the IP packets and broadcasts an ARP Request packet. In the ARP Request packet, the IP address and MAC address of the sender are the IP address and MAC address of HOSTA. The destination IP address is the IP address of HOSTB, and the destination MAC address contains all 0s. All hosts on the same network segment can receive the ARP Request packet, but only HOSTB processes the packet.

Figure 2-3 ARP reply process

HOSTB compares its IP address with the destination IP address in the ARP Request packet. If HOSTB finds that its IP address is the same as the destination IP address, HOSTB adds the IP address and MAC address of the sender (HOSTA) to the local ARP table. Then HOSTB unicasts an ARP Reply packet, which contains its MAC address, to HOSTA, as shown in Figure 2-3.

After receiving the ARP Reply packet, HOSTA adds HOSTB's MAC address into the local ARP table. Meanwhile, HOSTA encapsulates the IP packets and forwards them to HOSTB.

ARP cache (ARP table)

If HOSTA broadcasts an ARP Request packet every time it communicates with HOSTB, the communication traffic on the network will increase. Furthermore, all hosts on the network have to receive and process the ARP Request packet, which decreases network efficiency.

To solve the preceding problems, each host maintains an ARP cache, which is the key to efficient operation of ARP. This cache contains the recent mapping from IP addresses to MAC addresses.

Before sending IP packets, a host searches the cache for the MAC address corresponding to the destination IP address. If the cache contains the MAC address, the host does not send an ARP Request packet but directly sends the IP packets to the destination MAC address. If the cache does not contain the MAC address, the host broadcasts an ARP Request packet on the network.
Aging time of dynamic ARP entries

After HOSTA receives the ARP Reply packet from HOSTB, HOSTA adds the mapping between the IP address and the MAC address of HOSTB to the ARP cache. However, if a fault occurs on HOSTB or the network adapter of HOSTB is replaced but HOSTA is not notified, HOSTA still sends IP packets to HOSTB. This fault occurs because the ARP entry of HOSTB in the ARP cache on HOSTA is not updated.

To reduce address resolution errors, a timer is set for each ARP entry in an ARP cache. When a dynamic ARP entry expires, the device sends ARP aging probe packets to the corresponding host. If the host does not respond, the ARP entry is deleted, otherwise, the ARP entry is saved.

Configuring the timer reduces address resolution errors but does not eliminate the problem because of the time delay. Specifically, if the length of a dynamic ARP entry timer is N seconds, the sender can detect the fault on the receiver after N seconds. During the N seconds, the cache on the sender is not updated.
Number of probes for aging dynamic ARP entries

Besides setting a timer for dynamic ARP entries, you can set the number of probes for aging dynamic ARP entries to reduce address resolution errors. Before aging a dynamic ARP entry, a host sends ARP aging probe packets. If the host receives no ARP Reply packet after the number of probes reaches the maximum number, the ARP entry is deleted.
Aging probe modes for dynamic ARP entries

Before a dynamic ARP entry on a device is aged out, the device sends ARP aging probe packets to other devices on the same network segment. An ARP aging probe packet can be a unicast or broadcast packet. By default, a device sends the last ARP aging probe message in broadcast mode, and the rest ARP aging probe messages are sent in unicast mode.

If the IP address of the peer device remains the same but the MAC address changes frequently, it is recommended that you configure ARP aging probe packets to be broadcast.

If the MAC address of the peer device remains the same, the network bandwidth is insufficient, and the aging time of ARP entries is short, it is recommended that you configure ARP aging probe packets to be unicast.

When a non-Huawei device connected to a Huawei device receives an ARP aging probe packet whose destination MAC address is a broadcast address, the non-Huawei device checks the ARP table. If the mapping between the IP address and the MAC address of the Huawei device exists in the ARP table, the non-Huawei device drops the ARP aging probe packet. The Huawei device cannot receive a response and therefore deletes the corresponding ARP entry. As a result, traffic from the network cannot be forwarded. In this scenario, the Huawei device needs to send ARP aging probe packets in unicast mode and the non-Huawei device needs to respond to the ARP aging probe packets.

Dynamic ARP entries are generated and maintained dynamically by using ARP packets. They can be aged out, updated, or overwritten by static ARP entries. When the aging time expires or the interface is Down, the corresponding dynamic ARP entries are deleted.

When the egress of ARP entries is a tunnel, in the event of a tunnel status change, the device does not get aware of ARP entries, and ARP entries are automatically deleted when aged out.

Static ARP entries record fixed mapping between IP addresses and MAC addresses and are configured manually by network administrators.

This Document Applies to these Products

Page 5

To obtain a valid dynamic IP address, a DHCP client exchanges different messages with a server at different stages. Generally, a DHCP client and server interact in the following modes.

The DHCP client dynamically obtains an IP address.

Figure 3-4 Procedure for a DHCP client to dynamically obtain an IP address

As shown in Figure 3-4, when a DHCP client accesses the network for the first time, the DHCP client sets up a connection with a DHCP server through the following four stages.
- Discovery stage: The DHCP client searches for the DHCP server.
  
  In this stage, the DHCP client sends a DHCP Discover message to search for the DHCP server. The DHCP server address is unknown to the client, so the DHCP client broadcasts the DHCP Discover message. All the DHCP servers send Reply messages after they receive the Discover message. In this way, the DHCP client knows locations of the DHCP servers on the network.
- Offer stage: The DHCP server offers an IP address to the DHCP client.
  
  The DHCP server receives the DHCP Discover message, selects an IP address from the address pool, and sends a DHCP Offer message to the DHCP client. The Offer message carries information such as the IP address, lease of the IP address, gateway address, and DNS server address.
- Request stage: The DHCP client selects an IP address.
  
  If multiple DHCP servers send DHCP Offer messages to the DHCP client, the client receives the first DHCP Offer message. Then the client broadcasts a DHCP Request message including the information about the DHCP server address (Option 54 field).
  
  The client broadcasts a DHCP Request message to notify all the DHCP servers that the client uses the IP address provided by the DHCP server in the Option 54 field and that all the other servers can use the assigned IP addresses.
- Acknowledgment stage: The DHCP server acknowledges the IP address that is offered.
  
  When the DHCP server receives the DHCP Request message from the DHCP client, the server searches the lease record based on the MAC address in the Request message. If there is the IP address record, the server sends a DHCP ACK message to the client, carrying the IP address and other configurations. After receiving the DHCP ACK message, the DHCP client broadcasts gratuitous ARP packets to detect whether any host is using the IP address assigned by the DHCP server. If no response is received within the specified time, the DHCP client uses the IP address.
  
  If there is no IP address record or the server cannot assign IP addresses, the server sends a DHCP NAK message to notify the DHCP client that the server cannot assign IP addresses. The DHCP client needs to send a new DHCP Discover message to request a new IP address.
  
  After obtaining the IP address, the DHCP client checks the status of the gateway in use before the client goes online. If the gateway address is incorrect or the gateway device fails, the DHCP client requests a new IP address using the four modes for interaction.
The DHCP client reuses the assigned IP address.

Figure 3-5 Procedure for the DHCP client to reuse the assigned IP address

As shown in Figure 3-5, when the DHCP client accesses a network for the second time, it set ups a connection with the DHCP server in the following procedure.
- The client accesses a network for the second time with the IP address that does not expire. The client does not need to send a DHCP Discover message again. It directly sends a DHCP Request message carrying the IP address assigned in the first time, namely, the Option 50 field in the message.
- After receiving the DHCP Request message, if the requested IP address is not assigned to another DHCP client, the DHCP server sends a DHCP ACK message to instruct the DHCP client to use the IP address again.
- If the IP address cannot be assigned to the DHCP client, for example, it has been assigned to another DHCP client, the DHCP server sends a DHCP NAK message to the DHCP client. After receiving the DHCP NAK message, the DHCP client sends a DHCP Discover message to request a new IP address.
The DHCP client renews the IP address lease.

An expected lease can be contained in the DHCP Request message sent to the server for an IP address. The server compares the expected lease with the lease in the address pool and assigns a shorter lease to the client.

The IP address dynamically assigned to the DHCP client usually has a validity period. The DHCP server withdraws the IP address after the validity period expires. To keep using the IP address, the DHCP client needs to renew the IP address lease.

When obtaining an IP address, the DHCP client enters the binding state. The client is configured with three timers to control lease renewal, rebinding, and lease expiration respectively. When assigning an IP address to the DHCP client, the DHCP server also specifies values for the timers. If the server does not specify values for the timers, the client uses the default values. Table 3-5 lists the default timer values.

Table 3-5 Default values of timers
Timer

Default Value

Lease renewal

50% of the lease

Rebinding

87.5% of the lease

Lease expiration

Overall lease

Figure 3-6 Procedure for a DHCP client to renew the IP address lease time

As shown in Figure 3-6, when the DHCP client renews the IP address lease time, it set ups a connection with the DHCP server in the following procedures:
- When 50% of the IP address lease (T1) has passed, the DHCP client unicasts a DHCP Request message to the DHCP server to renew the lease time. If the client receives a DHCP ACK message, the address lease is successfully renewed. If the client receives a DHCP NAK message, it sends a request again.
- When 87.5% of the IP address lease (T2) has passed and the client has not received the Reply message, the DHCP client automatically sends a broadcast message to the DHCP server to renew the IP address lease. If the client receives a DHCP ACK message, the address lease is successfully renewed. If the client receives a DHCP NAK message, it sends a request again.
- If the client has not received a Reply message from the server when the IP address lease expires, the client must stop using the current IP address and send a DHCP Discover message to request a new IP address.
The DHCP client releases an IP address.

When the DHCP client does not use the assigned IP address, it sends a DHCP Release message to notify the DHCP server of releasing the IP address. The DHCP server retains the DHCP client configurations so that the configurations can be used when the client requests an address again.

This Document Applies to these Products

Page 6

Figure 4-1 shows typical networking of a DNS client.

Figure 4-1 Typical networking of a DNS client

As shown in Figure 4-1, the device functions as a DNS client and can dynamically obtain the corresponding IP address of a domain name from a DNS server. This facilitates user communication.

This Document Applies to these Products

Page 7

This section describes how to configure the DHCPv6 function.

This Document Applies to these Products

Page 8

Network devices can communicate at the network layer only after they are configured with IP addresses.

This Document Applies to these Products

Page 9

The SEcure Neighbor Discovery (SEND) protocol is a security extension of the Neighbor Discovery Protocol (NDP) in IPv6.

Pre-configuration Tasks

Before configuring IPv6 SEND, complete the following tasks:

Configuring IPv6 Neighbor Discovery

You can perform the following configuration tasks in sequence.

This Document Applies to these Products

Page 10

The switch can function as a proxy of the destination host to reply an ARP Request message.

Pre-configuration Tasks

Before configuring proxy ARP, complete the following task:

Setting link layer protocol parameters for interfaces to ensure that the link layer protocol status of the interfaces is Up

This Document Applies to these Products

Page 11

ARP-Ping IP sends ARP packets onto a LAN to check whether an IP address is being used by another device on the LAN.

The ping command can also check whether an IP address is in use. If the destination host or the switch configured with the firewall function are configured not to reply to ping packets, there is no response to the ping packet. Consequently, the IP address is considered unused. ARP is a Layer 2 protocol. In most cases, ARP packets can pass through the firewall that is disabled from replying to the Ping packets to prevent the preceding situation.

Run ping arp ip ip-host [ interface interface-type interface-number ] [ timeout timeout ]
Check whether the IP address is used.
- If the following information is displayed, the IP address is not used.
  <HUAWEI> ping arp ip 10.1.1.2 ARP-Pinging 10.1.1.2: Error: Request timeout. Error: Request timeout. Error: Request timeout. Info: The IP address is not used by anyone.
- If the following information is displayed, the IP address is used.
  <HUAWEI> ping arp ip 10.1.1.1 ARP-Pinging 10.1.1.1: 10.1.1.1 is used by 00e0-517d-f202

This Document Applies to these Products

Page 12

When you know a specific MAC address but not the corresponding IP address on a network segment, you can obtain the corresponding IP address using the ping arp mac command to send ICMP packets. In this way, you can obtain the IP address mapping the MAC address.

Run ping arp mac mac-address { ip-address [ vpn-instance vpn-instance-name ] | interface interface-type interface-number }
Check whether the MAC address is used.
- If the following information is displayed, the MAC address is not used.
  <HUAWEI> ping arp mac 286e-d488-b6a7 interface vlanif 109 OutInterface: Vlanif109 MAC[28-6E-D4-88-B6-A7], press CTRL_C to break Error: Request timeout. Error: Request timeout. Error: Request timeout. ----- ARP-Ping MAC statistics ----- 3 packet(s) transmitted 0 packet(s) received MAC[28-6E-D4-88-B6-A7] not be used
- If the following information is displayed, it means that the MAC address is used.
  <HUAWEI> ping arp mac 006d-8834-ae00 10.1.1.0 LANIP: 10.1.1.0 MAC[00-6D-88-34-AE-00], press CTRL_C to break ----- ARP-Ping MAC statistics ----- 1 packet(s) transmitted 1 packet(s) received IP ADDRESS MAC ADDRESS 10.1.1.1 00-6D-88-34-AE-00

This Document Applies to these Products

Page 13

Generally, PMTU is dynamically negotiated according to the IPv6 MTU value of an interface. In special situations, to protect devices on the network and avoid attacks from large-sized packets, you can manually configure the PMTU to a specified destination node to control the maximum length of packets forwarded from the device to the destination node.

Run system-view
The system view is displayed.
(Optional) Configure the IPv6 MTU for an interface.
1. Run interface interface-type interface-number
  
  The specified interface view is displayed.
2. (For Ethernet interfaces) Run undo portswitch
  
  The interface is switched to Layer 3 mode.
  
  By default, an Ethernet interface works in Layer 2 mode.
  
  The command fails if any Layer 2 configuration exists on the interface. In such a case, clear the Layer 2 configurations on the interface before running the undo portswitch command.
  
  You can run the undo portswitch batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to switch the working mode of multiple Ethernet interfaces in batches.
3. Run ipv6 enable
  
  The IPv6 function is enabled on the interface.
  
  By default, the IPv6 function is disabled on an interface.
4. Run ipv6 mtu mtu
  
  The MTU of IPv6 packets on an interface is set.
  
  By default, the MTU of IPv6 packets on an interface is 1500 bytes.
  
  After the MTU value is changed, run the shutdown and undo shutdown commands or the restart command to restart the interface and allow the changes to take effect.
5. Run quit
  
  Return to the system view.
Run ipv6 pathmtu ipv6-address [ vpn-instance vpn-instance-name ] [ path-mtu ]
The PMTU for a specified IPv6 address is set.
Run commit
The configuration is committed.

This Document Applies to these Products

Page 14

In IPv4, oversized packets are fragmented. When the transit device receives a packet exceeding the maximum transmission unit (MTU) size of its outbound interface from a source node, the transit device fragments the packet before forwarding it to the destination node. In IPv6, however, the source node fragments the packets to reduce pressure on the transit device. When an interface on the transit device receives a packet whose size exceeds the MTU, the transit device discards the packet and sends an ICMPv6 Packet Too Big message to the source node. The ICMPv6 Packet Too Big message contains the MTU value of the outbound interface. The source node fragments the packet based on the MTU and resends the packet, increasing traffic overhead. The Path MTU Discovery (PMTUD) protocol dynamically discovers the MTU value of each link on the transmission path, reducing excessive traffic overhead.

The PMTU protocol is implemented through ICMPv6 Packet Too Big messages. A source node first uses the MTU of its outbound interface as the PMTU and sends a probe packet. If a smaller PMTU exists on the transmission path, the transit device sends a Packet Too Big message to the source node. The Packet Too Big message contains the MTU value of the outbound interface on the transit device. After receiving this message, the source node changes the PMTU value to the received MTU value and sends packets based on the new MTU. This process repeats until packets are sent to the destination address. The source node obtains the PMTU of the destination address.

Figure 7-19 shows an example of PMTU discovery.

Figure 7-19 PMTU discovery

Packets are transmitted through four links with MTU values of 1500, 1500, 1400, and 1300 bytes. Before sending a packet, the source node fragments the packet based on a PMTU of 1500. When the packet is sent to the outbound interface with MTU 1400, the device returns a Packet Too Big message carrying MTU 1400. The source node then fragments the packet based on MTU 1400 and sends the fragmented packet again. The process repeats when the packet based on MTU 1400 is sent to the outbound interface with MTU 1300, the device returns another Packet Too Big message that carries MTU 1300. The source node receives the message and fragments the packet based on MTU 1300. In this way, the source node sends the packet to the destination address and discovers the PMTU of the transmission path.

IPv6 allows a minimum MTU of 1280 bytes. Therefore, the PMTU must be greater than 1280 bytes. PMTU of 1500 bytes is recommended.

This Document Applies to these Products

Page 15

The DUID identifies a DHCPv6 device. Each DHCPv6 server or client has a unique DUID. DHCPv6 servers use DUIDs to identify DHCPv6 clients and DHCPv6 clients use DUIDs to identify DHCPv6 servers. The DUID is optional for DHCPv6 relay agents.

Run system-view
The system view is displayed.
Run dhcpv6 enable
DHCPv6 is enabled.

By default, the DHCPv6 function is disabled.
(Optional) Run dhcpv6 duid { duid-value | ll | llt }
A DUID is configured for the device.

By default, the device generates a DUID based on the link-layer (LL) address.
Run commit
The configuration is committed.

This Document Applies to these Products

Page 16

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is designed to assign IPv6 addresses, prefixes, and other network configuration parameters to hosts.

The IPv6 protocol provides huge address space formed by 128-bit IPv6 addresses that require proper and efficient assignment and management policies. IPv6 stateless address autoconfiguration is widely used. Hosts configured with the stateless address autoconfiguration function automatically configure IPv6 addresses based on prefixes carried in Route Advertisement (RA) packets sent from a neighboring device.

When stateless address autoconfiguration is used, devices do not record IPv6 addresses of hosts. Therefore, stateless address autoconfiguration has poor manageability. In addition, hosts configured with stateless address autoconfiguration cannot obtain other configuration parameters such as the DNS server address. Internet service providers (ISPs) do not provide instructions for automatic allocation of IPv6 prefixes for devices. Therefore, users need to manually configure IPv6 addresses for devices during IPv6 network deployment.

DHCPv6 solves this problem. DHCPv6 is a stateful protocol for configuring IPv6 addresses automatically.

Compared with manual address configuration and IPv6 stateless address autoconfiguration that uses network prefixes in RA packets, DHCPv6 has the following advantages:

Controls IPv6 address assignment better. A DHCPv6 device can record addresses assigned to hosts and assign requested addresses. This function facilitates network management.
Assigns IPv6 address prefixes to network devices. This function facilitates automatic configuration and hierarchical network management.
Provides other network configuration parameters such as the DNS server address.

This Document Applies to these Products

Page 17

Dynamic Host Configuration Protocol (DHCP) dynamically manages and configures clients in a centralized manner. It ensures proper IP address allocation and improves IP address utilization.

As the network scale and complexity of networks increase, the number of available IPv4 addresses is no longer sufficient. In addition, wireless networks and mobile devices mean that IPv4 addresses and client locations are liable to change. DHCP is introduced to automate the assignment of network parameters, including IPv4 addresses, to clients.

DHCP is based on the BOOTstrap Protocol (BOOTP), which runs on networks where each host has a fixed network connection. For each host using BOOTP, an administrator must configure a BOOTP parameter file that requires manual intervention to modify. DHCP improves on BOOTP by:

Dynamically allocating IP addresses and configuration parameters to hosts.
Enabling a host to dynamically obtain an IP address without specifying an IP address for each host.

DHCP ensures proper IP address allocation, which prevents IP address waste and improves IP address usage on the entire network.

Devices support DHCP snooping. For details about DHCP snooping, see the CloudEngine 16800 Series Switches Configuration Guide -- Basic Configurations -- DHCP Snooping Configurations.

This Document Applies to these Products

Page 18

The Address Resolution Protocol (ARP) maps IP addresses into MAC addresses.

On a local area network (LAN), a host or a network device must learn the IP address of the destination host or device before sending data to it. Additionally, the host or network device must learn the physical address of the destination host or device because IP packets must be encapsulated into frames for transmission over a physical network. Therefore, the mapping from an IP address into a physical address is required. ARP is used to map IP addresses into physical addresses.

This Document Applies to these Products

Page 19

IPv6 DNS is a distributed database used in TCP and IP applications and completes resolution between IPv6 addresses and domain names. Each host on the IPv6 network is identified by an IPv6 address. To access a host, a user must obtain the host IPv6 address first. It is difficult for users to remember IPv6 addresses of hosts. Therefore, host names in the format of strings are designed. In this way, users can use the simple and meaningful domain names instead of the complicated IPv6 addresses to access hosts by resolution of the DNS server on the network.

The device can function as an IPv6 DNS client.

Figure 9-1 Typical networking of the IPv6 DNS Client

As shown in Figure 9-1, the switch functions as an IPv6 DNS client and supports static and dynamic domain name resolution.

Static domain name resolution: Mappings between domain names and IPv6 addresses are configured manually. To obtain the IPv6 address by resolving a domain name, the DNS client searches the static domain name resolution table for the specified domain name.
Dynamic domain name resolution: Dynamic domain name resolution is implemented by a DNS server. The DNS server receives domain name resolution requests from DNS clients. The DNS server searches for the corresponding IPv6 address of the domain name in its DNS database. If no matching entry is found, it sends a query message to a higher-level DNS server. This process continues until the DNS server finds the corresponding IPv6 address or detects that the corresponding IPv6 address of the domain name does not exist. Then the DNS server returns a result to the DNS client.
The switch IPv6 domain name resolution system must support the following DNS query mode:
- AAAA query: uses a domain name to query an IPv6 address.
- IPv6 PTR query: uses an IPv6 address to query a domain name.

This Document Applies to these Products

Page 20

An IPv6 address is 128 bits long and is written as eight groups of four hexadecimal digits (base 16 digits represented by the numbers 0-9 and the letters A-F). Each group is separated by a colon (:). For example, FC00:0000:130F:0000:0000:09C0:876A:130B is a complete and valid IPv6 address.

For convenience, IPv6 addresses can be written in a compressed format. Taking the IPv6 address FC00:0000:130F:0000:0000:09C0:876A:130B as an example:

Any leading zeroes in a group can be omitted. The example address now becomes FC00:0:130F:0:0:9C0:876A:130B.
A double colon (::) can be used when two or more consecutive groups contain all zeros. The example address now becomes FC00:0:130F::9C0:876A:130B.

An IPv6 address can contain only one double colon (::). Otherwise, a computer cannot determine the number of zeros in a group when restoring the compressed address to the original 128-bit address.

IPv6 addresses have two parts:

Network prefix: Corresponds to the network ID of an IPv4 address. It is comprised of n bits.
Interface identifier (interface ID): Corresponds to the host ID of an IPv4 address. It is comprised of 128-n bits.

You can manually configure the interface ID, generate it through system software, or generate it in IEEE 64-bit Extended Unique Identifier (EUI-64) format. Generating an interface ID in EUI-64 format is the most common practice.

The 64-bit interface ID in an IPv6 address identifies a unique interface on a link. This address is derived from the link-layer address (such as a MAC address) of the interface. The 64-bit IPv6 interface ID is translated from a 48-bit MAC address by inserting a hexadecimal number into the MAC address, and then setting the U/L bit (the leftmost seventh bit) to 1.

If the interface has been configured with a MAC address, the EUI-64 address is generated based on the MAC address of the interface, with FFFE added in the middle.

If the interface has not been configured with a MAC address, the EUI-64 address is generated based on the following rules:

Different Layer 3 physical interfaces may have the same MAC address. To address stacking conflicts, the EUI-64 address of a Layer 3 physical interface or a Layer 3 sub-interface is generated based on the MAC address of the physical interface, with the last two bytes following the interface index added in the middle.
For loopback interfaces, VBDIF interfaces, and tunnel interfaces, the EUI-64 address is generated based on the MAC address of an interface, with the last two bytes following the interface index added in the middle.
For Eth-Trunk interfaces and its sub-interfaces and VLANIF interfaces, the EUI-64 address is generated based on the MAC address of an interface, with FFFE added in the middle.

Taking the insertion of a hexadecimal number FFFE (1111 1111 1111 1110) into the middle of a MAC address as an example, see Figure 7-1 for the detailed conversion procedure.

Figure 7-1 EUI-64 format

For example, if the MAC address is 000E-0C82-C4D4, the interface ID is 020E:0CFF:FE82:C4D4 after the conversion.

Converting MAC addresses into IPv6 interface IDs reduces the configuration workload. When using stateless address autoconfiguration, you only need an IPv6 network prefix to obtain an IPv6 address. One defect of this method, however, is that an IPv6 address is easily calculable based on a MAC address, and could therefore be used for malicious attacks.

IPv6 addresses can be classified as unicast, multicast, or a new class called anycast. Unlike IPv4, there is no broadcast IPv6 address. Instead, a multicast address can be used as a broadcast address.

IPv6 Unicast Address

An IPv6 unicast address identifies an interface. Since each interface belongs to a node, the IPv6 unicast address of any interface can identify the relevant node. Packets sent to an IPv6 unicast address are delivered to the interface identified by that address.

A global unicast address cannot be the same as its network prefix because an IPv6 address which is the same as its network prefix is a subnet-router anycast address reserved for a device. However, this rule does not apply to an IPv6 address with a 127-bit network prefix.

IPv6 defines multiple types of unicast addresses, including the unspecified address, loopback address, global unicast address, link-local address, and unique local address.

Unspecified address

The IPv6 unspecified address is 0:0:0:0:0:0:0:0/128 or ::/128, indicating that an interface or a node does not have an IP address. It can be used as the source IP address of some packets, such as Neighbor Solicitation (NS) messages, in duplicate address detection. Devices do not forward packets with an unspecified address as the source IP address.
Loopback address

The IPv6 loopback address is 0:0:0:0:0:0:0:1/128 or ::1/128. Similar to the IPv4 loopback address 127.0.0.1, the IPv6 loopback address is used when a node needs to send IPv6 packets to itself. This IPv6 loopback address is usually used as the IP address of a virtual interface, such as a loopback interface. The loopback address cannot be used as the source or destination IP address of packets needing to be forwarded.
Global unicast address

An IPv6 global unicast address is an IPv6 address with a global unicast prefix, which is similar to an IPv4 public address. IPv6 global unicast addresses support route prefix summarization, helping limit the number of global routing entries.

Figure 7-2 shows a global unicast address consisting of a global routing prefix, subnet ID, and interface ID.

Figure 7-2 Global unicast address format

These components are described as follows:

Global routing prefix: is assigned by a service provider to an organization. A global routing prefix is comprised of at least 48 bits. Currently, the first 3 bits of every assigned global routing prefix is 001.

Subnet ID: is used by organizations to construct a local network (site). Similar to an IPv4 subnet number, there are a maximum of 64 bits for both the global routing prefix and subnet ID.

Interface ID: identifies a device (host).
Link-local address

Link-local addresses are used only in communication between nodes on the same local link. A link-local address uses a link-local prefix of FE80::/10 as the first 10 bits (1111111010 in binary) and an interface ID as the last 64 bits.

When IPv6 runs on a node, a link-local address that consists of a fixed prefix and an interface ID in EUI-64 format is automatically assigned to each interface of the node. This mechanism enables two IPv6 nodes on the same link to communicate without any configuration, making link-local addresses widely used in neighbor discovery and stateless address configuration.

Devices do not forward IPv6 packets with the link-local address as a source or destination address to devices on different links.

Figure 7-3 shows the link-local address format.

Figure 7-3 Link-local address format
Unique local address

Unique local addresses are used only within a site. Site-local addresses have been replaced by unique local addresses.

Unique local addresses are similar to IPv4 private addresses. Any organization that does not obtain a global unicast address from a service provider can use a unique local address. However, they are routable only within a local network, not the Internet as a whole.

Figure 7-4 shows the unique local address format.

Figure 7-4 Unique local address format

These components are described as follows:

Prefix: is fixed as FC00::/7.

L: is set to 1 if the address is valid within a local network. The value 0 is reserved for future expansion.

Global ID: indicates a globally unique prefix, which is pseudo-randomly allocated.

Subnet ID: identifies a subnet within the site.

Interface ID: identifies an interface.

A unique local address has the following features:
- Has a globally unique prefix that is pseudo-randomly allocated with a high probability of uniqueness.
- Allows private connections between sites without creating address conflicts.
- Has a well-known prefix (FC00::/7) that allows for easy route filtering at site boundaries.
- Does not conflict with any other addresses if it is accidentally routed offsite.
- Functions as a global unicast address to applications.
- Is independent of Internet Service Providers (ISPs).

IPv6 Multicast Address

Like IPv4 multicast addresses, IPv6 multicast addresses identify groups of interfaces, which usually belong to different nodes. A node may belong to any number of multicast groups. Packets sent to an IPv6 multicast address are delivered to all the interfaces identified by the multicast address. For example, the multicast address FF02::1 indicates all nodes within the link-local scope, and FF02::2 indicates all routers within the link-local scope.

An IPv6 multicast address is composed of a prefix, a flag, a scope, and a group ID (global ID).

Prefix: is fixed as FF00::/8.
Flag: is 4 bits long. The high-order 3 bits are reserved and must be set to 0s. The last bit 0 indicates a permanently-assigned, well-known multicast address allocated by the Internet Assigned Numbers Authority (IANA). The last bit 1 indicates a non-permanently-assigned (transient) multicast address.
Scope: is 4 bits long. It limits the scope where multicast data flows are sent on the network. Figure 7-5 shows the field values and meanings.
Group ID (global ID): is 112 bits long. It identifies a multicast group. RFC does not define all the 112 bits as a group ID but recommends using the low-order 32 bits as the group ID and setting all of the remaining 80 bits to 0s. In this case, each multicast group ID maps to a unique Ethernet multicast MAC address.

Figure 7-5 shows the IPv6 multicast address format.

Figure 7-5 IPv6 multicast address format

Solicited-node Multicast Address

A solicited-node multicast address is generated using an IPv6 unicast or anycast address of a node. When a node has an IPv6 unicast or anycast address, a solicited-node multicast address is generated for the node, and the node joins the multicast group that corresponds to its IPv6 unicast or anycast address. Each unicast or anycast address corresponds to a single solicited-node multicast address, which is often used in neighbor discovery and duplicate address detection.

IPv6 does not support broadcast addresses or Address Resolution Protocol (ARP). In IPv6, Neighbor Solicitation (NS) packets are used to resolve IP addresses to MAC addresses. When a node needs to resolve an IPv6 address to a MAC address, it sends an NS packet in which the destination IP address is the solicited-node multicast address corresponding to the IPv6 address.

The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last 24 bits of the corresponding unicast address.

IPv6 Anycast Address

An anycast address identifies a group of network interfaces, which usually belong to different nodes. Packets sent to an anycast address are delivered to the nearest interface that is identified by the anycast address, depending on the routing protocols.

Application scenario: When a mobile host communicates with the mobile agent on the home subnet, it uses the anycast address of the subnet device.

Addresses specifications: Anycast addresses do not have independent address space. They can use the format of any unicast address. Syntax is required to differentiate an anycast address from a unicast address.

As IPv6 defines, an IPv6 address with the interface identifier of all 0s is a subnet-router anycast address. As shown in Figure 7-6, the subnet prefix is an IPv6 unicast address prefix which is specified during configuration of an IPv6 unicast address.

Figure 7-6 Format of a subnet-router anycast address

An anycast address is not necessarily a subnet-router anycast address and can also be a global unicast address.

This Document Applies to these Products

Page 21

To ensure that users can use the IP address normally, ensure that:

An IP address is a network layer address of a host. To transmit data packets to a destination host, the device must obtain the physical address of the host. Therefore, the IP address must be resolved to a physical address.
A host name is easier to remember than an IP address. Therefore, the host name needs to be resolved to the IP address.

On Ethernet, the physical address of a host is the MAC address. The DNS server resolves a host name to an IP address. ARP resolves an IP address to a MAC address. For details, see DNS Configuration and ARP Configuration.

This Document Applies to these Products