IPv6 Header and Addressing Essentials

8/6/2019 IPv6 Header and Addressing Essentials

1/26

IPv6 Header and Addressing Essentials CYBERNET

1

Technical Paper

IPv6 Header and Addressing Essentials

Fahad Ali KhanSenior Network EngineerNetwork Engineering Department

CYBERNET

Cyber Internet Services Pvt. LtdA904- Lakson Square Building # 3

Sarwar Shaheed road Karachi, Pakistan111-56-56-56www.cyber.net.pkwww6.cyber.net.pk

Copyright 2006, Cyber Internet Services Pvt. Ltd.


2/26


2Copyright 2006, Cyber Internet Services Pvt. Ltd.

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....................................................................................................20IPV6 MULTICAST ADDRESS........................................................................................22

IPV6 MULTICAST ADDRESS ALLOCATION ...............................................................23

APPENDIX-A .................................................................................................................24

APPENDIX-B .................................................................................................................25

REFERENCE .................................................................................................................26


3/26



Executive Summary

The structure of the actual IP packet header was quite modified in IPv6. Thesechanges reflect some of the lessons learned from years of operating IPv4, andthey have a significant impact on the protocol operation. To fulfill the need oftomorrow IPv6 address is designed to128bits and it is good enough to covermore than every element in this universe or it can be compared to providingmultiple IP addresses for every grain of the sand on the Planet.

Designing large space address can cause other issue like more need forprocessing and memory in IPv6 Nodes, also its assignment and management willalso lead Network Administrator to hard thinking about IPv6 deployment. ButIPv6 developers have these thoughts were in their mind and they came with verygood features in IPv6 headers and its addressing & deployment procedureswhich will not only limit the need of memory and processing overheads but alsohelp administrator to easily adopt it in their existing networks without thinking ofIP addressing renumbering and manual assignment to thousands of Hosts andNodes.

IPv6 Header Vs IPv4 Header

The core of every protocol is naturally its datagram format. After severalexperimental implementations were created and some practical experiencegained 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 RFC2460. Before exploring the header fields of IPv6, it is necessary to find out whatare the motivations behind the choices made with respect to IPv4 headerstructure.

IPv4 Header

IPv4 packet has two components, the header that contains the layer 3information and the payload that carries the data and the upper-layer protocolinformation. RFC 791 defines the following fields for the IPv4 packet header:


4/26



:Version (4 bits)It represents the version of the IP protocol. As the name suggest, the fieldis 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 forwardpacket in a differentiated manner. It is an important service identifier usedin implementing Quality of Service (QoS).

Total Length (16 bits):This field defines the length in octets of the entire packet, header pluspayload. With 16 bits available in this field, the maximum length of an IPv4packet is 65,535 octets.

Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits):These three fields enable IPv4 networks to support packet fragmentationto negotiate forwarding over links supporting various maximumtransmission units (MTUs). Fragmentation is done as needed by therouters along the path of the packet.

Time To Live (8 bits):It is important to protect a network's resources from packets that loop dueto routing problems. This field is used to count down the number of routersthat switched the packet. The packet is discarded when the value of thisfield is 0.


5/26



Protocol Number (8 bits):The Protocol Number lists the upper-layer protocol (TCP, UDP, ICMP, andso on) that is present in the packet payload.

Header Checksum (16 bits):The integrity of the packet header is verified by comparing the computedchecksum 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 properhandling of the data carried by the packet, information that is notrepresented in the other fields of the header. Because of this field, theIPv4 header has a variable length, justifying the need for the HeaderLength field.

Padding (variable length):This field is used to align the variable-length Options field to the 32-bitboundary.

Fields removed from IPv4 HeaderThe relevancy of the highlighted fields in IPv4 Header format has been re-evaluated in the process of developing IPv6 and it has been found that there isno more need of some fields in the new protocol version as they will not helpmuch 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 Optionsfield. When present, the Options field increases the length of the IPv4header. Instead of the Options field, IPv6 uses the Extension field. TheExtension field is handled differently from how IPv4 handles the Optionsfield.


6/26



Identification, Flags, and Fragment Offset: Fragmentation is handleddifferently in IPv6. It is no longer done by intermediate routers in thenetworks, but by the source node that originates the packet. Removing theFragmentation field removes costly CPU processing at intermediaterouters. The path MTU discovery (PMTUD) mechanism is used by everyIPv6 node to avoid fragmentation.

