No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
Rate and give feedback:
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).
Principles

Principles

This section describes the implementation of IPv6.

IPv6 Addresses

IPv6 Address Formats

An IPv6 address is 128 bits long. It is written as eight groups of four hexadecimal digits (0 to 9, A to F), where each group is separated by a colon (:). For example, 2031:0000:130F:0000:0000:09C0:876A:130B is a valid IPv6 address. This IPv6 address format is the preferred format.

For convenience, IPv6 provides the compressed format. The following uses IPv6 address 2031:0000:130F:0000:0000:09C0:876A:130B as an example to describe the compressed format:

  • Any zeros at the beginning of a group can be omitted. Then the given example becomes 2031:0:130F:0:0:9C0:876A:130B.
  • A double colon (::) can be used in an IPv6 address when two or more consecutive groups contain all zeros. Then the given example can be written as 2031:0:130F::9C0:876A:130B.
NOTE:

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 Address Structure

An IPv6 address has two parts:

  • Network prefix: corresponds to the network ID of an IPv4 address. It is of n bits.

  • Interface identifier (interface ID): corresponds to the host ID of an IPv4 address. It is of 128-n bits.

NOTE:

If the first 3 bits of an IPv6 unicast address are not 000, the interface ID must be of 64 bits. If the first 3 bits are 000, there is no such limitation.

The interface ID can be manually configured, generated through the system software, or generated in IEEE 64-bit Extended Unique Identifier (EUI-64) format. It is most common to generate the interface ID in EUI-64 format.

IEEE EUI-64 standards convert an interface MAC address into an IPv6 interface ID. As shown in Figure 6-42, if a 48-bit MAC address is used as an interface ID, the first 24 bits (expressed by c) is a vendor identifier, and the last 24 bits (expressed by m) is an extension identifier. If the higher seventh bit is 0, the MAC address is locally unique. During conversion, EUI-64 inserts FFFE between the vendor identifier and extension identifier of the MAC address, and then the higher seventh bit 0 is changed to 1 to indicate that the interface ID is globally unique.

Figure 6-42 EUI-64 format

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

The method for converting MAC addresses into IPv6 interface IDs reduces the configuration workload. When stateless address autoconfiguration is used, you only need an IPv6 network prefix before obtaining an IPv6 address. The defect of this method is that an IPv6 address can be easily calculated based on a MAC address.

IPv6 Address Types

IPv6 addresses are classified into unicast, anycast, and multicast addresses. Compared to IPv4, IPv6 has no broadcast address, uses multicast addresses as broadcast addresses, and introduces a new address type anycast address.

IPv6 Unicast Address

An IPv6 unicast address identifies an interface. Each interface belongs to a node. Therefore, the IPv6 unicast address of any interface on a node can identify the node. Packets sent to an IPv6 unicast address are delivered to the interface identified by the unicast address.

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

  • Unspecified address

    An 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) message in duplicate address detection. Devices do not forward the packets with the source IP address as an unspecified address.

  • Loopback address

    An IPv6 loopback address is 0:0:0:0:0:0:0:1/128 or ::1/128. Similar to IPv4 loopback address 127.0.0.1, 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 (a loopback interface for example). The loopback address cannot be used as the source or destination IP address of packets that need 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.

    A global unicast address consists of a global routing prefix, subnet ID, and interface ID, as shown in Figure 6-43.

    Figure 6-43 Global unicast address format

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

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

    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 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, each interface of the node is automatically assigned a link-local address that consists of a fixed prefix and an interface ID in EUI-64 format. This mechanism enables two IPv6 nodes on the same link to communicate without any configuration. Therefore, link-local addresses are 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 6-44 shows the link-local address format.

    Figure 6-44 Link-local address format

  • Unique local address

    Unique local addresses are used only within a site. Site-local addresses are deprecated in RFC 3879 and replaced by unique local addresses in RFC 4193.

    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. Unique local addresses are routable only within a local network but not the Internet.

    Figure 6-45 shows the unique local address format.

    Figure 6-45 Unique local address format

    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 (for details, see RFC 4193).

    Subnet ID: identifies a subnet within the site.

    Interface ID: identifies an interface.

    A unique local address has the following characteristics:
    • Has a globally unique prefix. The prefix is pseudo-randomly allocated and has 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 leaked outside of the site through routing.
    • Functions as a global unicast address to applications.
    • Is independent of the Internet Service Provider (ISP).

