IPv6 Header and Addressing Essentials

IPv6 Header and Addressing Essentials
CYBERNET
Technical Paper
Fahad Ali Khan Senior Network Engineer Network Engineering Department
CYBERNET
Cyber Internet Services Pvt. Ltd A904- Lakson Square Building # 3 Sarwar Shaheed road Karachi, Pakistan 111-56-56-56 www.cyber.net.pk www6.cyber.net.pk
1 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
Contents
EXECUTIVE SUMMARY .................................................................................................. 3 IPV6 HEADER VS IPV4 HEADER ................................................................................... 3 IPV4 HEADER .................................................................................................................. 3 FILEDS REMOVED FROM IPV4 HEADER...................................................................... 5 IPV6 HEADER .................................................................................................................. 6 IPV6 EXTENSION HEADER ............................................................................................ 8 IPV6 ADDRESSING ....................................................................................................... 10 REPRESENTATION OF IPV6 ADDRESSES............................................................. 10 IPV6 PREFIX NOTATION........................................................................................... 10 IPV6 ADDRESSING TYPES......................................................................................... 102 IPV6 UNICAST ADDRESS............................................................................................. 13 LINK LOCAL ADDRESS............................................................................................ 15 UNIQUE LOCAL UNICAST ADDRESS ..................................................................... 16 GLOBAL UNICAST ADDRESS ................................................................................. 16 IPV6 UNICAST ADDRESS ALLOCATION .................................................................... 18 IPV6 PREFIX ALLOCATION RULES............................................................................. 19 ANYCAST ADDRESS .................................................................................................... 20 IPV6 MULTICAST ADDRESS ........................................................................................ 22 IPV6 MULTICAST ADDRESS ALLOCATION ............................................................... 23 APPENDIX-A ................................................................................................................. 24 APPENDIX-B ................................................................................................................. 25 REFERENCE ................................................................................................................. 26
CYBERNET
Executive Summary
The structure of the actual IP packet header was quite modified in IPv6. These changes reflect some of the lessons learned from years of operating IPv4, and they have a significant impact on the protocol operation. To fulfill the need of tomorrow IPv6 address is designed to128bits and it is good enough to cover more than every element in this universe or it can be compared to providing multiple IP addresses for every grain of the sand on the Planet. Designing large space address can cause other issue like more need for processing and memory in IPv6 Nodes, also its assignment and management will also lead Network Administrator to hard thinking about IPv6 deployment. But IPv6 developers have these thoughts were in their mind and they came with very good features in IPv6 headers and its addressing & deployment procedures which will not only limit the need of memory and processing overheads but also help administrator to easily adopt it in their existing networks without thinking of IP addressing renumbering and manual assignment to thousands of Hosts and Nodes.
IPv6 Header Vs IPv4 Header

The core of every protocol is naturally its datagram format. After several experimental implementations were created and some practical experience gained through to operation of the 6bone network, developers came with a revise and more improve set of specifications published in the end of 1998 in RFC 2460. Before exploring the header fields of IPv6, it is necessary to find out what are the motivations behind the choices made with respect to IPv4 header structure.
IPv4 Header
IPv4 packet has two components, the header that contains the layer 3 information and the payload that carries the data and the upper-layer protocol information. RFC 791 defines the following fields for the IPv4 packet header:
CYBERNET
Version (4 bits): It represents the version of the IP protocol. As the name suggest, the field is set to 4. Header Length (4 bits): It defines the length in octets of the packet header. Type of Service (ToS) (8 bits): This field carries information that enables routers to classify and forward packet in a differentiated manner. It is an important service identifier used in implementing Quality of Service (QoS). Total Length (16 bits): This field defines the length in octets of the entire packet, header plus payload. With 16 bits available in this field, the maximum length of an IPv4 packet is 65,535 octets. Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits): These three fields enable IPv4 networks to support packet fragmentation to negotiate forwarding over links supporting various maximum transmission units (MTUs). Fragmentation is done as needed by the routers along the path of the packet. Time To Live (8 bits): It is important to protect a network's resources from packets that loop due to routing problems. This field is used to count down the number of routers that switched the packet. The packet is discarded when the value of this field is 0.
CYBERNET
Protocol Number (8 bits): The Protocol Number lists the upper-layer protocol (TCP, UDP, ICMP, and so on) that is present in the packet payload. Header Checksum (16 bits): The integrity of the packet header is verified by comparing the computed checksum with the value listed in this field. Source IPv4 Address (32 bits): The IPv4 address of the node that sourced the packet. Destination IPv4 Address (32 bits): The IPv4 address of the packet destination node. Options (variable length): This field is meant as a place holder for the information relevant to proper handling of the data carried by the packet, information that is not represented in the other fields of the header. Because of this field, the IPv4 header has a variable length, justifying the need for the Header Length field. Padding (variable length): This field is used to align the variable-length Options field to the 32-bit boundary.
Fields removed from IPv4 Header