Header Checksum: Link-layer technologies (Layer 2) perform their ownchecksum and error control. The reliability of link-layer is now good andupper-layer protocols such TCP and UDP (Layer 4) also have theirchecksums. UDP checksum, which was optional in IPv4, is mandatory inIPv6. Therefore, the checksum at Layer 3 is redundant, so the HeaderChecksum field is unnecessary in IPv6 and suppresses the re-computation process each time a packet passes through a router.

The CRC has been abandoned for two good reasons: First, frameconsistency is checked in lower layers, so it is largely redundant. Second,CRC decelerates the datagram processing, every forwarding nodedecreases the datagram lifetime, so it changes the header and mustrecalculate the CRC.

Options and Padding: The Options field is radically changed in IPv6. Theoptions are now handled by extension headers. The Padding field is alsoremoved. The removal of Options and Padding headers simplifies the IPheader. Thus, the basic IPv6 header has a fixed length of 40 octets,allowing less processing by routers along the delivery path compared toIPv4.

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 IPv4Address, either was not changed or was modified only slightly.

IPv6 Header

As defined in RFC 2460, Internet Protocol version 6 (IPv6) Specification, thebasic 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 basicIPv6 header might have one or many extension headers daisy chained followingthe 40 octets. The description of these eight fields of basic IPv6 header is asfollows,


7/26



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 real-time and other data services classification in the network. Sending nodesand forwarding routers can use it to identify and distinguish betweendifferent classes or priorities of IPv6 packets to handle them in differentmanner.

RFC 2474, "Definition of the Differentiated Services Field (DS Field) in theIPv4 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 ofService" field in the IPv4 header, as well as to the Traffic Class field in theIPv6 header.

Flow Label (20 bits):This field identifies a flow and it is intended to enable the router to identifypackets that should be treated in a similar way without the need for deeplookups within those packets. The specification for this header field ispresented in RFC 3697. The field is set by the source and should not bechanged by routers along the path to destination.

The Flow Label together with the SA and DA can uniquely identify IPv6flows. This ID can map in the main header traffic characteristics that aredeeper in the packet, providing routers with the capability to appropriatelyhandle packets without the need to look deep into them.

The Flow Label field is unique to IPv6, but it is recognized to be a powerfultool and similar extensions are being proposed for IPv4. Applications areenvisioned where the field is used just as a tag as well as more complex


8/26



ones that maintain label state on the nodes using a signaling protocol. TheFlow Label can be used with differentiated services (DiffServ) as well asintegrated services (IntServ) and Resource ReSerVation Protocol(RSVP2).

Payload Length (16 bits):This field represents the payload's length. The payload is the remainingpart of the packet following the IPv6 header. The extension headers areconsidered as the part of packet payload.

Next Header (8 bits):This field expands the functionality of the Protocol Number in the IPv4header. Its a pointer towards the information type immediately followingthe basic header. This can be an extension header or the upper-layerprotocol in the payload. The possible values of next header can be find inAppendix-A

Hop Limit (8 bits):This field defines the maximum number of hops (intermediate routers) thatthe IP packet can pass through. Each hop decreases this value by 1. As inIPv4, when this field contains the value 0, the packet is destroyed and anInternet 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 designerschose a different approach i.e. extension headers. They are added after the IPv6datagram only if needed, i.e. if it is necessary to fragment the datagram thefragmentation header is put into it. The number of extension headers may vary,so some flexible mechanism to identify them is necessary. This mechanism usedis called header chaining and It is implemented using the Next Header field. Themeaning of this field in short is to identify whats next.

Actually, the Next Header field has two duties: it determines the followingextension header or identifies the upper-layer protocol (TCP/UDP..etc) to whichthe datagram content should be passed. For plain datagram there is no need of


9/26



extension header, in this case the Next Header simulates the Protocol field formIPv4 and contains value identifying the protocol which ordered the data transport.

If there is an extension header present then the Next Header field determines itstype. Every extension header also contains its own Next Header field identifying

the following data. The chain mechanism is used here to simply announce whowill be the next header, and the last header identifies the upper-layer protocol towhich 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 longchain of extension headers which hinders the processing performance. Tominimize this, IPv6 specifies a particular order of extension headers.