IPv6 Multicast Address

Like an IPv4 multicast address, an IPv6 multicast address identifies a group 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, flag, scope, and 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 6-46 shows the field values and meanings.
  • Group ID (global ID): is 112 bits long. It identifies a multicast group. RFC 2373 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 the remaining 80 bits to 0s. In this case, each multicast group ID maps to a unique Ethernet multicast MAC address (for details, see RFC 2464).

Figure 6-46 shows the IPv6 multicast address format.

Figure 6-46 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 the IPv6 unicast or anycast address. A unicast or anycast address corresponds to a 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.

Anycast addresses are designed to implement the redundancy and load balancing functions when multiple hosts or nodes are provided with the same services. Currently, a unicast address is assigned to more than one interface to make a unicast address become an anycast address. When a unicast address is assigned to multiple hosts or nodes, the sender cannot determine which device can receive the sent data packets with the destination IP address as the anycast address, if there are multiple routes to the anycast address. This depends on the routing protocols running on the network. Anycast addresses are used in stateless applications, such as Domain Name Service (DNS).

IPv6 anycast addresses are allocated from the unicast address space. Anycast addresses are used in mobile IPv6 applications.

NOTE:

IPv6 anycast addresses can be assigned only to devices but not hosts. Anycast addresses cannot be used as the source IP addresses of IPv6 packets.

  • Subnet-router anycast address

    A subnet-router anycast address is predefined in RFC 3513. Packets sent to a subnet-router anycast address are delivered to the nearest device on the subnet identified by the anycast address, depending on the routing protocols. All devices must support subnet-router anycast addresses. A subnet-router anycast address is used when a node needs to communicate with any of the devices on the subnet identified by the anycast address. For example, a mobile node needs to communicate with one of the mobile agents on the home subnet.

    In a subnet-router anycast address, the n-bit subnet prefix identifies a subnet and the remaining bits are padded with 0s. Figure 6-47 shows the subnet-router anycast address format.

    Figure 6-47 Subnet-router anycast address format

IPv6 Packet Format

An IPv6 packet has three parts: an IPv6 basic header, one or more IPv6 extension headers, and an upper-layer protocol data unit (PDU).

An upper-layer PDU is composed of the upper-layer protocol header and its payload such as an ICMPv6 packet, a TCP packet, or a UDP packet.

IPv6 Basic Header

An IPv6 basic header is fixed as 40 bytes long and has eight fields. Each IPv6 packet must have an IPv6 basic header. The IPv6 basic header provides basic packet forwarding information and will be parsed by all devices on the forwarding path.

Figure 6-48 shows the IPv6 basic header.

Figure 6-48 IPv6 basic header

An IPv6 basic header contains the following fields:
  • Version: is 4 bits long. In IPv6, the Version field value is 6.
  • Traffic Class: is 8 bits long. It indicates the class or priority of an IPv6 packet. The Traffic Class field is similar to the TOS field in an IPv4 packet and is mainly used in QoS control.
  • Flow Label: is 20 bits long. This field is added in IPv6 to differentiate traffic. A flow label and source IP address identify a data flow. Intermediate network devices can effectively differentiate data flows based on this field.
  • Payload Length: is 16 bits long, which indicates the length of the IPv6 payload. The payload is the rest of the IPv6 packet following this basic header, including the extension header and upper-layer PDU. This field indicates only the payload with the maximum length of 65535 bytes. If the payload length exceeds 65535 bytes, the field is set to 0. The payload length is expressed by the Jumbo Payload option in the Hop-by-Hop Options header.
  • Next Header: is 8 bits long. This field identifies the type of the first extension header that follows the IPv6 basic header or the protocol type in the upper-layer PDU.
  • Hop Limit: is 8 bits long. This field is similar to the Time to Live field in an IPv4 packet, defining the maximum number of hops that an IP packet can pass through. The field value is decremented by 1 by each device that forwards the IP packet. When the field value becomes 0, the packet is discarded.
  • Source Address: is 128 bits long, which indicates the address of the packet originator.
  • Destination Address: is 128 bits long, which indicates the address of the packet recipient.

Compared with the IPv4 packet header, the IPv6 packet header does not carry IHL, identifier, flag, fragment offset, header checksum, option, and paddiing fields but carries the flow label field. This facilitates IPv6 packet processing and improves processing efficiency. To support various options without changing the existing packet format, the Extension Header information field is added to the IPv6 packet header. This improves IPv6 flexibility. The following describes IPv6 extension headers.