The relevancy of the highlighted fields in IPv4 Header format has been reevaluated in the process of developing IPv6 and it has been found that there is no more need of some fields in the new protocol version as they will not help much the future protocol. The main reasons for these removals are as follows: Header Length: The basic IPv4 header is only 20 bytes long but variable. However, the basic IPv6 header has a fixed length of 40 octets. The IPv4 header length indicates the packet's total length, including the Options field. When present, the Options field increases the length of the IPv4 header. Instead of the Options field, IPv6 uses the Extension field. The Extension field is handled differently from how IPv4 handles the Options field.
CYBERNET
Identification, Flags, and Fragment Offset: Fragmentation is handled differently in IPv6. It is no longer done by intermediate routers in the networks, but by the source node that originates the packet. Removing the Fragmentation field removes costly CPU processing at intermediate routers. The path MTU discovery (PMTUD) mechanism is used by every IPv6 node to avoid fragmentation. Header Checksum: Link-layer technologies (Layer 2) perform their own checksum and error control. The reliability of link-layer is now good and upper-layer protocols such TCP and UDP (Layer 4) also have their checksums. UDP checksum, which was optional in IPv4, is mandatory in IPv6. Therefore, the checksum at Layer 3 is redundant, so the Header Checksum field is unnecessary in IPv6 and suppresses the recomputation process each time a packet passes through a router. The CRC has been abandoned for two good reasons: First, frame consistency is checked in lower layers, so it is largely redundant. Second, CRC decelerates the datagram processing, every forwarding node decreases the datagram lifetime, so it changes the header and must recalculate the CRC.
Options and Padding: The Options field is radically changed in IPv6. The options are now handled by extension headers. The Padding field is also removed. The removal of Options and Padding headers simplifies the IP header. Thus, the basic IPv6 header has a fixed length of 40 octets, allowing less processing by routers along the delivery path compared to IPv4.
The other fields in the IPv4 header i.e. Version, Type of Service, Total Length, Time to Live, Protocol Number, Source IPv4 Address, and Destination IPv4 Address, either was not changed or was modified only slightly.
IPv6 Header
As defined in RFC 2460, Internet Protocol version 6 (IPv6) Specification, the basic IPv6 header consists of eight fields, in comparison with 12 fields in IPv4 (without the Options and Padding fields), for a total length of 40 octets. The basic IPv6 header might have one or many extension headers daisy chained following the 40 octets. The description of these eight fields of basic IPv6 header is as follows,
CYBERNET
Version (4 bits): It represents the version of the IP protocol. As the name suggest, the field is set to 6. Traffic Class (8 bits): This field replaces the "Type of Service" field in IPv4. It facilitates the realtime and other data services classification in the network. Sending nodes and forwarding routers can use it to identify and distinguish between different classes or priorities of IPv6 packets to handle them in different manner. RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," explains how the Traffic Class field in IPv6 can be used. RFC 2474 uses the term DS Field to refer to the "Type of Service" field in the IPv4 header, as well as to the Traffic Class field in the IPv6 header.
Flow Label (20 bits): This field identifies a flow and it is intended to enable the router to identify packets that should be treated in a similar way without the need for deep lookups within those packets. The specification for this header field is presented in RFC 3697. The field is set by the source and should not be changed by routers along the path to destination. The Flow Label together with the SA and DA can uniquely identify IPv6 flows. This ID can map in the main header traffic characteristics that are deeper in the packet, providing routers with the capability to appropriately handle packets without the need to look deep into them. The Flow Label field is unique to IPv6, but it is recognized to be a powerful tool and similar extensions are being proposed for IPv4. Applications are envisioned where the field is used just as a tag as well as more complex 7 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
ones that maintain label state on the nodes using a signaling protocol. The Flow Label can be used with differentiated services (DiffServ) as well as integrated services (IntServ) and Resource ReSerVation Protocol (RSVP2). Payload Length (16 bits): This field represents the payload's length. The payload is the remaining part of the packet following the IPv6 header. The extension headers are considered as the part of packet payload. Next Header (8 bits): This field expands the functionality of the Protocol Number in the IPv4 header. Its a pointer towards the information type immediately following the basic header. This can be an extension header or the upper-layer protocol in the payload. The possible values of next header can be find in Appendix-A Hop Limit (8 bits): This field defines the maximum number of hops (intermediate routers) that the IP packet can pass through. Each hop decreases this value by 1. As in IPv4, when this field contains the value 0, the packet is destroyed and an Internet Control Message Protocol for IPv6 (ICMPv6) Type 3 message (Time Exceeded) is sent to the source node. Source IPv6 Address (128 bits): The IPv6 address of the node that sourced the packet. Destination IPv6 Address (128 bits): The IPv6 address of the packet destination node.
IPv6 Extension Headers