Generally speaking, headers important for all forwarding nodes must be placedfirst; headers important just for the addressee are located on the end of thechain. The advantage of this sequence is that the processing node may stopheader investigation early, as soon as it sees some extension header dedicatedto the destination it can be sure that no more important headers follow. Thisimproves the processing performance significantly, because in many cases theinvestigation 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


10/26



Authentication

Encapsulating Security Payload Destination Options

Upper-layer (TCP, UDP, ICMPv6, ...)

IPv6 Addressing

Addressing is a fundamental aspect of the communication process between twoor more entities. It provides the means to identify information sources anddestinations while enabling dedicated resources to appropriately link the twogroups together. The most obvious distinguishing feature of IPv6 is its use ofmuch larger addresses. The size of an address in IPv6 is 128 bits that is fourtimes 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, or340,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 formatsrepresent IPv6 addresses. The preferred format is the longest method. Itrepresents all 32 hexadecimal characters that form an IPv6 address. Thepreferred format may also be seen as the representation that matches acomputer's "thinking."

Binary Format of IPv6 Address

00100001110110100000000011010011000000000000000000101111001110110000001010101010000000001111111111111110001010001001110001011010

Well it is really hard to read, write and remember, so Hexadecimal format isused. Above mentioned IPv6 address in hex-format will be,

21DA00D300002F3B02AA00FFFE289C5A

This representation is still long enough to make it hard to remember, so the stringof 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 familiarwith, was not adopted by IPv6.


11/26



The next method is the compressed representation of an IPv6 address. Tosimplify the typing of IPv6 addresses by humans, it is possible to compress theaddress when zero values are present in the IPv6 address. This means thatpreferred and compressed formats are different representations of the same IPv6addresses, 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 betweentwo colons, the leading 0s can be eliminated. This means that you canwrite :00D3 as :D3.

The Elimination of Consecutive 0s: You can collapse consecutive all-0groups 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 transitionmechanisms where an IPv4 address is embedded in an IPv6 address. This lastrepresentation is less important than the preferred and the compressed format,because it is useful only if you're using specific transition mechanisms such asautomatic IPv4-compatible tunnels and dynamic Network Address TranslationProtocol Translation (NAT-PT).

Two kinds of IPv6 addresses have an embedded IPv4 address:

IPv4-compatible IPv6 address: Used to establish an automatic tunnel tocarry IPv6 packets over IPv4 networks. This address is related to atransition mechanism of the IPv6 protocol.

IPv4-mapped IPv6 address: Used only on the local scope of nodeshaving both IPv4 and IPv6 stacks. Nodes use IPv4-mapped IPv6addresses internally only. These addresses are never known outside thenode 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 ofembedded IPv4 address. The IPv6 prefix for the IPv4-compatible IPv6 address isrepresented by the high-order 96-bit set to 0 followed by the 32-bit of the IPv4address. The prefix for the IPv4-mapped IPv6 address is represented by thehigh-order 80-bit set to 0, then the next 16-bit set to 1, and finally followed by the32-bit of the IPv4 address of the local node.


12/26



It is important to mention that colon (:) is a meaningful character in the UniformResource Locator (URL), where it separates the port number from the address.To avoid confusion, RFC 2732 suggests enclosing the IPv6 address in a URL inbrackets.

http://[2001:4538:100::2]:7878 in place of https://www6.cyber.net.pkIPv6 Prefix Notation

The notation for IPv6 prefixes has also been specified in RFC 4291. A globalrouting prefix is the high-order bits of an IP address used to identify the subnet ora specific type of address. It was called the format prefix in earlier RFCs. Theprefix notation is very similar to the way IPv4 addresses are written in ClasslessInterdomain Routing (CIDR) notation, and it is also commonly used for subnettedIPv4 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 theprefix. This is another way of noting a subnet mask. The prefix is used to identifythe 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 IPv6addresses have been defined:
https://www6.cyber.net.pk/https://www6.cyber.net.pk/


13/26



Unicast Addressing:

A unicast address identifies a single interface within the scope of the typeof address. The scope of an address is the region of the IPv6 networkover which the address is unique. With the appropriate unicast routingtopology, packets addressed to a unicast address are delivered to a singleinterface. To accommodate load-balancing systems, RFC 2373 allows formultiple interfaces to use the same address as long as they appear as asingle interface to the IPv6 implementation on the host.

Anycast Addressing