IPv6 Extension Header

An IPv4 packet header has an optional field (Options), which includes security, timestamp, and record route options. The variable length of the Options field makes the IPv4 packet header length range from 20 bytes to 60 bytes. When devices forward IPv4 packets with the Options field, many resources need to be used. Therefore, these IPv4 packets are rarely used in practice.

To improve packet processing efficiency, IPv6 uses extension headers to replace the Options field in the IPv4 header. Extension headers are placed between the IPv6 basic header and upper-layer PDU. An IPv6 packet may carry zero, one, or more extension headers. The sender of a packet adds one or more extension headers to the packet only when the sender requests other devices or the destination device to perform special handling. Unlike IPv4, IPv6 has variable-length extension headers, which are not limited to 40 bytes. This facilitates further extension. To improve extension header processing efficiency and transport protocol performance, IPv6 requires that the extension header length be an integer multiple of 8 bytes.

When multiple extension headers are used, the Next Header field of an extension header indicates the type of the next header following this extension header. As shown in Figure 6-49, the Next Header field in the IPv6 basic header indicates the type of the first extension header, and the Next Header field in the first extension header indicates the type of the next extension header. If the next extension header does not exist, the Next Header field indicates the upper-layer protocol type. Figure 6-49 shows the IPv6 extension header format.

Figure 6-49 IPv6 extension header format

An IPv6 extension header contains the following fields:
  • Next Header: is 8 bits long. It is similar to the Next Header field in the IPv6 basic header, indicating the type of the next extension header (if existing) or the upper-layer protocol type.
  • Extension Header Len: is 8 bits long, which indicates the extension header length excluding the Next Header field.
  • Extension Head Data: is of variable length. It includes a series of options and the padding field.

RFC 2460 defines six IPv6 extension headers: Hop-by-Hop Options header, Destination Options header, Routing header, Fragment header, Authentication header, and Encapsulating Security Payload header.

Table 6-16 IPv6 extension headers

Header Type

Next Header Field Value

Description

Hop-by-Hop Options header

0

This header carries information that must be examined by every node along the delivery path of a packet. This header is used in the following applications:
  • Jumbo payload (the payload length exceeds 65535 bytes)
  • Prompting devices to check this option before the devices forward packets.
  • Resource Reservation Protocol (RSVP)

Destination Options header

60

This header carries information that needs to be examined only by the destination node of a packet. Currently, this header is used in mobile IPv6.

Routing header

43

Similar to the Loose Source and Record Route option in IPv4, this header is used by an IPv6 source node to specify the intermediate nodes that a packet must pass through on the way to the destination of the packet.

Fragment header

44

Like IPv4 packets, IPv6 packets to be forwarded cannot exceed the MTU. When the packet length exceeds the MTU, the packet needs to be fragmented. In IPv6, the Fragment header is used by an IPv6 source node to send a packet larger than the MTU.

Authentication header

51

This header is used in IPSec to provide data origin authentication, data integrity check, and packet anti-replay. It also protects some fields in the IPv6 basic header.

Encapsulating Security Payload header

50

Similar to the Authentication header, this header is used in IPSec to provide data origin authentication, data integrity check, packet anti-replay, and IPv6 packet encryption.

Conventions on IPv6 extension headers

When more than one extension header is used in the same packet, the headers must be listed in the following order:

  • IPv6 basic header

  • Hop-by-Hop Options header

  • Destination Options header

  • Routing header

  • Fragment header

  • Authentication header

  • Encapsulating Security Payload header

  • Destination Options header

  • Upper-layer header

Intermediate devices determine whether to process extension headers according to the Next Header field value in the IPv6 basic header. Not all extension headers need to be examined and processed by intermediate devices.

Each extension header can only occur once in an IPv6 packet, except for the Destination Options header. The Destination Options header may occur at most twice (once before a Routing header and once before the upper-layer header).

ICMPv6

The Internet Control Message Protocol version 6 (ICMPv6) is one of the basic IPv6 protocols.

In IPv4, ICMP reports IP packet forwarding information and errors to the source node. ICMP defines certain messages such as Destination Unreachable, Packet Too Big, Time Exceeded, and Echo Request or Echo Reply to facilitate fault diagnosis and information management. In addition to the common functions provided by ICMPv4, ICMPv6 provides mechanisms such as Neighbor Discovery (ID), stateless address configuration including duplicate address detection, and Path Maximum Transmission Unit (PMTU) discovery.

