Home | Me | My Resume | Tech-Zone | Downloads | My Photos | E- Links | Contact | Messages4U | IPv6 | C  | C++

IPv6 The current version of IP (known as Version 4 or IPv4) has not been substantially changed since RFC 791 was published in 1981. IPv4 has proven to be robust, easily implemented and interoperable, and has stood the test of scaling an internetwork to a global utility the size of today's Internet. However, the initial design did not anticipate the following: · The recent exponential growth of the Internet and the impending exhaustion of the IPv4 address space. · The growth of the Internet and the ability of Internet backbone routers to maintain large routing tables. · The need for simpler configuration. · The requirement for security at the IP level. · The need for better support for real-time delivery of data—also called quality of service (QoS). To address these concerns, the Internet Engineering Task Force (IETF) has developed a suite of protocols and standards known as IP version 6 (IPv6). This new version, previously called IP-The Next Generation (IPng), incorporates the concepts of many proposed methods for updating the IPv4 protocol. The design of IPv6 is intentionally targeted for minimal impact on upper and lower layer protocols by avoiding the random addition of new features. IPv6 Features The following are the features of the IPv6 protocol: · New header format · Large address space · Efficient and hierarchical addressing and routing infrastructure · Stateless and stateful address configuration · Built-in security · Better support for QoS · New protocol for neighboring node interaction · Extensibility
IPv6 Addressing The IPv6 Address Space The most obvious distinguishing feature of IPv6 is its use of much larger addresses. The size of an address in IPv6 is 128 bits, which is four times the larger than an IPv4 address A 32-bit address space allows for 4,294,967,296 possible addresses. A 128-bit address space allows for 340,282,266,920,938,463,463,374,607,431,768,211,465 (or 3.4*1038) possible addresses. The relatively large size of the IPv6 address is designed to be subdivided into hierarchical routing domains that reflect the topology of the modern-day Internet. The use of 128 bits allows for multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing that is currently lacking on the IPv4-based Internet. Current Allocation Similar to the same way in which the IPv4 address space is divided, the IPv6 address space is divided based on the value of high order bits. The high order bits and their fixed values are known as a Format Prefix (FP). Table 1 shows the allocation of the IPv6 address space by FPs. IPv6 Address Syntax IPv4 addresses are represented in dotted-decimal format. For IPv6, the 128-bit address is divided along 16-bit boundaries, and each 16-bit block is converted to a 4-digit hexadecimal number and separated by colons. The resulting representation is called colon-hexadecimal. For example 21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A A contiguous sequence of 16-bit blocks set to 0 in the colon hexadecimal format can be compressed to "::", known as double-colon. For example, FF02:0:0:0:0:0:0:2 can be compressed to FF02::2. Allocation Format Prefix (FP) Fraction of the Address Space Reserved 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP allocation 0000 001 1/128 Reserved for IPX allocation 0000 010 1/128 Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Aggregatable global unicast addresses 001 1/8 Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link-local unicast addresses 1111 1110 10 1/1024 Site-local unicast addresses 1111 1110 11 1/1024 Multicast addresses 1111 1111 1/256 IPv6 Prefixes The prefix is the part of the address that indicates the bits that have fixed values or are the bits of the network identifier. An IPv6 prefix is written in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix. A subnet mask is not used for IPv6. Only the prefix length notation is supported. Types of IPv6 Addresses There are three types of IPv6 addresses: 1. Unicast: A unicast address identifies a single interface within the scope of the type of unicast address. 2. Multicast: A multicast address identifies multiple interfaces. 3. Anycast: An anycast address identifies multiple interfaces. Packets addressed to an anycast address are delivered to a single interface, the nearest interface that is identified by the address. The "nearest" interface is defined as being closest in terms of routing distance. A multicast address is used for one-to-many communication, with delivery to multiple interfaces. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface. All types of IPv4 broadcast addressing are performed in IPv6 using multicast addresses. For example, the subnet and limited broadcast addresses from IPv4 are replaced with the link-local scope all-nodes multicast address of FF02::1. Unicast IPv6 Addresses The following types of addresses are unicast IPv6 addresses: · Aggregatable global unicast addresses · Link-local addresses · Site-local addresses · Special addresses · NSAP and IPX addresses Aggregatable Global Unicast Addresses Aggregatable global unicast addresses, identified by the FP of 001, are equivalent to public IPv4 addresses. They are globally routable and reachable on the IPv6 portion of the Internet known as the 6bone (IPv6 backbone). The fields in the aggregatable global unicast address are: TLA ID – Top Level Aggregator (TLA) for the address. The size of this field is 13 bits. Res – 8 bits are reserved for future use in expanding the size of either the TLA ID or the NLA ID. NLA ID – The Next-Level Aggregator (NLA) for the address. The size of this field is 24 bits. SLA ID – The Site-Level Aggregator (SLA) for the address. The size of this field is 16 bits. Interface ID – Indicates the interface on a specific subnet. The size of this field is 64 bits. Link-Local Addresses Link-local addresses, identified by the FP of 1111 1110 10, are used by nodes when communicating with neighboring nodes on the same link. For example, on a single link IPv6 network with no router, link-local addresses are used to communicate between hosts on the link. The scope of a link-local address is the local link. With the 64-bit interface identifier, the prefix for link-local addresses is always FE80::/64. An IPv6 router never forwards link-local traffic beyond the link. Site-Local Addresses Site-local addresses, identified by the FP of 1111 1110 11, are equivalent to the IPv4 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). The scope of a site-local address is the site (the organization internetwork). The first 48-bits are always fixed for site-local addresses, beginning with FEC0::/48. After the 48 fixed bits is a 16-bit subnet identifier (Subnet ID field). After the Subnet ID field is a 64-bit Interface ID field that identifies a specific interface on a subnet. Special IPv6 Addresses The following are special IPv6 addresses: · Unspecified address: The unspecified address (0:0:0:0:0:0:0:0 or ::) is only used to indicate the absence of an address. · Loopback address: The loopback address (0:0:0:0:0:0:0:1 or ::1) is used to identify a loopback interface, enabling a node to send packets to itself. It is equivalent to the IPv4 loopback address of 127.0.0.1. NSAP and IPX Addresses To provide a way of mapping Network Service Access Point (NSAP) and Internetwork Packet Exchange (IPX) addresses to IPv6 addresses, NSAP and IPX addresses are defined. · NSAP addresses NSAP addresses use the FP of 0000001 and map the last 121 bits of the IPv6 address to an NSAP address. (RFC 1888) · IPX addresses IPX addresses use the FP of 0000010 and map the last 121 bits of the IPv6 address to an IPX address. The mapping of an IPX address to an IPv6 address has not yet been defined. Multicast IPv6 Addresses An IPv6 address is easy to classify as multicast because it always begins with "FF". Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header. Beyond the FP, multicast addresses include additional structure to identify their flags, scope, and multicast group. FP Flag Scope Group ID Flags – Indicates flags set on the multicast address. The size of this field is 4 bits. As of RFC 2373, the only flag defined is the Transient (T) flag. When set to 0, the T flag indicates that the multicast address is a permanently- assigned (well-known) multicast address allocated by the Internet Assigned Numbers Authority (IANA). When set to 1, the T flag indicates that the multicast address is a transient (non-permanently-assigned) multicast address. Scope – Indicates the scope of the IPv6 internetwork for which the multicast traffic is intended. The size of this field is 4 bits. Table lists the defined values for the Scope field. Value Scope 0 Reserved 1 Node-local scope 2 Link-local scope 5 Site-local scope 8 Organization-local scope E Global scope F Reserved To identify all nodes for the node-local and link-local scopes, the following addresses are defined: · FF01::1 (node-local scope all-nodes multicast address) · FF02::1 (link-local scope all-nodes multicast address) To identify all routers for the node-local, link-local, and site-local scopes, the following addresses are defined: · FF01::2 (node-local scope all-routers multicast address) · FF02::2 (link-local scope all-routers multicast address) · FF05::2 (site-local scope all-routers multicast address) Anycast IPv6 Addresses An anycast address is assigned to multiple interfaces. Packets addressed to an anycast address are forwarded by the routing infrastructure to the nearest interface to which the anycast address is assigned. In order to facilitate delivery, the routing infrastructure must be aware of the interfaces assigned anycast addresses and their "distance" in terms of routing metrics. At present, anycast addresses are only used as destination addresses and are only assigned to routers. Anycast addresses are assigned out of the unicast address space and the scope of an anycast address is the scope of the type of unicast address from which the anycast address is assigned. The Subnet-Router anycast address is predefined and required. It is created from the subnet prefix for a given interface. To construct the Subnet-Router anycast address, the bits in the subnet prefix are fixed at their appropriate values and the remaining bits are set to 0. IPv6 Interface Identifiers All addresses that use the prefixes 001 through 111 must also use a 64-bit interface identifier that is derived from the EUI-64 address. The 64-bit EUI-64 address is defined by the Institute of Electrical and Electronic Engineers (IEEE). EUI-64 addresses are either assigned to a network adapter card or derived from IEEE 802 addresses.
IPv6 HEADER The IPv6 header is a streamlined version of the IPv4 header. It eliminates fields that are unneeded or rarely used and adds fields that provide better support for real-time traffic. The fields in the IPv6 header are: Version – 4 bits are used to indicate the version of IP and is set to 6. Traffic Class – Indicates the class or priority of the IPv6 packet. The size of this field is 8 bits. The Traffic Class field provides similar functionality to the IPv4 Type of Service field. In RFC 2460, the values of the Traffic Class field are not defined. Flow Label – Indicates that this packet belongs to a specific sequence of packets between a source and destination, requiring special handling by intermediate IPv6 routers. The size of this field is 20 bits. The Flow Label is used for non-default quality of service connections, such as those needed by real-time data (voice and video). For default router handling, the Flow Label is set to 0. There can be multiple flows between a source and destination, as distinguished by separate non-zero Flow Labels. Payload Length – Indicates the length of the IP payload. The size of this field is 16 bits. The Payload Length field includes the extension headers and the upper layer PDU. With 16 bits, an IPv6 payload of up to 65,535 bytes can be indicated. For payload lengths greater than 65,535 bytes, the Payload Length field is set to 0 and the Jumbo Payload option is used in the Hop-by-Hop Options extension header. Next Header – Indicates either the first extension header (if present) or the protocol in the upper layer PDU (such as TCP, UDP, or ICMPv6). The size of this field is 8 bits. When indicating an upper layer protocol above the Internet layer, the same values used in the IPv4 Protocol field are used here. Hop Limit – Indicates the maximum number of links over which the IPv6 packet can travel before being discarded. The size of this field is 8 bits. When the Hop Limit equals 0, the packet is discarded and an ICMP Time Expired message is sent to the source address. Source Address –Stores the IPv6 address of the originating host. The size of this field is 128 bits. Destination Address – Stores the IPv6 address of the current destination host. The size of this field is 128 bits. In most cases the Destination Address is set to the final destination address. However, if a Routing extension header is present, the Destination Address might be set to the next router interface in the source route list. Values of the Next Header Field Table shows the typical values of the Next Header field for an IPv6 header or an IPv6 extension header. Value (in decimal) Header 0       Hop-by-Hop Options Header 6       TCP 17       UDP 41       Encapsulated IPv6 Header 43       Routing Header 44       Fragmentation Header 46       Resource ReSerVation Protocol 50       Encapsulating Security Payload 51       Authentication Header 58       ICMPv6 59       No next header 60       Destination Options Header IPv6 Extension Headers The IPv4 header includes all options. Therefore, each intermediate router must check for their existence and process them when present. This can cause performance degradation in the forwarding of IPv4 packets. With IPv6, delivery and forwarding options are moved to extension headers. The only extension header that must be processed at each intermediate router is the Hop-by-Hop Options extension header. This increases IPv6 header processing speed and improves forwarding process performance. RFC 2460 defines the following IPv6 extension headers that must be supported by all IPv6 nodes: · Hop-by-Hop Options header · Destination Options header · Routing header · Fragment header · Authentication header · Encapsulating Security Payload header In a typical IPv6 packet, no extension headers are present. If special handling is required by either the intermediate routers or the destination, one or more extension headers are added by the sending host. Each extension header must fall on 64-bit (8-byte) boundaries. Extension headers of variable size contain a Header Extension Length field and must use padding as needed to ensure that their size is a multiple of 8 bytes. Extension Headers Order Extension headers are processed in the order in which they are present. Because the only extension header that is processed by every node on the path is the Hop-by-Hop Options header, it must be first. There are similar rules for other extension headers. In RFC 2460, it is recommended that extension headers be placed in the IPv6 header in the following order: 1. Hop-by-Hop Options header 2. Destination Options header 3. Routing header 4. Fragment header 5. Authentication header 6. Encapsulating Security Payload header 7. Destination Options header (for the final destination) Hop-by-Hop Options Header The Hop-by-Hop Options header is used to specify delivery parameters at each hop on the path to the destination. It is identified by the value of 0 in the IPv6 header's Next Header field. Figure shows the Hop-by-Hop Options header. The Hop-by-Hop Options header consists of a Next Header field, a Header Extension Length field, and an Options field that contains one or more options. The value of the Header Extension Length field is the number of 8-byte blocks in the Hop-by-Hop Options extension header, not including the first 8 bytes. Padding options are used to ensure 8-byte boundaries. An option is a header within the Hop-by-Hop Options header that either describes a specific characteristic of the packet delivery or provides padding. Each option is encoded in the type-length-value (TLV) format that is commonly used in TCP/IP protocols. The option type both identifies the option and determines the way it is handled by the processing node. The option length identifies its length. The option value is the data associated with the option. RFCs 2460, 2675, and 2711 define the following options: · The Pad1 option (Option Type 0) is used to insert a single byte of padding. · The PadN option (Option Type 1) is used to insert 2 or more bytes of padding. · The Jumbo Payload option (Option Type 194) is used to indicate a payload size that is greater than 65,535 bytes. With the Jumbo Payload option, payload sizes of up to 4,294,967,295 bytes can be indicated using a 32-bit Jumbo Payload Length field. An IPv6 packet with a payload size greater than 65,535 bytes is named a jumbogram. The Router Alert option (Option Type 5) is used to indicate to the router that the contents of the packet require additional processing. The Router Alert option is used for Multicast Listener Discovery and the Resource ReSerVation Protocol (RSVP). Destination Options Header The Destination Options header is used to specify packet delivery parameters for either intermediate destinations or the final destination. This header is identified by the value of 60 in the previous header's Next Header field. The fields within the Destination Options header are defined the same as the Hop-by-Hop Options header. The Destination Options header is used in two ways: 1. If a Routing header is present, it specifies delivery or processing options at each intermediate destination. 2. It specifies delivery or processing options at the final destination. Routing Header Similar to the source routing supported by IPv4, IPv6 source nodes can use the Routing extension header to specify a source route, a list of intermediate destinations for the packet to travel to on its path to the final destination. The Routing header is identified by the value of 43 in the previous header's Next Header field. The Routing header consists of a Next Header field, a Header Extension Length field (defined the same way as the Hop-by-Hop Options extension header), a Routing Type field, a Segments Left field, and routing type-specific data. For Routing Type 0, which is defined in RFC 2460, the routing type-specific data is a list of intermediate destination addresses. When the IPv6 packet reaches an intermediate destination, the Routing header is processed and the address of the next intermediate destination (based on the value of the Segments Left field) becomes the Destination Address in the IPv6 header. Fragment Header The Fragment header is used for IPv6 fragmentation and reassembly services. This header is identified by the value of 44 in the previous header's Next Header field. Figure shows the Fragment header. The Fragment header includes a Next Header field, a 13-bit Fragment Offset field, a More Fragments flag, and a 32-bit Identification field. The Fragment Offset, More Fragments flag, and Identification fields are used in the same way as the corresponding fields in the IPv4 header. Because the use of the Fragment Offset field is defined for 8-byte fragment blocks, the Fragment header cannot be used for IPv6 jumbograms. In IPv6, only source nodes can fragment payloads. If the payload submitted by the upper layer protocol is larger than the link or path MTU, then IPv6 fragments the payload at the source and uses the Fragment extension header to provide reassembly information. When an IPv6 packet is fragmented, it is initially divided into unfragmentable and fragmentable parts: · The unfragmentable part of the original IPv6 packet must be processed by each intermediate node between the fragmenting node and the destination. This part consists of the IPv6 header, the Hop-by-Hop Options header, the Destination Options header for intermediate destinations, and the Routing header. · The fragmentable part of the original IPv6 packet must only be processed at the final destination node. This part consists of the Authentication header, the Encapsulating Security Payload header, the Destination Options header for the final destination, and the upper layer PDU. Authentication Header The Authentication header provides data authentication (verification of the node that sent the packet), data integrity (verification that the data was not modified in transit), and anti-replay protection (assurance that captured packets cannot be retransmitted and accepted as valid data) for the IPv6 packet. The Authentication header, described in RFC 2402, is part of the Security Architecture for the Internet Protocol defined in RFC 2401. The Authentication header contains a Next Header field, a Header Length field, a Security Parameters Index (SPI) field that identifies a specific IP Security (IPSec) security association (SA), a Sequence Number field that provides anti-replay protection, and an Authentication Data field that contains an integrity check value (ICV). The ICV provides data authentication and integrity. The Authentication extension header does not provide data confidentiality services by encrypting the data. To provide this, the Authentication header can be used in conjunction with the Encapsulating Security Payload (ESP) header. Encapsulating Security Payload Header and Trailer The Encapsulating Security Payload (ESP) header and trailer provide data confidentiality, data authentication, and data integrity services to the encapsulated payload. In contrast, the Authentication header provides data authentication and integrity services for the entire IPv6 packet. The ESP header and trailer are identified by the value of 50 in the previous header's Next Header field. IPv6 MTU IPv6 requires that the link layer support a minimum IPv6 packet size of 1280 bytes. Link layers that do not support this must provide a link layer fragmentation and reassembly scheme that is transparent to IPv6. For link layers that can support a configurable MTU size, it is recommended that they be configured with an MTU size of at least 1500 bytes (the Ethernet II encapsulation IPv6 MTU). An example of a configurable MTU is the Maximum Receive Unit (MRU) of a Point-to-Point Protocol (PPP) link. Like IPv4, IPv6 provides for a Path MTU Discovery process using the ICMPv6 Packet Too Big message described in "Path MTU Discovery." Path MTU Discovery allows the transmission of IPv6 packets for sizes greater than 1280 bytes. IPv6 source hosts can fragment payloads of upper layer protocols that are larger than the path MTU by using the process and Fragment header previously described. However, the use of IPv6 fragmentation is highly discouraged. An IPv6 node must be able to reassemble a fragmented packet that is at least 1500 bytes in size.
ICMPv6 IPv6 uses an updated version of the Internet Control Message Protocol (ICMP) named ICMP version 6 (ICMPv6). ICMPv6 has the common IPv4 ICMP functions of reporting delivery or forwarding errors and providing a simple echo service for troubleshooting. The ICMPv6 protocol also provides a framework for the following: · Multicast Listener Discovery (MLD) · Neighbor Discovery (ND) ICMPv6 Header An ICMPv6 header is indicated by setting the previous header's Next Header field to 58. Figure shows the structure of all ICMPv6 messages. The fields in the ICMPv6 header are: Type – Indicates the type of ICMPv6 message. The size of this field is 8 bits. In ICMPv6 error messages, the high-order bit is set to 0. In ICMPv6 informational messages, the high-order bit is set to 1. Code – Differentiates among multiple messages within a given message type. The size of this field is 8 bits. If there is only one message for a given type, the Code field is set to 0. Checksum – Stores a checksum of the ICMP message. The size of this field is 16 bits. Message body – Contains ICMPv6 message-specific data. ICMPv6 Error Messages ICMPv6 error messages are used to report forwarding or delivery errors by either a router or the destination host. To conserve network bandwidth, ICMPv6 error messages are not sent for every error encountered. Instead, ICMPv6 error messages are rate limited. Rate limiting can be based on a timer (the rate is one error message per source or any source for every T milliseconds [suggested value of 1000]), or based on a percentage of bandwidth (the rate of error messages sent per interface is some percentage P of the link's bandwidth [suggested value of 2%]). Destination Unreachable An ICMPv6 Destination Unreachable message is sent by either a router or a destination host when the packet cannot be forwarded to its destination. In the Destination Unreachable message, the Type field is set to 1 and the Code field is set to a value in the range of 0 through 4. After the Checksum field is the 32-bit Unused field and the portion of the discarded packet that makes the entire IPv6 packet containing the ICMPv6 message no larger than 1280 bytes (the minimum IPv6 MTU). The number of bytes of the discarded packet included in the message varies if there are IPv6 extension headers present. For an ICMPv6 message without extension headers, 1232 bytes of the discarded packet are included (1280 less a 40-byte IPv6 header and an 8-byte ICMPv6 Destination Unreachable header). Table shows the value of the Code field for the various Destination Unreachable messages. Code = 0 No route matching the destination was found in the routing table. Code = 1 The communication with the destination is prohibited by administrative policy. This is typically sent when the packet is discarded by a firewall. Code = 2 The address is beyond the scope of the source address. Code = 3 The destination address is unreachable. This is typically sent because of an inability to resolve the destination's link layer address. Code = 4 The destination port was unreachable. This is typically sent when an IPv6 packet containing a UDP message arrived at the destination but there were no applications listening on the destination UDP port. Packet Too Big An ICMPv6 Packet Too Big message is sent when the packet cannot be forwarded because the link MTU on the forwarding link is smaller than the size of the IPv6 packet. In the Packet Too Big message, the Type field is set to 2 and the Code field is set to 0. After the Checksum field is the 32-bit MTU field that stores the link MTU for the link on which the packet was being forwarded. Next is the portion of the discarded packet that makes the entire IPv6 packet containing the ICMPv6 message no larger than the maximum length of 1280 bytes. The Packet Too Big message is used for the IPv6 Path MTU Discovery process. Time Exceeded An ICMPv6 Time Exceeded message is typically sent by a router when the Hop Limit field in the IPv6 header is zero, either upon receipt or after decrementing its value during the forwarding process. In the Time Exceeded message, the Type field is set to 3 and the Code field is set to either 0 (when the Hop Limit field in the IPv6 header becomes 0) or 1 (when the fragmentation reassembly time of the destination host is exceeded). After the Checksum field is the 32-bit Unused field and the portion of the discarded packet that makes the entire IPv6 packet containing the ICMPv6 message no larger than 1280 bytes. The receipt of Time Exceeded messages for Code=0 indicates that either the Hop Limit of outgoing packets is not large enough to reach the destination or that a routing loop exists. Parameter Problem An ICMPv6 Parameter Problem message is either sent by a router or by the destination. This occurs when an error is encountered in either the IPv6 header or an extension header, preventing IPv6 from performing further processing. In the Parameter Problem message, the Type field is set to 4 and the Code field is a value in the range of 0 through 2. After the Checksum field is the 32-bit Pointer field that indicates the byte offset in the offending IPv6 packet where the error was encountered. After the Pointer field is the portion of the discarded packet that makes the entire ICMPv6 message no larger than 1280 bytes. The Pointer field value is set to the correct offset even when the location of the error is not included in the portion of the discarded packet. Following are shown the Code field values for Parameter Problem messages. Code = 0 An error in a field within the IPv6 header or an extension header was encountered. Code = 1 An unrecognized Next Header field value was encountered. This is equivalent to the IPv4 Destination Unreachable-Protocol Unreachable message. Code = 2 An unrecognized IPv6 option was encountered. Echo Request An ICMPv6 Echo Request message is sent to a destination to solicit an immediate Echo Reply message. Figure shows the ICMPv6 Echo Request message In the Echo Request message, the Type field is set to 128 and the Code field is set to 0. After the Checksum field are the 16-bit Identifier and Sequence Number fields. The Identifier and Sequence Number fields are set by the sending host and used to match an incoming Echo Reply message with its corresponding Echo Request. The Data field is zero or more bytes of optional data that is also set by the sending host. Echo Reply An ICMPv6 Echo Reply message is sent in response to the receipt of an ICMPv6 Echo Request message. Figure shows the ICMPv6 Echo Reply In the Echo Reply message, the Type field is set to 129 and the Code field is set to 0. After the Checksum field are the 16-bit Identifier and Sequence Number fields. The Identifier, Sequence Number, and Data fields are set with the same values as those in the Echo Request message that initially prompted the Echo Reply. Path MTU Discovery The path MTU is the minimum link MTU of all links on a path between a source and a destination. To discover the path MTU, the sending node uses the receipt of ICMP Packet Too Big messages. The path MTU is discovered through the following process: 1. The sending node assumes that the path MTU is the link MTU of the interface on which the traffic is being forwarded. 2. The sending node sends IP datagrams at the path MTU size. 3. If a router on the path is unable to forward the packet over a link with a link MTU that is smaller than the size of the packet, it discards the IPv6 packet and sends an ICMP Packet Too Big message back to the sending node. The ICMP Packet Too Big message contains the link MTU of the link on which the forwarding failed. 4. The sending node sets the path MTU for packets being sent to the destination to the value of the MTU field in the ICMPv6 Packet Too Big message. The sending node starts again at step 2 and repeats steps 2 through 4 for as many times as are necessary to discover the path MTU. The path MTU is determined when either no additional ICMPv6 Packet Too Big messages are received or an acknowledgment is received from the destination. In RFC 1981, it is recommended that IPv6 nodes support path MTU discovery. Those that do not must use the minimum link MTU of 1280 bytes as the path MTU.
MULTICAST LISTENER DISCOVERY Multicast Listener Discovery (MLD) is the IPv6 equivalent of Internet Group Management Protocol version 2 (IGMPv2) for IPv4. MLD is a set of messages exchanged by routers and nodes, enabling routers to discover the set of multicast addresses for which there are listening nodes for each attached interface. Like IGMPv2, MLD only discovers the list of multicast addresses for which there is at least one listener, not the list of individual multicast listeners for each multicast address. Unlike IGMPv2, MLD uses ICMPv6 messages instead of defining its own message structure. All MLD messages are ICMPv6 messages types 130, 131, and 132. The three types of MLD messages are: 1. Multicast Listener Query 2. Multicast Listener Report 3. Multicast Listener Done An MLD message packet consists of an IPv6 header, a Hop-by-Hop Options extension header, and the MLD message. The Hop-by-Hop Options extension header contains the IPv6 Router Alert Option. It is used to ensure that routers process MLD messages sent to multicast addresses on which the router is not listening. Multicast Listener Query It is used by a router to query an attached link for listening hosts. In the IPv6 header, the source address is the link-local address of the interface on which the query is being sent. The Hop Limit field is set to 1. For the General Query, the destination address is the link-local scope all-nodes multicast address (FF02::1). For the Multicast-Address-Specific Query, the destination address is the specific multicast address being queried. In the MLD Multicast Listener Query message, the Type field is set to 130 and the Code field is set to 0. After the Checksum field are the 16-bit Maximum Response Delay and Reserved fields. The Maximum Response Delay is the maximum amount of time in milliseconds within which a multicast group member must report its membership using an MLD Multicast Listener Report message. In the General Query, the Multicast Address field is set to the unspecified address (::). In the Multicast-Address-Specific Query, the Multicast Address field is set to the specific multicast address that is being queried. Multicast Listener Report It is used by a listening node to either report its interest in receiving multicast traffic at a specific multicast address or respond to an MLD General or Multicast-Address-Specific Query message. In the IPv6 header, the source address is the link-local address of the interface on which the report is being sent. The Hop Limit field is set to 1 and the destination address is the specific multicast address being reported. In the MLD Multicast Listener Report message, the Type field is set to 131 and the Code field is set to 0. The Maximum Response Delay field is not used in a Multicast Listener Report message and is set to 0. The Multicast Address field is set to the specific multicast address that is being reported. Multicast Listener Done It is used by a listening node to inform local routers that the host is the last host on the subnet and is no longer listening for a specific multicast address. In the IPv6 header, the source address is the link-local address of the interface on which the report is being sent. The Hop Limit field is set to 1 and the destination address is the link-local scope all-routers multicast address (FF02::2). In the MLD Multicast Listener Done message, the Type field is set to 132 and the Code field is set to 0. The Maximum Response Delay field is not used in a Multicast Listener Done message and is set to 0. The Multicast Address field is set to the specific multicast address for which the sending node is informing local routers that it is no longer as listener.
NEIGHBOR DISCOVERY IPv6 Neighbor Discovery (ND) is a set of messages and processes that determine relationships between neighboring nodes. ND replaces ARP, ND is used by: · Hosts to discover neighboring routers. · Hosts to discover addresses, address prefixes, and other configuration parameters. · Nodes to both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed. · Nodes to determine whether a neighbor is still reachable. · Routers to advertise their presence, host configuration parameters, and on-link prefixes. · Routers to inform hosts of a better next-hop address to forward packets for a specific destination. Neighbor Discovery Message Format Like Multicast Listener Discovery (MLD) messages, ND messages use the ICMPv6 message structure and ICMPv6 types 133 through 137. ND messages consist of an ND message header, composed of an ICMPv6 header and ND message-specific data, and zero or more ND options. All of the functions of IPv6 ND are performed with the following messages: · Router Solicitation · Router Advertisement · Neighbor Solicitation · Neighbor Advertisement · Redirect Router Solicitation The Router Solicitation message is sent by IPv6 hosts to discover IPv6 routers present on the link. A host sends a multicast Router Solicitation to prompt IPv6 routers to respond immediately, rather than waiting for a periodic Router Advertisement message. For example, assuming the local link is Ethernet, in the Ethernet header of the Router Solicitation message: · The Source Address field is set to the MAC address of the sending network adapter. · The Destination Address field is set to 33-33-00-00-00-02. In the IPv6 header of the Router Solicitation message: · The Source Address field is set to either a link-local IPv6 address assigned to the sending interface or the IPv6 unspecified address (::). · The Destination Address field is set to the link-local scope all-routers multicast address (FF02::2). · The Hop Limit field is set to 255. The format of the Router Solicitation message is shown in Figure The fields in the Router Solicitation message are: Checksum – The value of this field is the ICMPv6 checksum. Reserved – A 32-bit field reserved for future use and set to 0. Source Link-Layer Address option – The ND Source Link-Layer Address option contains the link-layer address of the sender. For an Ethernet node, the Source Link-Layer Address option contains the Ethernet MAC address of the sending host. The address in the Source Link-Layer Address option is used by the receiving router to determine the unicast MAC address of the host to which the corresponding unicast Router Advertisement is sent. Router Advertisement IPv6 routers send the Router Advertisement message either periodically or in response to the receipt of a Router Solicitation message. It contains the information required by hosts to determine the link prefixes, the link MTU, whether or not to use address autoconfiguration, and the duration for which addresses created through address autoconfiguration are both valid and preferred. For example, assuming the local link is Ethernet, in the Ethernet header of the Router Advertisement message: · The Source Address field is set to the MAC address of the sending network adapter. · The Destination Address field is set to either 33-33-00-00-00-01 for a periodic Router Advertisement or the unicast MAC address of the host that sent a Router Solicitation. In the IPv6 header of the Router Advertisement message: · The Source Address field is set to the link-local address assigned to the sending interface. · The Destination Address field is set to either the all-nodes link-local multicast address (FF02::1) or the unicast IPv6 address of the host that sent the Router Solicitation message. · The Hop Limit field is set to 255. The fields in the Router Advertisement message are: Type – The value of this field is 134. Code – The value of this field is 0. Checksum – The value of this field is the ICMPv6 checksum. Cur Hop Limit – Indicates the default value of the Hop Count field in the IPv6 header for packets sent by hosts that receive this Router Advertisement message. The size of this field is 8 bits. A Cur Hop Limit of 0 indicates that the default value of the Hop Count field is not specified by the router. Managed Address Configuration flag – Indicates, when set to 1, that hosts receiving this Router Advertisement message must use a stateful address configuration protocol (for example, DHCPv6) to obtain addresses in addition to the addresses derived from stateless address autoconfiguration. The size of this field is 1 bit. Router Lifetime – Indicates the lifetime (in seconds) of the router as the default. The size of this field is 16 bits. The maximum Router Lifetime value is 65,535 seconds (about 18.2 hours). A Router Lifetime of 0 indicates that the router cannot be considered a default router. Reachable Time– Indicates the amount of time (in milliseconds) that a node can consider a neighboring node reachable after receiving a reachability confirmation. The size of this field is 32 bits. A Reachable Time value of 0 indicates that the router does not specify the Reachable Time. Retrans Timer – Indicates the amount of time (in milliseconds) between retransmissions of Neighbor Solicitation messages. The size of this field is 32 bits. Retrans Timer is used during Neighbor Unreachability Detection. A Retrans Timer value of 0 indicates that the router does not specify the Retrans Timer. Source Link-Layer Address option – The Source Link-Layer Address option contains the link-layer address of the interface on which the Neighbor Solicitation message was sent. This option can be omitted when the router is load balancing across multiple link-layer addresses. MTU option – The MTU option contains the MTU of the link. Prefix Information options – The prefix information options contain the on-link prefixes that are used for address autoconfiguration. The local-link prefix is never sent as a prefix information option. Neighbor Solicitation The Neighbor Solicitation message is sent by IPv6 hosts to discover the link-layer address of an on-link IPv6 node. It includes the link-layer address of the sender. Typical Neighbor Solicitations are multicast for address resolution and unicast when the reachability of a neighboring node is being verified. For example, assuming the local link is Ethernet, in the Ethernet header of the Neighbor Solicitation message: · The Source Address field is set to the MAC address of the sending network adapter. · For a multicast Neighbor Solicitation, the Destination Address field is set to the Ethernet MAC address that corresponds to the solicited-node address of the target. For a unicast Neighbor Solicitation, the Destination Address field is set to the unicast MAC address of the neighbor. In the IPv6 header of the Neighbor Solicitation message: · The Source Address field is set to either an IPv6 address assigned to the sending interface or, during duplicate address detection, the unspecified address (::). · For a multicast Neighbor Solicitation, the Destination Address field is set to the solicited-node multicast address of the target. For a unicast Neighbor Solicitation, the Destination Address field is set to the unicast or anycast address of the target. · The Hop Limit field is set to 255. The format of the Neighbor Solicitation message is shown in Figure The fields in the Neighbor Solicitation message are: Target Address – Indicates the IP address of the target. The size of this field is 128 bits. Source Link-Layer Address option – The Source Link-Layer Address option contains the link-layer address of the sender. During duplicate address detection, when the source IPv6 address is the unspecified address (::), the Source Link-Layer Address option is not included. Neighbor Advertisement The Neighbor Advertisement message is sent by an IPv6 node in response to the receipt of a Neighbor Solicitation message. An IPv6 node also sends unsolicited Neighbor Advertisements to inform neighboring nodes of changes in link-layer addresses. The Neighbor Advertisement contains information required by nodes to determine the type of Neighbor Advertisement message, the link-layer address of the sender, and the sender's role on the network. For example, assuming the local link is Ethernet, in the Ethernet header of the Neighbor Advertisement message: · The Source Address field is set to the MAC address of the sending network adapter. · The Destination Address field is set, for a solicited Neighbor Advertisement, to the unicast MAC address of the initial Neighbor Solicitation sender. For an unsolicited Neighbor Advertisement, the Destination Address field is set to 33-33-00-00-00-01, the Ethernet MAC address corresponding to the link-local scope all-nodes multicast address. In the IPv6 header of the Neighbor Advertisement message: · The Source Address field is set to the link-local address assigned to the sending interface. · The Destination Address field is set, for a solicited Neighbor Advertisement, to the unicast IP address of the sender of the initial Neighbor Solicitation. For an unsolicited Neighbor Advertisement, the Destination Address field is set to the link-local scope all-nodes multicast address (FF02::1). · The Hop Limit field is set to 255. The format of the Neighbor Advertisement message is shown in Figure The fields in the Neighbor Advertisement message are: Router flag – Indicates the role of the sender of the Neighbor Advertisement message. The size of this field is 1 bit. The Router flag is set to 1 when the sender is a router and 0 when the sender is not. The Router flag is used by Neighbor Unreachability Detection to determine when a router changes to a host. Solicited flag – Indicates, when set to 1, that the Neighbor Advertisement message was sent in response to a Neighbor Solicitation message. The size of this field is 1 bit. The Solicited flag is used as a reachability confirmation during Neighbor Unreachability Detection. The Solicited flag is set to 0 for both multicast Neighbor Advertisements and unsolicited unicast Neighbor Advertisements. Override flag – Indicates, when set to 1, that the link-layer address in the included Target Link-Layer Address option should override the link-layer address in the existing neighbor cache entry. The size of this field is 1 bit. If the Override flag is set to 0, the enclosed link-layer address only updates a neighbor cache entry if the link-layer address is not known. The Override flag is set to 0 for solicited anycast address and proxied advertisements. The Override flag is set to 1 in other solicited and unsolicited advertisements. For more information on the neighbor cache Target Address – Indicates the address being advertised. The size of this field is 128 bits. Target Link-Layer Address option – The Target Link-Layer Address option contains the link-layer address of the target, which is the sender of the Neighbor Advertisement. Redirect The Redirect message is sent by an IPv6 router to inform an originating host of a better first-hop address for a specific destination. Redirect messages are only sent by routers for unicast traffic, are only unicast to originating hosts, and are only processed by hosts. For example, assuming the local link is Ethernet, in the Ethernet header of the Redirect message: · The Source Address field is set to the MAC address of the sending network adapter. · The Destination Address field is set to the unicast MAC address of the originating sender. In the IPv6 header of the Redirect message: · The Source Address field is set to the link-local address that is assigned to the sending interface. · The Destination Address field is set to the unicast IP address of the originating host. · The Hop Limit field is set to 255. The redirect use one special header option- Redirected Header option – The Redirected Header option includes a portion of the original packet that caused the Redirect message to be sent so that the entire IPv6 packet containing the Redirect message is no larger than 1280 bytes. Neighbor Discovery Processes The ND protocol provides message exchanges for the following processes: · Address resolution (including duplicate address detection) · Router discovery (includes prefix and parameter discovery) · Neighbor unreachability detection · Redirect function Address Resolution The address resolution process for IPv6 nodes consists of an exchange of Neighbor Solicitation and Neighbor Advertisement messages to resolve the link-layer address of the on-link next-hop address for a given destination. The sending host sends a multicast Neighbor Solicitation message on the appropriate interface. The multicast address of the Neighbor Solicitation message is the solicited-node multicast address derived from the target IP address. The Neighbor Solicitation message includes the link-layer address of the sending host in the Source Link-Layer Address option. When the target host receives the Neighbor Solicitation message, it updates its own neighbor cache based on the source address of the Neighbor Solicitation message and the link-layer address in the Source Link-Layer Address option. Next, the target node sends a unicast Neighbor Advertisement to the Neighbor Solicitation sender. The Neighbor Advertisement includes the Target Link-Layer Address option. After receiving the Neighbor Advertisement from the target, the sending host updates its neighbor cache with an entry for the target based upon the information in the Target Link-Layer Address option. At this point, unicast IPv6 traffic between the sending host and the target of the Neighbor Solicitation can be sent. Duplicate Address Detection IPv4 nodes use ARP Request messages and a method called gratuitous ARP to detect a duplicate IP address on the local link. Similarly, IPv6 nodes use the Neighbor Solicitation message to detect duplicate address use on the local link. In IPv6 duplicate address detection, the Target Address field in the Neighbor Solicitation message is set to the IPv6 address for which duplication is being detected. Duplicate address detection differs from address resolution in these ways: · In the duplicate address detection Neighbor Solicitation message, the Source Address field in the IPv6 header is set to the unspecified address (::). The address being queried for duplication cannot be used until it is determined that there are no duplicates. · In the Neighbor Advertisement reply to a duplicate address detection Neighbor Solicitation message, the Destination Address in the IP header is set to the link-local scope all-nodes multicast address (FF02::1). The Solicited flag in the Neighbor Advertisement message is set to 0. Because the sender of the duplicate address detection Neighbor Solicitation message is not using the desired IP address, it cannot receive unicast Neighbor Advertisements. Therefore, the Neighbor Advertisement is multicast. Upon receipt of the multicast Neighbor Advertisement with the Target Address field set to the IP address for which duplication is being detected, the node disables the use of the duplicate IP address on the interface. If the node does not receive a Neighbor Advertisement that defends the use of the IPv6 address, it initializes the address on the interface. Router Discovery Router discovery is the process through which nodes attempt to discover the set of routers on the local link. IPv6 has a Router Lifetime field in the Router Advertisement message. This field indicates the length of time that the router can be considered a default router. However, if the current default router becomes unavailable, the condition is detected through neighbor unreachability detection instead of the Router Lifetime field in the Router Advertisement message. Because neighbor unreachability detection determines that the router is no longer reachable, a new router is chosen immediately from the default router list. In addition to configuring a default router, IPv6 router discovery also configures the following: · The default setting for the Hop Limit field in the IPv6 header. · A determination of whether the node should use a stateful address protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6), for addresses and other configuration parameters. · The timers used in reachability detection and the retransmission of Neighbor Solicitations. · The list of network prefixes defined for the link. Each network prefix contains both the IPv6 network prefix and its valid and preferred lifetimes. If indicated, a network prefix combined with the interface identifier creates a stateless IP address configuration for the receiving interface. A network prefix also defines the range of addresses for nodes on the local link. · The MTU of the local link. The IPv6 router discovery processes are the following: · IPv6 routers periodically send a Router Advertisement message on the local link advertising their existence as routers. They also provide configuration parameters such as default hop limit, MTU, and prefixes. · Active IPv6 hosts on the local link receive the Router Advertisement messages and use the contents to maintain the default router list, the prefix list, and other configuration parameters. · A host that is starting sends a Router Solicitation message to the link-local scope all-routers multicast address (FF02::2). Upon receipt of a Router Solicitation message, all routers on the local link send a unicast Router Advertisement message to the node that sent the Router Solicitation. The node receives the Router Advertisement messages and uses their contents to build the default router and prefix lists and set other configuration parameters. The number of Router Solicitations sent before abandoning the router discovery process is set by a configurable variable. RFC 2461 uses the variable name of MAX_RTR_SOLICITATIONS and recommends a value of 3. Neighbor Unreachability Detection Reachability is defined as the ability to correctly send an IPv6 packet to a neighboring node and have that packet be successfully received and processed by the IPv6 layer of the neighbor. For a node that is sending a packet to a router, the packet is delivered to the router's IPv6 layer and then forwarded to the next hop. For a node that is sending a packet to a neighboring node, the packet is delivered to the node's IPv6 layer. It is important to note that the definition of reachability does not require delivery to a remote node across a router—only to the neighboring router. When a neighbor becomes unreachable, IPv6 detects this condition and attempts to correct it. To determine whether a neighbor is reachable, IPv6 relies on either upper layer protocols that indicate communication progress or receipt of a Neighbor Advertisement message that has been sent in response to a unicast Neighbor Solicitation message. In the case of TCP traffic, communication progress is indicated when new data or acknowledgement segments for sent data are received. For UDP traffic, a progress indication might not be present. In this case, the node sends unicast Neighbor Solicitation messages to the next-hop neighbor to monitor its ongoing reachability. Only the receipt of a solicited Neighbor Advertisement is considered proof of reachability. A solicited Neighbor Advertisement, which has its Solicited flag set to 1, is only sent in response to a Neighbor Solicitation. Unsolicited Neighbor Advertisement or Router Advertisement messages are not considered proof of reachability. Redirect Function Routers use the redirect function to inform originating hosts of a better first-hop neighbor to which traffic should be forwarded for a specific destination. There are two instances where redirect is used: 1. A router informs an originating host of the IP address of a router available on the local link that is "closer" to the destination. "Closer" is routing metric function used to reach the destination network segment. This condition can occur when there are multiple routers on a network segment and the originating host chooses a default router and it is not the best one to use to reach the destination. 2. A router informs an originating host that the destination is a neighbor (it is on the same link as the originating host). This condition can occur when the prefix list of a host does not include the prefix of the destination. Because the destination does not match a prefix in the list, the originating host forwards the packet to its default router. The following steps occur in the IPv6 redirect process: 1. The originating host forwards a unicast packet to its default router. 2. The router processes the packet and notes that the address of the originating host is a neighbor. Additionally, it notes that the addresses of both the originating host and the next-hop are on the same link. 3. The router forwards the packet to the appropriate next-hop address. 4. The router sends the originating host a Redirect message. In the Target Address field of the Redirect message is the next-hop address of the node to which the originating host should send packets addressed to the destination. For packets redirected to a router, the Target Address field is set to the link-local address of the router. For packets redirected to a host, the Target Address field is set to the destination address of the packet originally sent. The Redirect message includes the Redirected Header option. It might also include the Target Link-Layer Address option. 5. Upon receipt of the Redirect message, the originating host updates the destination address entry in the destination cache with the address in the Target Address field. If the Target Link-Layer Address option is included in the Redirect message, its contents are used to create or update the corresponding neighbor cache entry. Redirect messages are only sent by the first router in the path between the originating host and the destination. Hosts never send Redirect messages and routers never update routing tables based on the receipt of a Redirect message. Host Sending Algorithm The process by which an IPv6 host sends an IPv6 packet uses a combination of the local host's structures and the ND protocol. An IPv6 host uses the following algorithm when sending a packet to an arbitrary destination: 1. Check the destination cache for an entry matching the destination address. 2. If an entry matching the destination address is found in the destination cache, obtain the next-hop address in the destination cache entry. Go to step 4. If an entry matching the destination address is not found in the destination cache, determine if the destination address matches a prefix in the prefix list. If the destination address matches a prefix in the prefix list, the next-hop address is set to the destination address. Go to step 3. If the destination address does not match a prefix in the prefix list, the next-hop address is set to the address of the current default router. Go to Step 3. If there is no default router (and there are no routers in the default router list), the next-hop address is set to the destination address. 3. Update the neighbor cache. 4. Check the neighbor cache for an entry matching the next-hop address. 5. If an entry matching the next-hop address is found in the neighbor cache, obtain the link-layer address. If an entry matching the next-hop address is not found in the neighbor cache, use address resolution to obtain the link-layer address for the next-hop address. Send the packet using the link-layer address of the neighbor cache entry.
REFERENCES · IPv6 Working Group Web site http://www.ietf.org/html.charters/ipngwg-charter.html. This site contains links to the current set of RFCs and Internet drafts that describe the IPv6 protocol suite. · The Next Generation Transition (ngtrans) Working Group Web site http://www.ietf.org/html.charters/ngtrans-charter.html. This site contains links to the current set of RFCs and Internet drafts that describe various deployment tools and Internet transition strategies. · http://playground.sun.com/IPng · RFC 2460: Internet Protocol Version 6 (IPv6) specification · RFC 1887: An Architecture for IPv6 Unicast Address Allocation · RFC 1924: A Compact Representation of IPv6 Addresses · RFC 2373: IP Version 6 Addressing Architecture · RFC 2461: Neighbor Discovery for IP Version 6 (IPv6) · RFC 2463: Internet Control Message Protocol (ICMPv6) for Ipv6
TERMINOLOGY node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. [See Note below]. host - any node that is not a router. [See Note below]. upper layer - a protocol layer immediately above IPv6. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. neighbors - nodes attached to the same link. interface - a node's attachment to a link. address - an IPv6-layer identifier for an interface or a set of interfaces. packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. path MTU - the minimum link MTU of all the links in a path between a source node and a destination node.