An anycast address identifies multiple interfaces. With the appropriateunicast routing topology, packets addressed to an anycast address aredelivered to a single interface, the nearest interface that is identified by theaddress. The nearest interface is defined as being the closest in terms ofrouting distance. A multicast address is used for one-to-manycommunication, with delivery to multiple interfaces. An anycast address isused for one-to-one-of-many communication, with delivery to a singleinterface.

Multicast Addressing:

A multicast address identifies zero or more interfaces. With theappropriate multicast routing topology, packets addressed to a multicastaddress are delivered to all interfaces identified by the address.

IPv6 Unicast Address

The fundamental function of any network is to provide unicast reachability for thehosts connected to it. All other services it provides rely on this unicastinfrastructure. For these reasons, regardless of the IP version, unicast addressesplay a critical role in any network.

RFC 3513 leaves no room for doubt about what the interface ID should be: "Forall unicast addresses, except those that start with binary value 000, interface IDsare 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 theinterface ID whenever possible. You can generate an interface ID in manydifferent ways:

Build one from the layer 2 address in the modified EUI-64 format. For theinterface ID portion of the network, the seventh high-order bit of the EUI-


14/26



64 format defines a local scope when set to 0 and a global scope (globallyunique) when set to 1. Different mechanisms are defined for each mediatype to build the complete interface ID in the modified EUI-64 format.

Autogenerate a random address as defined in RFC 3041. This assignmentmechanism was developed mainly to limit the exposure of a globallyreachable address and to increase privacy.

Acquire the interface ID via DHCPv6.

Manual configuration.

Cryptographically generated addresses (CGAs) based on RFC 3972through a hash that includes a public key. This method of generating aninterface ID provides added security and enables address authentication.

The network portion of the address is further refined in the case of IPv6 tointegrate the concept of scope. The scope identifies a network domain. Beingable to easily recognize the scope of an IP stream enables a network to bettermanage its resources by containing the traffic within the relevant domain and byapplying 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-localaddresses.

The unique-local scope identifies all devices reachable within anadministrative site or domain that typically contains multiple distinct links.The unicast addresses used within this scope are called unique-localaddresses (ULAs).

The global scope identifies all devices reachable across the Internet. Theunicast addresses used within this scope are called global unicastaddresses (GUAs).


15/26



Link Local Address

When an IPv6-enabled node comes online, each interface is provided by defaultwith a layer 3 address that can be used for communication exclusively with otherhosts on the same link. The local link defines the scope of these addresses, sopackets that have them as SA or DA should never be routed to other links. Theseaddresses are called link-local. They are used for on-link communication as wellas link operation processes such as finding neighbors or routers.


16/26



Unique Local Unicast Address

The concept of site scope can easily be mapped to that of a privateadministrative 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 IPv4private 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 inuse designating a local assignment.

Global ID is a 40-bit identifier that ensures the global uniqueness of theaddress. It is generated pseudo-randomly and must not be sequential.Because ULAs should not be globally routed, they do not need to beaggregated, so sequential global IDs are not necessary.

Subnet ID gives the administrator of the local domain a resource that canbe used to define a hierarchical addressing plan within the site.

Interface ID has the same meaning for all unicast addresses, and it is 64bits long in the modified EUI-64 format.

Global Unicast Address

The global unicast addresses are defined for use across the IPv6 Internet. Theyare globally unique and globally routable. The IPv6 addresses reserved for global


17/26



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 GUAsthat facilitates easy aggregation. Several attempts were made, starting with RFC

2373, to enforce a granular address structure reflecting various levels ofaggregation. In the end, it was decided to enforce proper aggregation throughrigorous allocation policies and settle for a simpler address structure, as specifiedin RFC 3587.

The components of the global unicast address are as follows:

Global routing prefix: A service provider is assigned a portion of thisprefix by the Internet Assigned Numbers Authority (IANA), and it then

allocates a subspace to its customers. Its length is 48 bits or shorterbased on the RFC 3177 recommendations.

Subnet ID: An organization receives a prefix from its service providerwhere the global routing prefix identifies the service provider (SP) and theorganization inside the SP, and the subnet ID identifies the organizationalstructure of its network.

Interface ID: The low-order 64 bits of the address are used to identify theinterfaces of nodes on a link.


18/26



IPv6 Unicast Address Allocation