Instead of placing optional fields to the end of datagram header, IPv6 designers chose a different approach i.e. extension headers. They are added after the IPv6 datagram only if needed, i.e. if it is necessary to fragment the datagram the fragmentation header is put into it. The number of extension headers may vary, so some flexible mechanism to identify them is necessary. This mechanism used is called header chaining and It is implemented using the Next Header field. The meaning of this field in short is to identify whats next. Actually, the Next Header field has two duties: it determines the following extension header or identifies the upper-layer protocol (TCP/UDP..etc) to which the datagram content should be passed. For plain datagram there is no need of
CYBERNET
extension header, in this case the Next Header simulates the Protocol field form IPv4 and contains value identifying the protocol which ordered the data transport. If there is an extension header present then the Next Header field determines its type. Every extension header also contains its own Next Header field identifying the following data. The chain mechanism is used here to simply announce who will be the next header, and the last header identifies the upper-layer protocol to which the datagram content belongs. Following diagram shows, the daisy chain method;
But there is one complication header chaining implementation, the processing of complete headers (complete chain) may require a walk through quite a long chain of extension headers which hinders the processing performance. To minimize this, IPv6 specifies a particular order of extension headers. Generally speaking, headers important for all forwarding nodes must be placed first; headers important just for the addressee are located on the end of the chain. The advantage of this sequence is that the processing node may stop header investigation early, as soon as it sees some extension header dedicated to the destination it can be sure that no more important headers follow. This improves the processing performance significantly, because in many cases the investigation of fixed basic header will be sufficient to forward the datagram. The order followed by multiple extension headers chained in an IPv6 packet is: Basic IPv6 header Hop-by-Hop Options Destination Options (if the Routing header is used) Routing Fragment 9 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
Authentication Encapsulating Security Payload Destination Options Upper-layer (TCP, UDP, ICMPv6, ...)
IPv6 Addressing
Addressing is a fundamental aspect of the communication process between two or more entities. It provides the means to identify information sources and destinations while enabling dedicated resources to appropriately link the two groups together. The most obvious distinguishing feature of IPv6 is its use of much larger addresses. The size of an address in IPv6 is 128 bits that is four times longer than the 32-bit IPv4 address. A 32-bit address space allows for 232, or 4,294,967,296, possible addresses. A 128-bit address space allows for 2128, or 340,282,366,920,938,463,463,374,607,431,768,211,456 (or 3.4 x 1038), possible addresses.
Representation of IPv6 Addresses