The protocol number of ICMPv6, namely, the value of the Next Header field in an IPv6 packet is 58. Figure 6-50 shows the ICMPv6 packet format.

Figure 6-50 Format of an ICMPv6 packet

Some fields in the packet are described as follows:

  • Type: specifies the message type. Values 0 to 127 indicate the error message type, and values 128 to 255 indicate the informational message type.

  • Code: indicates a specific message type.

  • Checksum: indicates the checksum of an ICMPv6 packet.

Classification of ICMPv6 Error Messages

Error messages report errors generated during IPv6 packet forwarding. ICMPv6 error messages are classified into the following four types:

  • Destination Unreachable message

    During IPv6 packet forwarding, if an IPv6 node detects that the destination address of a packet is unreachable, it sends an ICMPv6 Destination Unreachable message to the source node. Information about the causes for the error message is carried in the message.

    In an ICMPv6 Destination Unreachable message, the value of the Type field is 1. Based on different causes, the value of the Code field can be:

    • Code=0: No route to the destination device.

    • Code=1: Communication with the destination device is administratively prohibited.

    • Code=2: Not assigned.

    • Code=3: Destination IP address is unreachable.

    • Code=4: Destination port is unreachable.

  • Packet Too Big message

    During IPv6 packet forwarding, if an IPv6 node detects that the size of a packet exceeds the link MTU of the outbound interface, it sends an ICMPv6 Packet Too Big message to the source node. The link MTU of the outbound interface is carried in the message. PMTU discovery is implemented based on Packet Too Big messages.

    In a Packet Too Big message, the value of the Type field is 2 and the value of the Code field is 0.

  • Time Exceeded message

    During the transmission of IPv6 packets, when a device receives a packet with the hop limit being 0 or a device reduces the hop limit to 0, it sends an ICMPv6 Time Exceeded message to the source node. During the processing of a packet to be fragmented and reassembled, an ICMPv6 Time Exceeded message is also generated when the reassembly time is longer than the specified period.

    In a Time Exceeded message, the value of the Type field is 3. Based on different causes, the value of the Code field can be:

    • Code=0: Hop limit exceeded in packet transmission.
    • Code=1: Fragment reassembly timeout.
  • Parameter Problem message

    When a destination node receives an IPv6 packet, it checks the validity of the packet. If an error is detected, it sends an ICMPv6 Parameter Problem message to the source node.

    In a Parameter Problem message, the value of the Type field is 4. Based on different causes, the value of the Code field can be:

    • Code=0: A field in the IPv6 basic header or extension header is incorrect.

    • Code=1: The Next Header field in the IPv6 basic header or extension header cannot be identified.

    • Code=2: Unknown options exist in the extension header.

Classification of ICMPv6 Information Messages
ICMPv6 information messages provide the diagnosis and additional host functions such as Multicast Listener Discovery (MLD) and ND. Common ICMPv6 information messages include Ping messages that consist of Echo Request and Echo Reply messages.
  • Echo Request messages: Echo Request messages are sent to destination nodes. After receiving an Echo Request message, the destination node responds with an Echo Reply message. In an Echo Request message, the value of the Type field is 128 and the value of the Code field is 0.

  • Echo Reply messages: After receiving an Echo Request message, the destination node responds with an Echo Reply message. In an Echo Reply message, the value of the Type field is 129 and the value of the Code field is 0.

Neighbor Discovery

The Neighbor Discovery Protocol (NDP) is one important IPv6 basic protocol. It is an enhancement of the Address Resolution Protocol (ARP) and Internet Control Management Protocol (ICMP) router discovery in IPv4. In addition to the function of ICMPv6 address resolution, NDP also provides the following functions: neighbor tracking, duplicate address detection, router discovery, and redirection.

Address Resolution

In IPv4, a host needs to obtain the link-layer address of the destination host through the ARP protocol for communication. Similar to IPv4, the IPv6 NDP protocol parses the IP address to obtain the link-layer address.

ARP packets are encapsulated in Ethernet packets. The Ethernet type value is 0x0806. ARP is defined as a protocol that runs between Layer 2 and Layer 3. ND is implemented through ICMPv6 packets. The Ethernet type value is 0x86dd. The Next Header value in the IPv6 header is 58, indicating that the packets are ICMPv6 packets. NDP packets are encapsulated in ICMPv6 packets. Therefore, NDP is taken as a Layer 3 protocol. Layer 3 address resolution brings the following advantages:
  • Layer 3 address resolution enables Layer 2 devices to use the same address resolution protocol.
  • Layer 3 security mechanisms are used to prevent address resolution attacks.
  • Request packets are sent in multicast mode, reducing performance requirements on Layer 2 networks.