IANA is in charge of managing the IPv6 address space. The internationalallocation of IPv6 addresses has been delegated to several regional registryservices:

ARIN (American Registry for Internet Numbers) for North America andsub-Saharan Africa

RIPE NCC (Rseau IP Europens Network Coordination Center) forEurope, the Middle East, Central Asia, and North Africa;

APNIC (Asia Pacific Network Information Center) for the Asia/Pacificregion

LACNIC (Latin American and Caribbean Internet Addresses Registry)for Latin America.

AfriNIC (African Network Information Center) went into operation in2005 to cover Africa.

APNIC

2001:0200::/232001:0C00::/232001:0E00::/232001:4400::/232001:8000::/192001:A000::/202001:B000::/20

ARIN

2001:0400::/232001:1800::/232001:4800::/232600:0000::/122610:0000::/232620:0000::/23

RIPE NCC

2001:0600::/232001:0800::/232001:0A00::/232001:1400::/232001:1600::/232001:1A00::/232001:1C00::/222001:2000::/202001:3000::/212001:3800::/22

ISP/32

ISP/32

SITE/48

SITE/48

LACNIC

2001:1200::/232800:0000::/12

AfriNIC

2001:4200::/232C00:0000::/12

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

IANA2001::/16


19/26



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 additionalnetwork 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 froma hotel room, may receive its /128 IPv6 address for a PPP styleconnection as part of a /64 prefix.

A /64 prefix can be allocated when it is known that one and only onesubnet is needed by design.

A /128 prefix can be allocated when it is absolutely known that one andonly 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 switchingISPs.

The process for renumbering a site, which may include parallel operationof the old and the new prefix for a certain time, is much easier to handle.

There are several approaches for multihoming solutions with IPv6 indiscussion. Multihoming is when a host is connected to more than onenetwork. No matter which approach is used; complexity will be reduced ifsubnet 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, thetransition to the official IPv6 address space will be easier, as the 6to4prefix is a /48 prefix.


20/26



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 requesta shorter prefix.

Some other prefix are also allocated for specific tunneling purpose, the list is

mentioned under,

2001:0000::/32 Teredo RFC 4380

2001:DB8::/32 For documentation purposes only, nonroutable RFC 3849

2002::/16 6to4 RFC 3056

3FFE::/16 6Bone Testing (has been phased out on June 2006) RFC 2471

Anycast Address

Anycast addresses are designed to provide redundancy and load balancing insituations where multiple hosts or routers provide the same service. Anycast wasnot originally created for IPv6; it was defined in RFC 1546 in 1993 as anexperimental specification to be used with IPv4. The RFC allots a special prefixfor anycast, which would make an anycast address recognizable as such basedon the prefix. Anycast was meant to be used for services such as DNS andHTTP. The RFC discusses possible modifications to TCP to deal with theseaddresses 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 byassigning a regular unicast address to multiple interfaces/hosts and creatingmultiple entries in the routing table. In this case, the network and transport layerassume that it is a globally unique IP address. An exception to this rule is if theapplication uses independent stateless request/reply transactions for instance,DNS over UDP. The root DNS servers in the Internet are set up using sharedunicast addresses. As this procedure does not require any support from thenetwork layer, it can also be used with IPv6.

From the beginning, the IPv6 developers considered anycast to be incorporatedin the network layer according to RFC 1546. No special prefix was assigned.

IPv6 anycast addresses are in the same address range as global unicastaddresses and each participating interface must be configured to have ananycast address. Within the region where the interfaces containing the sameanycast addresses are, each host must be advertised as a separate entry in therouting tables. If the anycast interfaces have no definable region, each anycastentry has to be propagated throughout the Internet, which obviously does notscale.


21/26


22/26



The main difference between this form of using anycast and the shared unicastaddress is that in the latter, the application needs to support anycast, while in theformer; this support is avoided if possible. Guidelines of how to use this andmodifications to existing stateful transport protocols are needed.

IPv6 Multicast Address

Multicast received its well-deserved attention during the development of IPv6. Itreplaced broadcast addresses in the control-plane messages, thus becoming acritical part of IPv6 network operation. The larger address space provides plentyof globally unique multicast group addresses to facilitate the deployment ofmulticast services.