As defined in RFC 2373, IP Version 6 Addressing Architecture, three formats represent IPv6 addresses. The preferred format is the longest method. It represents all 32 hexadecimal characters that form an IPv6 address. The preferred format may also be seen as the representation that matches a computer's "thinking." Binary Format of IPv6 Address 0010000111011010000000001101001100000000000000000010111100111011 0000001010101010000000001111111111111110001010001001110001011010 Well it is really hard to read, write and remember, so Hexadecimal format is used. Above mentioned IPv6 address in hex-format will be, 21DA00D300002F3B02AA00FFFE289C5A This representation is still long enough to make it hard to remember, so the string of 32 hexadecimal characters was given some structure and segmented into 8 groups of 4 characters (or 16 bits) separated by a colon (:). 21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A The decimal representation, like the one used by IPv4 that everyone is familiar with, was not adopted by IPv6.
CYBERNET
The next method is the compressed representation of an IPv6 address. To simplify the typing of IPv6 addresses by humans, it is possible to compress the address when zero values are present in the IPv6 address. This means that preferred and compressed formats are different representations of the same IPv6 addresses, a new concept in comparison with IPv4. The rules introduce to compressed the 32 hexadecimal character are, The Elimination of Leading 0s: Within each group of 16 bits between two colons, the leading 0s can be eliminated. This means that you can write :00D3 as :D3. The Elimination of Consecutive 0s: You can collapse consecutive all-0 groups of 16 bits between consecutive colons. In this case, :0000:0000:0000: becomes :: . But this rule should be applied only once.
Now 32 characters IPv6 addressed can be compressed in following form, 21DA:D3::2F3B:2AA:FF:FE28:9C5A Finally, the third method to represent an address is related to transition mechanisms where an IPv4 address is embedded in an IPv6 address. This last representation is less important than the preferred and the compressed format, because it is useful only if you're using specific transition mechanisms such as automatic IPv4-compatible tunnels and dynamic Network Address Translation Protocol Translation (NAT-PT). Two kinds of IPv6 addresses have an embedded IPv4 address: IPv4-compatible IPv6 address: Used to establish an automatic tunnel to carry IPv6 packets over IPv4 networks. This address is related to a transition mechanism of the IPv6 protocol. IPv4-mapped IPv6 address: Used only on the local scope of nodes having both IPv4 and IPv6 stacks. Nodes use IPv4-mapped IPv6 addresses internally only. These addresses are never known outside the node itself and should not go on the wire as IPv6 addresses.
Although they both use the same address representation of an IPv4 address embedded in an IPv6 address, a different IPv6 prefix is defined for each kind of embedded IPv4 address. The IPv6 prefix for the IPv4-compatible IPv6 address is represented by the high-order 96-bit set to 0 followed by the 32-bit of the IPv4 address. The prefix for the IPv4-mapped IPv6 address is represented by the high-order 80-bit set to 0, then the next 16-bit set to 1, and finally followed by the 32-bit of the IPv4 address of the local node.
CYBERNET
It is important to mention that colon (:) is a meaningful character in the Uniform Resource Locator (URL), where it separates the port number from the address. To avoid confusion, RFC 2732 suggests enclosing the IPv6 address in a URL in brackets. http://[2001:4538:100::2]:7878 in place of https://www6.cyber.net.pk
IPv6 Prefix Notation

The notation for IPv6 prefixes has also been specified in RFC 4291. A global routing prefix is the high-order bits of an IP address used to identify the subnet or a specific type of address. It was called the format prefix in earlier RFCs. The prefix notation is very similar to the way IPv4 addresses are written in Classless Interdomain Routing (CIDR) notation, and it is also commonly used for subnetted IPv4 addresses. The notation appends the prefix length, written as a number of bits with a slash, which leads to the following format: IPv6 address/prefix length The prefix length specifies how many left-most bits of the address specify the prefix. This is another way of noting a subnet mask. The prefix is used to identify the subnet that an interface belongs to and is used by routers for forwarding.
IPv6 Addressing Types

Understanding the IPv6 address representation above, enables us to discuss the IPv6 addressing architecture defined in RFC 3513. Three types of IPv6 addresses have been defined:
CYBERNET
Unicast Addressing: A unicast address identifies a single interface within the scope of the type of address. The scope of an address is the region of the IPv6 network over which the address is unique. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, RFC 2373 allows for multiple interfaces to use the same address as long as they appear as a single interface to the IPv6 implementation on the host.
Anycast Addressing An anycast address identifies multiple interfaces. With the appropriate unicast routing topology, 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 the 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.
Multicast Addressing: A multicast address identifies zero or more interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces identified by the address.
IPv6 Unicast Address