Neighbor Solicitation (NS) packets and Neighbor Advertisement (NA) packets are used during address resolution.
  • In an NS packet, the value of the Type field is 135 and the value of the Code field is 0. An NS packet is similar to the ARP Request packet in IPv4.
  • In an NA packet, the value of the Type field is 136 and the value of the Code field is 0. An NA packet is similar to the ARP Reply packet in IPv4.

Figure 6-51 shows the process of address resolution.

Figure 6-51 IPv6 address resolution

Host A needs to parse the link-layer address of Host B before sending packets to Host B. Therefore, Host A sends an NS message on the network. In the NS message, the source IP address is the IPv6 address of Host A, and the destination IP address is the solicited-node multicast address of Host B. The destination IP address to be parsed is the IPv6 address of Host B. This indicates that Host A wants to know the link-layer address of Host B. The Options field in the NS message carries the link-layer address of Host A.

After receiving the NS message, Host B replies with an NA Reply message. In the NA reply message, the source address is the IPv6 address of Host B, and the destination address is the IPv6 address of Host A (the NS message is sent to Host A in unicast mode using the link-layer address of Host A). The Options field carries the link-layer address of Host B. This is the whole address resolution process.

Neighbor Tracking

Communication with neighboring devices will be interrupted because of various reasons such as hardware fault and hot swapping of interface cards. If the destination address of a neighboring device becomes invalid, communication cannot be restored. If the path fails, communication can be restored. Therefore, nodes need to maintain the neighbor table to monitor the status of each neighboring device. A neighbor state can transit from one to another.

Five neighbor states are defined in RFC2461: Incomplete, Reachable, Stale, Delay, and Probe.

Figure 6-52 shows the transition of neighbor states. The Empty state indicates that the neighbor table is empty.

Figure 6-52 Neighbor state transition

The following example describes the neighbor state changes of node A during the first communication with node B.

  1. Node A sends an NS message and generates a cache entry. The neighbor state of node A is Incomplete.
  2. If node B replies with an NA message, the neighbor state of node A changes from Incomplete to Reachable; otherwise, the neighbor state changes from Incomplete to Empty after a certain period of time. Node A deletes this entry.
  3. After the neighbor reachable time times out, the neighbor state changes from Reachable to Stale, indicating that whether the neighbor is reachable is unknown.
  4. If node A in the Reachable state receives a non-NA Request message from node B, and the link-layer address of node B carried in the message is different from that learned by node A, the neighbor state of node A immediately goes to Stale.
  5. After the aging time times out, the neighbor state changes from Stale to Delay.
  6. After a certain period of time (5s by default), the neighbor state changes from Delay to Probe. During this time, if node A receives an NA Reply message, the neighbor state of node A changes to Reachable.
  7. Node A in the Probe state sends unicast NS messages at the configured interval (1s by default) for several times (3 by default). If node A receives a Reply message, the neighbor state of node A changes from Probe to Reachable; otherwise, the state changes to Empty. Node A deletes this entry.
Duplicate Address Detection

Before an IPv6 unicast address is assigned to an interface, duplicate address detection (DAD) is performed to check whether the address is used by another node. DAD is required if IP addresses are configured automatically. An IPv6 unicast address that is assigned to an interface but has not been verified by DAD is called a tentative address. An interface cannot use the tentative address for unicast communication but will join two multicast groups: ALL-nodes multicast group and Solicited-node multicast group.

IPv6 DAD is similar to IPv4 gratuitous ARP. A node sends an NS message that requests the tentative address as the destination address to the Solicited-node multicast group. If the node receives an NA message, the tentative address is being used by another node. This node will not use this tentative address for communication.

Figure 6-53 shows the DAD working principle.

Figure 6-53 DAD example

An IPv6 address 2000::1 is assigned to Host A as a tentative IPv6 address. To check the validity of 2000::1, Host A sends an NS message to the Solicited-node multicast group to which 2000::1 belongs. The NS message contains the requested address 2000::1. Since 2000::1 is not specified, the source address of the NS message is an unspecified address. After receiving the NS message, Host B processes the message in the following ways:

  • If 2000::1 is one tentative address of Host B, Host B will not use this address as an interface address and not send the NA message.

  • If 2000::1 is being used on Host B, Host B sends an NA message to FF02::1. The NA message carries IP address 2000::1. In this way, Host A can find that the tentative address is duplicated after receiving the message. The tentative address then does not take effect on Host A and is marked as duplicated.