A multicast address identifies a group of interfaces. A packet with a multicastdestination address is delivered to all the group members. It is important toremember that multicast addresses should not be used as SAs. The IPv6multicast addresses have their top 8 high-order bits set to 1 (FF00::/8) and theformat 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 permanentlyassigned 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 multicastaddress 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 multicastgroup address contains the unicast address of the RP servicing thatgroup.


23/26



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. Itprovides 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 fieldshown,

Scope (Hex) Scope (Binary) Description

1 0001 Interface-local scope

2 0010 Link-local scope

3 0011 Subnet-local scope

4 0100 Admin-local scope

5 0101 Site-local scope

8 1000 Organization-local scope

E 1110 Global-local scope

IPv6 Multicast Address Allocation

IPv6 multicast addresses are allocated by IANA. IANA identifies two multicastaddress types in its allocation policy:

Variable-scope multicast addresses: These addresses are similaracross all scopes, but they represent distinct groups. They are reservedfor certain types of services or applications. A good example is NTP(Network Time Protocol), which has a multicast address ofFF0X:0:0:0:0:0:0:101, where X masks the address scope.

Fixed-scope multicast addresses: These addresses have a certainmeaning only within the scope they are defined in. This type of addressesis important in the basic operation of IPv6. Few common ones are listed inAppendix-B.
http://ch02table03/#ch02table03http://ch02table03/#ch02table03


24/26



Appendix-A

Possible values of Next Header field in IPv6 Header and their meaning.

Value Description

0In an IPv4 header: reserved and not usedIn an IPv6 header: Hop-by-Hop Option Header following

1 Internet Control Message Protocol (ICMPv4)IPv4 support

2 Internet Group Management Protocol (IGMPv4)IPv4 support

4 IPv4

6 TCP

8 Exterior Gateway Protocol (EGP)

9 IGP any private interior gateway (used by Cisco for their IGRP)

17 UDP

41 IPv6

43 Routing header

44 Fragmentation header

45 Inter-domain Routing Protocol (IDRP)

46 Resource Reservation Protocol (RSVP)

47 General Routing Encapsulation (GRE)

50 Encrypted Security Payload header

51 Authentication header58 ICMPv6

59 No Next Header for IPv6

60 Destination Options header

88 EIGRP

89 OSPF

108 IP Payload Compression Protocol

115 Layer 2 Tunneling Protocol (L2TP)

132 Stream Control Transmission Protocol (SCTP)

135 Mobility Header (Mobile IPv6)

136-254 Unassigned

255 Reserved


25/26



Appendix-B

Following are the list of fixed scope IPv6 Multicast address,

Address Description

Interface-local scope

FF01:0:0:0:0:0:0:1 All-nodes address

FF01:0:0:0:0:0:0:2 All-routers address

Link-local scope

FF02:0:0:0:0:0:0:1 All-nodes address


FF02:0:0:0:0:0:0:3 Unassigned

FF02:0:0:0:0:0:0:4 DVMRP routers

FF02:0:0:0:0:0:0:5 OSPFIGP

FF02:0:0:0:0:0:0:6 OSPFIGP designated routers

FF02:0:0:0:0:0:0:7 ST routers

FF02:0:0:0:0:0:0:8 ST hosts

FF02:0:0:0:0:0:0:9 RIP routers

FF02:0:0:0:0:0:0:A EIGRP routers

FF02:0:0:0:0:0:0:B Mobile agents

FF02:0:0:0:0:0:0:D All PIM routers

FF02:0:0:0:0:0:0:E RSVP encapsulationFF02:0:0:0:0:0:0:16 All MLDv2-capable routers

FF02:0:0:0:0:0:0:6A All snoopers

FF02:0:0:0:0:0:1:1 Link name

FF02:0:0:0:0:0:1:2 All DHCP agents

FF02:0:0:0:0:0:1:3 Link-local Multicast Name Resolution

FF02:0:0:0:0:0:1:4 DTCP Announcement

FF02:0:0:0:0:1:FFXX:XXXX Solicited-node address

Site-local scope


FF05:0:0:0:0:0:1:3 All DHCP servers

FF05:0:0:0:0:0:1:4 Deprecated

FF05:0:0:0:0:0:1:1000 to FF05:0:0:0:0:01:13FF Service location (SLP) Version 2


26/26


References

RFC 791, Internet Protocol

RFC 2373, IP Version 6 Addressing ArchitectureRFC 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

Documents

IPv6 Header and Addressing Essentials