The fundamental function of any network is to provide unicast reachability for the hosts connected to it. All other services it provides rely on this unicast infrastructure. For these reasons, regardless of the IP version, unicast addresses play a critical role in any network. RFC 3513 leaves no room for doubt about what the interface ID should be: "For all unicast addresses, except those that start with binary value 000, interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The rule reveals the intent to maintain a globally unique character for the interface ID whenever possible. You can generate an interface ID in many different ways: Build one from the layer 2 address in the modified EUI-64 format. For the interface ID portion of the network, the seventh high-order bit of the EUI13 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
64 format defines a local scope when set to 0 and a global scope (globally unique) when set to 1. Different mechanisms are defined for each media type to build the complete interface ID in the modified EUI-64 format. Autogenerate a random address as defined in RFC 3041. This assignment mechanism was developed mainly to limit the exposure of a globally reachable address and to increase privacy. Acquire the interface ID via DHCPv6. Manual configuration. Cryptographically generated addresses (CGAs) based on RFC 3972 through a hash that includes a public key. This method of generating an interface ID provides added security and enables address authentication.
The network portion of the address is further refined in the case of IPv6 to integrate the concept of scope. The scope identifies a network domain. Being able to easily recognize the scope of an IP stream enables a network to better manage its resources by containing the traffic within the relevant domain and by applying policies relevant to that scope. In IPv6, the unicast address format reflects three predefined scopes, as follows: The link-local scope identifies all hosts within a single layer 2 domain. The unicast addresses used within this scope are called link-local addresses. The unique-local scope identifies all devices reachable within an administrative site or domain that typically contains multiple distinct links. The unicast addresses used within this scope are called unique-local addresses (ULAs). The global scope identifies all devices reachable across the Internet. The unicast addresses used within this scope are called global unicast addresses (GUAs).
CYBERNET
Link Local Address When an IPv6-enabled node comes online, each interface is provided by default with a layer 3 address that can be used for communication exclusively with other hosts on the same link. The local link defines the scope of these addresses, so packets that have them as SA or DA should never be routed to other links. These addresses are called link-local. They are used for on-link communication as well as link operation processes such as finding neighbors or routers.
CYBERNET
Unique Local Unicast Address The concept of site scope can easily be mapped to that of a private administrative domain where addressing does not have to obey any global rules. The IPv6 addresses assigned to this scope as defined in RFC 3513 were called site-local, and they did not have to be unique. Their resemblance to the IPv4 private address space was a reminder of the drawbacks of such an approach (discussed in RFC 3879).
The portion of the unicast address space reserved for unique-local addresses (ULAs) is FC00::/7. the structure of a ULA with the following elements: L identifies the assignment policy. Only value 1 (FD00::/8) is currently in use designating a local assignment. Global ID is a 40-bit identifier that ensures the global uniqueness of the address. It is generated pseudo-randomly and must not be sequential. Because ULAs should not be globally routed, they do not need to be aggregated, so sequential global IDs are not necessary. Subnet ID gives the administrator of the local domain a resource that can be used to define a hierarchical addressing plan within the site. Interface ID has the same meaning for all unicast addresses, and it is 64 bits long in the modified EUI-64 format.
Global Unicast Address The global unicast addresses are defined for use across the IPv6 Internet. They are globally unique and globally routable. The IPv6 addresses reserved for global 16 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
scoped communication are identified by their high-level 3 bits set to 001 (2000::/3), as described in RFC 3587. A lot of effort has been placed on developing a flexible structure for the GUAs that facilitates easy aggregation. Several attempts were made, starting with RFC 2373, to enforce a granular address structure reflecting various levels of aggregation. In the end, it was decided to enforce proper aggregation through rigorous allocation policies and settle for a simpler address structure, as specified in RFC 3587.
The components of the global unicast address are as follows: Global routing prefix: A service provider is assigned a portion of this prefix by the Internet Assigned Numbers Authority (IANA), and it then allocates a subspace to its customers. Its length is 48 bits or shorter based on the RFC 3177 recommendations. Subnet ID: An organization receives a prefix from its service provider where the global routing prefix identifies the service provider (SP) and the organization inside the SP, and the subnet ID identifies the organizational structure of its network. Interface ID: The low-order 64 bits of the address are used to identify the interfaces of nodes on a link.
CYBERNET
IPv6 Unicast Address Allocation IANA is in charge of managing the IPv6 address space. The international allocation of IPv6 addresses has been delegated to several regional registry services: ARIN (American Registry for Internet Numbers) for North America and sub-Saharan Africa RIPE NCC (Rseau IP Europens Network Coordination Center) for Europe, the Middle East, Central Asia, and North Africa; APNIC (Asia Pacific Network Information Center) for the Asia/Pacific region LACNIC (Latin American and Caribbean Internet Addresses Registry) for Latin America. AfriNIC (African Network Information Center) went into operation in 2005 to cover Africa.
IANA 2001::/16
APNIC 2001:0200::/23 2001:0C00::/23 2001:0E00::/23 2001:4400::/23 2001:8000::/19 2001:A000::/20 2001:B000::/20
ARIN 2001:0400::/23 2001:1800::/23 2001:4800::/23 2600:0000::/12 2610:0000::/23 2620:0000::/23
RIPE NCC 2001:0600::/23 2001:0800::/23 2001:0A00::/23 2001:1400::/23 2001:1600::/23 2001:1A00::/23 2001:1C00::/22 2001:2000::/20 2001:3000::/21 2001:3800::/22
LACNIC 2001:1200::/23 2800:0000::/12
AfriNIC 2001:4200::/23 2C00:0000::/12
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
ISP /32
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
SITE /48
CYBERNET
IPv6 Prefix Allocation Rules The main rules for address allocation according to RFC 3177 are: Home network subscribers should receive a /48 prefix. Small and large enterprises should receive a /48 prefix. Very large subscribers can receive a /47 prefix or multiple /48 prefixes. Mobile networks, such as vehicles or mobile phones with an additional network interface (such as Bluetooth or 802.11b) should receive a static /64 prefix, to allow the connection of multiple devices through one subnet. A single PC with no additional need to subnet, such as one dialing up from a hotel room, may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix. A /64 prefix can be allocated when it is known that one and only one subnet is needed by design. A /128 prefix can be allocated when it is absolutely known that one and only one device is connecting.
There are several reasons why it is recommended to adhere to the /48 prefix: Changing ISPs is much easier if the /48 boundary is used by all providers. Otherwise, corporate subnets may have to be restructured when switching ISPs. The process for renumbering a site, which may include parallel operation of the old and the new prefix for a certain time, is much easier to handle. There are several approaches for multihoming solutions with IPv6 in discussion. Multihoming is when a host is connected to more than one network. No matter which approach is used; complexity will be reduced if subnet boundaries are equal. A site can manage all prefixes with one single DNS reverse zone. For sites that started out using the 6to4 transition mechanism, the transition to the official IPv6 address space will be easier, as the 6to4 prefix is a /48 prefix.
CYBERNET
So a site usually will receive a /48 prefix, which provides 16 bits for subnetting, allowing for 65,536 subnets. In special cases, a very large enterprise can request a shorter prefix. Some other prefix are also allocated for specific tunneling purpose, the list is mentioned under,
2001:0000::/32 2001:DB8::/32 2002::/16 3FFE::/16 Teredo For documentation purposes only, nonroutable 6to4 6Bone Testing (has been phased out on June 2006) RFC 4380 RFC 3849 RFC 3056 RFC 2471
Anycast Address
Anycast addresses are designed to provide redundancy and load balancing in situations where multiple hosts or routers provide the same service. Anycast was not originally created for IPv6; it was defined in RFC 1546 in 1993 as an experimental specification to be used with IPv4. The RFC allots a special prefix for anycast, which would make an anycast address recognizable as such based on the prefix. Anycast was meant to be used for services such as DNS and HTTP. The RFC discusses possible modifications to TCP to deal with these addresses that are not globally unique. In practice, anycast has not been implemented as it was designed to be. Often a method called shared unicast address is chosen. This method is implemented by assigning a regular unicast address to multiple interfaces/hosts and creating multiple entries in the routing table. In this case, the network and transport layer assume that it is a globally unique IP address. An exception to this rule is if the application uses independent stateless request/reply transactions for instance, DNS over UDP. The root DNS servers in the Internet are set up using shared unicast addresses. As this procedure does not require any support from the network layer, it can also be used with IPv6. From the beginning, the IPv6 developers considered anycast to be incorporated in the network layer according to RFC 1546. No special prefix was assigned. IPv6 anycast addresses are in the same address range as global unicast addresses and each participating interface must be configured to have an anycast address. Within the region where the interfaces containing the same anycast addresses are, each host must be advertised as a separate entry in the routing tables. If the anycast interfaces have no definable region, each anycast entry has to be propagated throughout the Internet, which obviously does not scale. 20 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
Within one network where a group of routers can provide access to a common routing domain, they can be assigned a single address. When a client sends a packet to this address, it will be forwarded to the next available router. One example is the 6to4 relay anycast address that is specified in RFC 3068. The Mobile IPv6 specification also uses anycast addresses. When using anycast addresses, we have to be aware of the fact that the sender has no control over which interface the packet will be delivered. This decision is taken on the level of the routing protocol. When a sender sends multiple packets to an anycast address, the packets may arrive at different destinations. If there is a series of requests and replies or if the packet has to be fragmented, this may cause problems. Basically, the router-subnet anycast address looks like a regular unicast address with a prefix specifying the subnet and an identifier set to all zeros. A packet sent to this address will be delivered to one router on that subnet. All routers are required to support the subnet-router anycast address for subnets to which they have interfaces. RFC 2526 provides more information about anycast address formats and specifies other reserved subnet anycast addresses and IDs. A reserved subnet anycast address can have one of two formats,
RFC 2526 specifies that within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses. Currently, the anycast IDs listed in have been reserved.
Decimal 127 126 0-125 Hexadecimal 7F 7E 00-7D Description Reserved Mobile IPv6 Home-Agents anycast Reserved
CYBERNET
The main difference between this form of using anycast and the shared unicast address is that in the latter, the application needs to support anycast, while in the former; this support is avoided if possible. Guidelines of how to use this and modifications to existing stateful transport protocols are needed.
IPv6 Multicast Address