Router Discovery

Router discovery is used to locate a neighboring device and learn the address prefix and configuration parameters for address autoconfiguration.

IPv6 supports stateless address autoconfiguration. Hosts obtain IPv6 prefixes and automatically generate interface IDs. Router Discovery is the basics for IPv6 address autoconfiguration and is implemented through the following two packets:

  • Router Advertisement (RA) message: Each router periodically sends multicast RA messages that carry network prefixes and identifiers on the network to declare its existence to Layer 2 hosts and devices. An RA message has a value of 134 in the Type field.
  • Router Solicitation (RS) message: After being connected to the network, a host immediately sends an RS message to obtain network prefixes. Devices on the network reply with an RA message. An RS message has a value of 133 in the Type field.

Figure 6-54 shows the router discovery function.

Figure 6-54 Router discovery example

Address Autoconfiguration

IPv4 uses DHCP to automatically configure IP addresses and default gateways. This simplifies network management. The length of an IPv6 address is increased to 128 bits. Multiple terminal nodes require the function of automatic configuration. IPv6 allows both stateful and stateless address autoconfiguration. Stateless autoconfiguration enables hosts to automatically generate link-local addresses. Based on the prefixes in the RA message, hosts automatically configure global unicast addresses and obtain other information.

The process of IPv6 stateless autoconfiguration is as follows:

  1. A host automatically configures the link-local address based on the interface ID.
  2. The host sends an NS message for duplicate address detection.
  3. If address conflict occurs, the host stops address autoconfiguration. Then addresses need to be configured manually.
  4. If addresses do not conflict, the link-local address takes effect. The host is connected to the network and can communicate with the local node.
  5. The host sends an RS message or receives RA messages devices periodically send.
  6. The host obtains the IPv6 address based on the prefixes carried in the RA message and the interface ID.

Default Router Priority and Route Information Discovery

If multiple devices exist on the Internet where hosts reside, hosts need to select forwarding devices based on the destination address of the packet. In such a case, devices advertise default router priorities and route information, which allows hosts to select the optimal forwarding device based on the packet destination address.

The fields of default router priority and route information are defined in an RA message. These two fields enable hosts to select the optimal forwarding device.

After receiving an RA message that contains route information, hosts update their routing tables. When sending packets to other devices, hosts check the route in the routing table and select the optimal route.

When receiving an RA message that carries default router priorities, hosts update their default router lists. When sending packets to other devices, hosts check the router list to select the device with the highest priority to forward packets. If the selected router does not work, hosts select the device in descending order of priorities.

Redirection

To choose an optimal gateway device, the gateway device sends a Redirection message to notify the sender that packets can be sent from another gateway device. A Redirection message is contained in an ICMPv6 message. A Redirection message has the value of 137 in the Type field and carries a better next hop address and destination address of packets that need to be redirected.

Figure 6-55 shows the process of redirecting packets.

Figure 6-55 Packet redirection example

Host A needs to communicate with Host B. By default, packets sent from Host A to Host B are sent through Switch A. After receiving packets from Host A, Switch A finds that sending packets to Switch B is much better. Switch A sends a Redirection message to Host A to notify Host A that Switch B is a better next hop address. The destination address of Host B is carried in the Redirection message. After receiving the Redirection message, Host A adds a host route to the default routing table. Packets sent to Host B will be directly sent to Switch B.

A device sends a Redirection message in the following situations:

  • The destination address of the packet is not a multicast address.
  • Packets are not forwarded to the device through the route.
  • After route calculation, the outbound interface of the next hop is the interface that receives the packets.
  • The device finds that a better next hop IP address of the packet is on the same network segment as the source IP address of the packet.
  • After checking the source address of the packet, the device finds a neighboring device in the neighbor entries that uses this address as the global unicast address or the link-local unicast address.

IPv6 SEcure Neighbor Discovery

In the IPv6 protocol suite, ND is significant in ensuring availability of neighbors on the local link. As network security problems intensify, how to secure ND becomes a concern. RFC 3756 defines several threats to ND security, some of which are described as follows:

Table 6-17 IPv6 ND attacks

Attack Method

Description

NS/NA spoofing

An attacker sends an authorized node (host or switch) an NS message with a bogus source link-layer address option, or an NA message with a bogus target link-layer address option. Then packets from the authorized node are sent to this link-layer address.

Neighbor Unreachability Detection (NUD) failure

An attacker repeatedly sends forged NA messages in response to an authorized node's NUD NS messages so that the authorized node cannot detect the neighbor unreachability. The consequences of this attack depend on why the neighbor became unreachable and how the authorized node would behave if it knew that the neighbor has become unreachable.

Duplicate Address Detection (DAD) attacks

An attacker responds to every DAD attempt made by a host that accesses the network, claiming that the address is already in use. Then the host will never obtain an address.

Spoofed Redirect message

An attacker uses the link-local address of the first-hop switch to send a Redirect message to an authorized host. The authorized host accepts this message because the host mistakenly considers that the message came from the first-hop switch.

Replay attacks

An attacker captures valid messages and replays them. Even if Neighbor Discovery Protocol (NDP) messages are cryptographically protected so that their contents cannot be forged, they are still prone to replay attacks.

Bogus address prefix

An attacker sends a bogus RA message specifying that some prefixes are on-link. If a prefix is on-link, a host will not send any packets that contain this prefix to the switch. Instead, the host will send NS messages to attempt address resolution, but the NS messages are not responded. As a result, the host is denied services.

Malicious last-hop switch

An attacker multicasts bogus RA messages or unicasts bogus RA messages in response to multicast RS messages to a host attempting to discover a last-hop switch. If the host selects the attacker as its default switch, the attacker is able to insert himself as a man-in-the-middle and intercepts all messages exchanged between the host and its destination.

To counter these threats, Secure Neighbor Discovery (SEND), defined in RFC 3971, specifies security mechanisms to extend ND. SEND defines Cryptographically Generated Addresses (CGAs), CGA option, and Rivest Shamir Adleman (RSA) option, which are used to ensure that the sender of an ND message is the owner of the message's source address. SEND also defines Timestamp and Nonce options to prevent replay attacks.

  • CGA: An CGA contains network prefix and interface identifier. Interface identifier is generated from a one-way hash of the public key and associated parameters.
  • CGA option: contains information used to verify the sender's CGA, including the public key of the sender. CGA is used to authenticate the validity of source IP addresses carried in ND messages.
  • RSA option: contains the hash value of the sender's public key and contains the digital signature generated from the sender's private key and ND messages. RSA is used to authenticate the completeness of ND messages and the identity of the ND message sender.
    NOTE:
    For an attacker to use an address that belongs to an authorized node, the attacker must use the public key of the authorized node for encryption. Otherwise, the receiver can detect the attempted attack after checking the CGA option. Even if the attacker obtains the public key of the authorized node, the receiver can still detect the attempted attack after checking the digital signature, which is generated from the sender's private key.
  • Timestamp option: a 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC.This option protects non-solicit notification messages and Redirect messages and ensures that the timestamp of the recently received message is the latest.
  • Nonce option: contains a random number selected by the sender of a solicitation message. This option prevents replay attacks during message exchange. For example, a sender sends an NS message carrying the Nonce option and receives an NA message as a response that also carries the Nonce option; the sender verifies the NA message based on the Nonce option.

Path MTU

In IPv4, a packet needs to be fragmented if it is oversized. When the transit device receives from a source node a packet whose size exceeds the maximum transmission unit (MTU) of its outbound interface, the transit device fragments the packet before forwarding it to the destination node. In IPv6, however, packets are fragmented on the source node to reduce the 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 sends the packet again. This increases 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 the message, the source node changes the PMTU value to the received MTU value and sends packets based on the new MTU. This process is repeated until packets are sent to the destination address. Then the source node obtains the PMTU of the destination address.

Figure 6-56 shows the process of PMTU discovery.

Figure 6-56 PMTU discovery

Packets are transmitted through four links. The MTU values of the four links are 1500, 1500, 1400, and 1300 bytes respectively. Before sending a packet, the source node fragments the packet based on PMTU 1500. When the packet is sent to the outbound interface with MTU 1400, the device returns a Packet Too Big message that carries MTU 1400. After receiving the message, the source node fragments the packet based on MTU 1400 and sends the fragmented packet again. When the packet 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.

NOTE:

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

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 59630

Downloads: 3623

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next