| The new IP version was improved in many important points, but this protocol has been used in the real world only to a limited extent. One of the reasons is that existing applications cannot run directly on top of IPv6. The most important changes from IPv4 are the following: Extended address size: Instead of 32 bits, each IPv6 address contains 128 bits, enabling several hierarchical levels and addressing a much larger number of nodes. In addition, the IPv6 address of each node can be configured automatically. The support of multicast routing has been improved. Moreover, a new address type, the anycast address, was defined, which allows you to send a packet to an arbitrary node from within a group. Simplified header format: Some of the IPv4 packet-header fields are no longer supported, or are now optional, to reduce the cost involved in processing IPv6 packets. Extension headers: The way IPv6 encodes information is completely different from that in IPv4, enabling more efficient forwarding, less strict limitations with regard to the length of options, and more flexibility for new, future packet options. Flow labeling: IPv6 is able to mark packets that belong to a specific stream. This allows the sender to request special handling of these packets, enabling a much better support of service qualities, such as priority handling or real-time services. Authentication and data protection: IPv6 specifies extensions to support authentication, integrity, and confidentiality of data.
23.2.1 Addressing The address space, extended from 232 (IPv4) to 2128 (IPv6) addresses, requires a new address notation. The preferred and abbreviated notation is the hexadecimal notation (e.g., FEDC:BA98:7654:3210:FEDC:BA98:7654:3120). Each group (i.e., one block between two colons, or between the beginning/end and a colon) represents 16 bits. Leading zeros can be omitted, so one group can consist of one to four hexadecimal numbers. In addition, it is assumed that many consecutive blocks consist of zeros, so a compressed notation was introduced: Each address may contain at most one occurrence of two consecutive colons. In between, as many zeros as necessary are used to reach the full length of an address. The following examples show this notation (the meaning of each of these addresses will be discussed further below): Alternatively, addresses can be represented in mixed form, composed of the new hexadecimal notation and the decimal IPv4 notation. The format is then x:x:x:x:x:x:d.d.d.d, where x represents the hexadecimal groups of IPv6 and d stands for the decimal IPv4 convention. One example would be 0:0:0:0:0:FFFF:129.13.64.5 (or ::FFFF:129.13.64.5 in the abbreviated form). How useful this is becomes obvious if you think of embedding IPv4 in IPv6. As does IPv4, IPv6 supports unicast and multicast addresses. A new form of communication introduced in IPv6 is anycast. Anycast is a mixture of unicast and multicast: A packet is sent to one computer in a multicast group, where the network itself decides which computer this is. The "broadcast" address of IPv4 (255.255.255.255) doesn't exist in IPv6. This functionality, which was used mainly by ARP (Address Resolution Protocol) to resolve IP addresses, is achieved by use of multicast addresses in IPv6. ARP is no longer supported in IPv6. It was replaced by Neighbor Discovery, which was integrated into ICMPv6. The structuring of the IPv6 address space is implemented by prefixes. A prefix is a sort of logical interconnection of a network, similarly to the subnetworks known from IPv4. A prefix virtually groups all IPv6 nodes with addresses beginning in the same way. For example, almost all IPv4 addresses of the Karlsruhe University begin with 129.13, using the notation 129.13.0.0/16. Subnetworks in IPv6 are denoted accordingly. The number of leading bits denoting the network are written after the complete IPv6 address and a slash. For example, the University of Münster, Germany, has the 6bone prefix 3FFE:400:10::/48. Normally, the bits in an address not belonging to the prefix are set to null; however, stating a complete address denotes the IPv6 address of a computer connected to the subnetwork specified by the prefix. In this representation, it is important to note that the compressed notation is also extended to 128 bits, rather than to the prefix length. This means that 3::16/64 is the subnetwork with prefix 0003:0000:0000:0000 and not prefix 0003:0000:0000:0016. We can basically distinguish between multicast addresses and "other" addresses. Multicast addresses begin with eight ones (= FF:). All other addresses are unicast or anycast addresses, and which of the two is the case cannot be told from the address itself. The lower 64 bits of all (nonmulticast) addresses not beginning with the bit string 000 must have an interface identifier corresponding to the EUI-64 format; for Ethernet, this would be the MAC address of the network card. Like IPv4, IPv6 uses special addresses required for specific purposes: Unspecified (:: = 0:0:0:0:0:0:0:0) This address, entirely consisting of zeros, does not stand for a real address, but for the absence of it. It must be selected only for source addresses and is used, for example, to configure the address of a computer automatically. Loopback (::1) Similarly, the loopback address does not stand for an actual network address either; it is used by a computer to send packets to itself. For this reason, it is inadmissible to send packets with the source or destination address set to ::1 to other computers. In addition, it would not be meaningful to use this address for a network interface. IPv6-capable routers have to drop such packets. IPv4-compatible addresses (::d.d.d.d) To be able to dynamically tunnel IPv6 packets over an existing IPv4 infrastructure, special IPv4-compatible IPv6 unicast addresses are assigned to the computers involved. These IPv6 addresses contain the IPv4 address in the lower 32 bits of their address; the remaining bits are set to null. Embedded IPv4 addresses (::FFFF:d.d.d.d) On the IPv6 side, an embedded IPv4 address is assigned to all computers actually supporting IPv4 only, so that these computers can be addressed by IPv6 computers. This addressing type is also called IPv4 mapped IPv6 Address; it consists of 80 zeros, 16 ones, and finally the 32-bit IPv4 address. Local addresses (FE80::x:x:x:x, FEA0::x:x:x:x) Link-local addresses (FE80::x:x:x:x) A link-local address is uniquely allocated to an interface directly connected to the network. Its prefix is FE80::/64, and the remaining bits hold an EUI-64-compliant address. The link-local address can be used exclusively for this interface and in the connected network. It serves primarily for automatic address configuration, for neighbor discovery, and for networks without routers. Site-local addresses (FEA0::x:x:x:x) Site-local addresses are designed for networks that do not require a global prefix, which means that they are not reachable from the outside. The format for these addresses has an EUI-64-compliant address in the lower 64 bits, and a 16-bit wide subnetwork number between the prefix, FEA0::, and the EUI-64-compliant address. Routers may not transport packets with local source or destination addresses beyond the corresponding network.
23.2.2 IPv6 Packet Header The IPv6 packet header includes 40 bytes in total, as shown in Figure 23-1. It is interesting that an IPv6 packet header fewer less fields than a comparable IPv4 packet header, which includes twelve fields in its 20 bytes, excluding packet options. The slimmer packet header in IPv6 reduces the cost involved in handling IPv6 packets in routers. Figure 23-1. The IPv6 packet header. 
The Version field defines the version of the IP protocol used; it is set to Version = 0x06 for IPv6. The TOS (Type Of Service) field known from IPv4 is called Traffic Class in IPv6. It is used to identify different classes or priorities of IPv6 packets and is set to 0x00 by default. The semantics of this field corresponds to the TOS field: codepoints in the Differentiated Services architecture are equally mapped to the TOS and the Traffic Class fields. The Flow Label field can be used to mark a related stream of IPv6 packets. These packets are then treated accordingly in the routers on their way to the receiver. This means that we can support QoS for individual packet streams (e.g., to support real-time services in a network). RFC 2460 does not specify the semantics of this field in detail. The Payload Length field is 16 bits wide and specifies the length of a packet (in bytes), excluding the packet header. It takes packet-header extensions into account, if present. The Next Header field specifies the type of "data" following after the IPv6 packet header: This can be either a packet-header extension (see next section) or pure payload specified by the higher-layer transport protocol (e.g., TCP). In this case, the values of the Protocol field known from IPv4 are used. (See RFC 1700 [RePo94].) The TTL (Time To Live) field in the IPv4 packet header corresponds to the Hop Limit field in IPv6, which serves a similar purpose: Each IPv6 router decrements the Hop Limit field. Once it has reached the value 0, the IPv6 packet is dropped, and an ICMPv6 error message is returned to the sender. Finally, the IPv6 packet header includes two 128-bit fields for the sender (Source Address) and receiver (Destination Address) addresses. 23.2.3 Packet-Header Extensions IPv6 encodes optional information of the Internet layer in separate packet-header extensions, placed between the IPv6 packet header and the payload. The set of different packet-header extensions used is designated by different Next-Header values. An IPv6 packet can have several extension headers, each determined by the Next Header field of the previous packet header or the previous packet-header extension. This is the reason why this field exists in each packet-header extension. Figure 23-2 shows how packet-header extensions are used. The length of each packet-header extension has to be a multiple of 8 bytes. Figure 23-2. Examples of using IPv6 packet-header extensions. 
Packet-header extensions are processed in the sequence of their occurrence and only in the destination host, except for the Hop-by-Hop packet-header extension. For this reason, the Hop-by-Hop packet-header extension must be at the first position, if present. A full IPv6 implementation has to include the following packet-header extensions: Hop-by-Hop Options, Destination Options, Routing, Fragment, Authentication Header, and Encapsulating Security Payload. Except for the last two, all of these packet-header extensions will be discussed below. Hop-by-Hop Options and Destination Options The Hop-by-Hop Options and Destination Options packet-header extensions hold optional information relevant for the nodes on the way to the receiver. The Hop-by-Hop Options are processed in each IPv6 router along the delivery path; the Destination Options are processed in the receiver of an IPv6 packet. Both header extensions have the same format; they differ only in the Next Header field of the previous packet-header extension. The following values are defined for this Next Header field: Both packet-header extensions have the following format:  The length of these packet header extensions can be variable, so Hdr Ext Len specifies the length of a packet-header extension, in 8-byte blocks (excluding the first 8 bytes). The Options block includes one or several encoded option(s). The original specification of IPv6 (RFC 2460) defines two options used essentially for data padding to align subsequent packet-header extensions accordingly. One of these options, PAD1, corresponds to a sequence of eight zeros (i.e., 0x00); the second option (PADN) pads to an arbitrary length (in bytes) and is composed of three : 0x01 to designate PADN, the length of padded data (1 byte; includes the length without the first two bytes), and the subsequent "padding data." Routing The Routing packet-header extension is used to specify a number of nodes (routers) that a packet has to visit along the way to its final destination. This corresponds to the Source Routing option in IPv4. The Routing packet header extension is identified by the Next Header value 0x2B (in the previous packet-header extension) and has the following format:  Again, the Hdr Ext Len field specifies the length of this packet-header extension in 8-byte blocks, excluding the first 8 bytes. Routing Type specifies the variant of the Routing packet-header extension. RFC 2460 standardizes only Loose Source Routing (known from IPv4) to Routing Type = 0x00. The Segments Left parameter holds the number of explicitly defined nodes a packet still has to visit. The last field holds type-specific information: the addresses of nodes left along the path (in addition to four reserved bytes, in the case of Loose Source Routing). How an IPv6 packet that includes the Routing packet-header extension is forwarded can best be explained by a simple practical example. Assume that an IPv6 packet should be transported from the sender, S, over nodes R1 and R2 to the receiver, R. These nodes are addressed directly in the IPv6 packet header, and the Routing packet-header extension specifies the previous and subsequent destinations, including the end system. Each addressed node replaces the IPv6 receiver address by an entry for the next hop, and then replaces this entry by its IPv6 address. In this example, the IPv6 packet would be composed as follows in the respective stations: Node S: Source = S, Destination = R1, Segments Left = 2, Address[1] = R2, Address[2] = R. Node R1: Source = S, Destination = R2, Segments Left = 1, Address[1] = R1, Address[2] = R. Node R2: Source = S, Destination = R, Segments Left = 0, Address[1] = R1, Address[2] = R2. Node R: Source = S, Destination = R, Segments Left = 0, Address[1] = R1, Address[2] = R2.
Fragment The Fragment packet-header extension is required for sending an IPv6 packet to a receiver when its size is larger than the maximum packet size (Maximum Transfer Unit MTU) of a connection on the route used. In contrast to IPv4, an IPv6 packet is fragmented by the sender only, never in the routers it traverses along the way. The Fragment packet-header extension is specified by the Next Header value 0x2C and looks like this:  Each of the two reserved fields has to be initialized to null. The 13-bit Fragment Offset specifies the offset (in 8-byte units) of the data following this packet-header extension in relation to the fragmentable part of the original packet. The M bit specifies whether more fragments are to follow (M = 1) or this is the last fragment of an IPv6 packet (M = 0). This corresponds to the segmenting and reassembling in IPv4. The Identification field identifies packets belonging together by a unique number. This number must be assigned only once for each sender/receiver relationship during a packet's lifetime, to avoid confusion with other fragmented IPv6 packets. The details are left to the implementation. A simple example will help us better understand how fragmenting in IPv6 works. Assume that an IPv6 packet consists of a nonfragmentable part and a fragmentable part. The nonfragmentable part includes the IPv6 packet header and all packet-header extensions that will have to be processed by each node along the route (i.e., all extensions but the Routing header extension). The fragmentable part of this IPv6 packet is decomposed into fragments. Each of these fragments, except the last fragment (bit M = 0), is a multiple of 8 bytes. The resulting fragments will then look like this:  Sequence of Packet-Header Extensions In general, an IPv6-capable node has to be able to process packet-header extensions in any arbitrary sequence, even in case of multiple occurrence. One exception is the packet-header extension of the type Hop-by-Hop Options. However, RFC 2460 recommends the following sequence: IPv6 packet header Hop-by-Hop Options Routing packet header extension Fragment packet header extension Destination Options Authentication Header Encapsulating Security Payload Payload/packet headers of higher layers.
In addition, the standard requires that none of the packet-header extensions, except Destination Options, occur more than once. The last two packet-header extensions, Authentication Header and Encapsulating Security Payload Header, are also packet-header extensions, but they serve for seamless integration of IPSec in IPv6. For this reason, we will not discuss them any further here. A detailed description of IPSec is included in the following standardized RFCs: RFC 2401: Architecture of IPSec RFC 2402: Authentication Header RFC 2406: Encapsulating Security Payload
|