Multicast received its well-deserved attention during the development of IPv6. It replaced broadcast addresses in the control-plane messages, thus becoming a critical part of IPv6 network operation. The larger address space provides plenty of globally unique multicast group addresses to facilitate the deployment of multicast services. A multicast address identifies a group of interfaces. A packet with a multicast destination address is delivered to all the group members. It is important to remember that multicast addresses should not be used as SAs. The IPv6 multicast addresses have their top 8 high-order bits set to 1 (FF00::/8) and the format shown
Three of the four bits in the flag are currently in use: The low-order bit T defined in RFC 3513 is set to 0 for permanently assigned multicast addresses that are assigned by IANA. The T bit is set to 1 for non-permanently assigned multicast addresses. The P bit is defined in RFC 3306, and it indicates whether the multicast address is built based on a unicast prefix (set to 1) or not (set to 0). The R bit defined in RFC 3956, if set to 1, indicates that the multicast group address contains the unicast address of the RP servicing that group. 22 Copyright 2006, Cyber Internet Services Pvt. Ltd.
CYBERNET
The remaining fourth flag bit is reserved for future use and currently is set to 0. Scoping is a powerful feature built in the IPv6 multicast address architecture. It provides routers with the information needed to contain the multicast traffic within the appropriate domain. Following table list the values that are currently defined for the 4-bit Scope field shown,
Scope (Hex) Scope (Binary) Description 1 2 3 4 5 8 E 0001 0010 0011 0100 0101 1000 1110 Interface-local scope Link-local scope Subnet-local scope Admin-local scope Site-local scope Organization-local scope Global-local scope
IPv6 Multicast Address Allocation IPv6 multicast addresses are allocated by IANA. IANA identifies two multicast address types in its allocation policy: Variable-scope multicast addresses: These addresses are similar across all scopes, but they represent distinct groups. They are reserved for certain types of services or applications. A good example is NTP (Network Time Protocol), which has a multicast address of FF0X:0:0:0:0:0:0:101, where X masks the address scope. Fixed-scope multicast addresses: These addresses have a certain meaning only within the scope they are defined in. This type of addresses is important in the basic operation of IPv6. Few common ones are listed in Appendix-B.
CYBERNET
Appendix-A Possible values of Next Header field in IPv6 Header and their meaning.
Value 0 1 2 4 6 8 9 17 41 43 44 45 46 47 50 51 58 59 60 88 89 108 115 132 135 136-254 255 Description In an IPv4 header: reserved and not used In an IPv6 header: Hop-by-Hop Option Header following Internet Control Message Protocol (ICMPv4)IPv4 support Internet Group Management Protocol (IGMPv4)IPv4 support IPv4 TCP Exterior Gateway Protocol (EGP) IGP any private interior gateway (used by Cisco for their IGRP) UDP IPv6 Routing header Fragmentation header Inter-domain Routing Protocol (IDRP) Resource Reservation Protocol (RSVP) General Routing Encapsulation (GRE) Encrypted Security Payload header Authentication header ICMPv6 No Next Header for IPv6 Destination Options header EIGRP OSPF IP Payload Compression Protocol Layer 2 Tunneling Protocol (L2TP) Stream Control Transmission Protocol (SCTP) Mobility Header (Mobile IPv6) Unassigned Reserved
CYBERNET
Appendix-B Following are the list of fixed scope IPv6 Multicast address,
Address Interface-local scope FF01:0:0:0:0:0:0:1 FF01:0:0:0:0:0:0:2 Link-local scope FF02:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:3 FF02:0:0:0:0:0:0:4 FF02:0:0:0:0:0:0:5 FF02:0:0:0:0:0:0:6 FF02:0:0:0:0:0:0:7 FF02:0:0:0:0:0:0:8 FF02:0:0:0:0:0:0:9 FF02:0:0:0:0:0:0:A FF02:0:0:0:0:0:0:B FF02:0:0:0:0:0:0:D FF02:0:0:0:0:0:0:E FF02:0:0:0:0:0:0:16 FF02:0:0:0:0:0:0:6A FF02:0:0:0:0:0:1:1 FF02:0:0:0:0:0:1:2 FF02:0:0:0:0:0:1:3 FF02:0:0:0:0:0:1:4 FF02:0:0:0:0:1:FFXX:XXXX Site-local scope FF05:0:0:0:0:0:0:2 FF05:0:0:0:0:0:1:3 FF05:0:0:0:0:0:1:4 FF05:0:0:0:0:0:1:1000 to FF05:0:0:0:0:01:13FF All-routers address All DHCP servers Deprecated Service location (SLP) Version 2 All-nodes address All-routers address Unassigned DVMRP routers OSPFIGP OSPFIGP designated routers ST routers ST hosts RIP routers EIGRP routers Mobile agents All PIM routers RSVP encapsulation All MLDv2-capable routers All snoopers Link name All DHCP agents Link-local Multicast Name Resolution DTCP Announcement Solicited-node address All-nodes address All-routers address Description
CYBERNET
References
RFC 791, Internet Protocol RFC 2373, IP Version 6 Addressing Architecture RFC 2374, An IPv6 Aggregatable Global Unicast Address Format RFC 2460, Internet Protocol, Version 6 (IPv6) Specification RFC 2460, Internet Protocol, Version 6 (IPv6) Specification RFC 2462, IPv6 Stateless Address Autoconfiguration RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2526, Reserved IPv6 Subnet Anycast Addresses RFC 2732, Format for Literal IPv6 Addresses in URL's RFC 3177, IAB/IESG Recommendations on IPv6 Address Allocations to Sites RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture RFC 3587, IPv6 Global Unicast Address Format RFC 3879, Deprecating Site Local Addresses RFC 4291, IP Version 6 Addressing Architecture Cisco Self-Study - Implementing IPv6 Networks (IPV6) Cisco Press - Deploying.IPv6.Networks O'Reilly - IPv6 Essentials

IPv6 Header and Addressing Essentials

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

IPv6 Header and Addressing Essentials

Diunggah oleh

Hak Cipta:

Format Tersedia

IPv6 Header and Addressing Essentials