Chapter 6: IPv6 Addressing

Introduction:

One of the major changes from IPv4 to IPv6 is the expanded addressing capabilities from 32-bits to 128-bits. The expanded addressing supports many more addressable nodes, an expanded addressing hierarchy, and simpler auto-configuration of addresses. In addition IPv6 supports a new type of address called an anycast address. The use of this type of address causes a node to send a packet to any one of a group of nodes.

Many environments exist that have one or more network protocols deployed and where there is a significant comprehensive network-addressing plan in place. In these cases, the use of common addresses can help facilitate the transition from other protocols to IPv6.

This chapter briefly:

• Reviews the IPv4 addressing architecture, the different forms of IP address, and IP subnetting.
• Describes the changing role of IP addresses including the changing profile of IP address users, the changing role of non-globally unique locators and identifiers, and the advent of multicast and anycast addresses.
• Introduces IPv6 addressing including: a summary of IPv6 Address Allocation Management and the role of the Internet Assigned Number Authority (IANA), the IPv6 address model, some addressing rules, text representations for IPv6 addresses, and IPv6 Address type representation and allocation.
• Discusses the various types of unicast address formats and types including IPv6 addresses with embedded IPv4 addresses, provider-based global unicast addresses, local-use addresses, and a discussion of the various fields in a provider-based global unicast address.
• Describes anycast addresses, the anycast address prefix, anycast address use, and the predefined and required anycast addresses.
• Introduces multicast addresses and address format, the differences between permanently and non-permanently assigned multicast addresses, and lists the predefined well-known multicast addresses.
• Describes a node’s required addresses.
• Touches on address resolution using Domain Name System (DNS) mapping of hostnames into both IPv4 and IPv6 addresses. (This subject is discussed in more detail in
Chapter 16, "Making the Transition to IPv6."

The IETF is working with other organizations to develop algorithms that map addresses between IPv6 and other environments. For example, mapping algorithms already exist or are under development for various types of addresses including mapping algorithms for Novell IPX addresses, some types of OSI Network Service Access Points (NSAPs), E164 addresses and SNA addresses. Such mappings will provide an unambiguous one-to-one map between individual addresses.

In addition, the IETF in conjunction with other organizations is developing recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments.

The format and semantics of IPv6 addresses are specified separately in [RFC-1884].

Quick review IPv4 addressing

This section provides is a brief review of IPv4 addressing. Within its 32-bit address field, IPv4 organizes the networked world into a two-level hierarchy: network numbers, and host numbers within network numbers. The Internet Assigned Numbers Authority (IANA) has largely delegated to Internet Service Providers the job of assigning unique network numbers to requesting organizations. The organizations network administrator then assigns unique host numbers to its attached devices. The IANA previously assigned globally unique addresses.

General IPv4 Addressing Architecture

IP addresses consist of a 32-bit value that is usually presented in decimal dot notation that consists of 4 octets (bytes) separated by a dot; for example 172.16.10.0. An IP address consists of network and host identifications. In an IPv4 implementation, each physical network and host has its own unique network address. Routers or gateways can have one or more addresses depending on the number of interfaces present.

Forms of IP Addresses

To accommodate the needs of large and small organizations and make the best use of its 32 available bits, IPv4 recognizes three kinds of unicast addresses classes and two specialized address classes: class D and class E. A unicast address identifies a specific network interface addresses.

Rather than being assigned to a specific interface, a class D address identifies the members of a logical group of interfaces rather than a specific interface. For example, a class D address could identify all the interfaces attached to IP network routers. All logical holders of particular class D addresses receives packets sent to that address. This multicast addressing scheme has never been widely used. This may be due to the way IPv4 implementations use multicast addressing.

Class E addresses are reserved by the IANA for future and experimental uses.

Class A addresses are intended for use by the world's largest organizations. Except for a few reserved and some perhaps re-assignable values, Class A addresses are all taken. While there are more than 16 thousand class B addresses each supporting up to 65 thousand hosts, this class of IPv4 addresses is practically all used up. Class C addresses are intended for very small network communities. An existing pool of these addresses is supporting the current growth in the internet.

Each class of IPv4 addresses consist of two parts; a network identifier portion and a host or node identifier portion as shown. In this example the binary address 10000000 00000111 00001111 00000001 has the decimal dot notation of 128.7.15.1. This is a class B address with the Network ID of 128.7.

Special forms of Internet addresses include the following:

• 0.0.0.0 indicates this host.
• 0.host-number indicates this host on this net.
• 255.255.255.255 indicates limited broadcast to the local net.
• Net-number.255 indicates directed broadcast for the specified net.
• 127.anything indicates the loopback internal in the host. This should never appear on the network.

IP Subnetting

Subnetting is a technique of assigning addresses that allows a single IP network address to span multiple physical networks. Subnetting uses some of the bits of the host-id part of the IP address as a physical network identifier. The subnet mask determines the bits of the network identifier. With subnetting, the Network ID and Host ID division changes to Network ID, Subnetwork ID, and Host ID. The subnet field takes the space that it needs by reducing the Host ID field. Individual organization assign the Subnet ID and the Host identifiers for the host on each subnet.

A subnet masks differentiates between various subnets. The subnet mask is a 32-bit number with all ones in the Network ID and Subnetwork ID fields and all zeros in the Host ID field. A host uses a logical AND function on a subnetwork mask to a particular address to determine if it can deliver the datagram to a host on the current subnet or if it must send the datagram to a router for delivery.

For example, you can subnet the Class B network 128.10.0.0 using the first 8 bits of the host-id, to span 254 different physical networks. In this case the subnet mask is 255.255.255.0 and the subnetworks are, 128.10.1.0, 128.10.2.0, and on through 128.10.254.0.

Each of the subnetworks can have up to 254 different hosts; for example, 128.10.XXX.1, 128.10.XXX.2, and on through 128.10.XXX.254.

If you need more hosts in a subnet then you can use fewer host-id bits when you establish your subnets. For example, if you use the subnet mask 255.255.254.0, you can have 126 different subnets with up to 510 hosts in each one.

shows dividing a single Class B network into two subnetworks. In this example, all Gateways except Gateway A route as if there was a single physical network. Gateway A is physically interconnected between the networks.

Changing role of IP addresses

Each TCP/IP network interface requires a unique IP address. IP routers use these addresses to forward packets across the various network devices such as cables or satellite relay stations that connect communicating systems. A 32-bit long IPv4 address can accommodate several million such interconnections.

Today the Internet has the potential for hundreds of millions of connections. And too, today we also have multiple Intranets (an organizations internal network). The size of an Intranet is limited only by the size of the organization.

Organizational and non-organizational network user

Currently, within the IPv4 community, there are three types of organizational and non-organizational network users all requiring addresses:

• Users within an organization that is connected to the Internet. Within this first group there are potentially millions of organizations each with thousands, or perhaps million of individual users. As an Internet member, each Intranet must have its own unique address. Within an Intranet, each interface address (also referred to as the host number) must also be unique.
• Users within an organization that is not connected to the internet. This group too potential consists of millions of users. An organization signing a service contract with an ISP and installing some network hardware, can instantly make participants of this group members of the Internet community. It is possible that many members of this group will need their Intranet address changed to make them unique within the Internet community
• Individual users connecting to the Internet from home or while traveling through modems or through packet radio links. For members of this group there are questions about which host numbers they should use, where they should use the host numbers, and how they should administer their address or addresses as they move about.

Interpreting the IPv4 address space

The interpretation of the 32-bit IP version 4 address space has undergone some substantial changes over the last few years. Brian Carpenter points out in RFC 2101 "IPv4 Address Behavior Today", that the concept of a network address consists of at least two notions; an identifier and a locator.

• Identifiers

Identifiers must be unique with respect to each set of inter-communicating hosts. An identifier consists of a bit string that two communicating hosts use throughout the lifetime of a particular communication session. This bit string is used for authentication; it identifies the hosts to each other and verifies the source of incoming packets as really having come from the other end of the communication. Identifiers must be valid for the maximum lifetime of a communication between two hosts.

Ideally, identifiers should be assigned when a host becomes part of a network for the first time, never change, and never be re-used.

• Locators

Locators must be unique with respect to each set of inter-communicating routers. This uniqueness could more than one routing realm. A locator consist of a bit string that identifies where to deliver a particular packet. The locator serves to locate the attachment point in the Internet topology of the destination host. IP routing protocols interpret IPv4 addresses as locators. The IP routing protocols build their routing tables based on which routers claim to know a route towards the locators of particular hosts. Locators must be valid as long as the routing mechanisms requires.

Ideally, locators should describe the host's position in the network's topology and should change whenever the topology changes.

IPv4 uses the same address space and the same source and destination address fields in the IP header for both identifiers and locators.

In the traditional Internet a host's identifier is identical to its locator and is unambiguous (spatially unique) and constant (temporally unique). The spatial uniqueness of an address meant that the address could simultaneously serve as an interface identifier, a host identifier, and the key to the routing table. Temporal uniqueness of an address meant that there was no need for TCP implementations to maintain state regarding identity of the far end, other than the IP address. Ideally you could use IP addresses both for end-to-end IP security and for binding upper layer sessions.

However, as the Internet evolved, using IPv4 addresses as locators has usually been considered more important than using them as identifiers. For example, a lot more work has been done in developing protocols that concern delivery of a packet than on protocols concerning other aspect of address usage.

Today an IPv4 address is no longer a globally unique locator or globally unique identifier.

Non-globally unique locators

Based on RFC 1918, corporate Intranets can now legitimately re-use a subset of the IPv4 address space and thus form multiple routing realms. Communication between the routing realms occurs through the use of a variety of devices and applications. Some applications carry IP addresses at the application layer and some do not do so.

At one end of the spectrum, an application-layer gateway (ALG) could enable communication between the realms. At the other end of the spectrum, a Network Address Translator (NAT) [RFC 1631] could enable communication between the realms.

Sometimes an organization has a goal of TCP/IP-OSI coexistence. Protocol-based approaches include using dual stacks or application-layer gateways.

Application-layer gateways act as origination and termination points for communications between realms. They are Internet hosts is each realm and understand the application layer data stream. The application-layer gateways convert protocol data units (PDUs) from one stack's application protocol to the other's. With application-layer gateways it is possible to communicate from any TCP/IP system to any OSI system. It is not necessary to choose between protocols, because either application protocol works on either stack. is a representation of an application gateway node.

Usually with an application-layer gateway you do not have to add anything to, or otherwise modify, the end systems. This is because the application-layer gateway that includes both protocol stacks sits between the systems and handles all of the protocol conversion.

It is possible to lose functionality in the conversion from one application protocol to another because of imperfect mapping between the two protocols. In addition, if the gateway is not powerful enough, it is possible for a bottleneck to occur that can impact the performance of the gateway.

A NAT device does not understand the application-layer data stream, instead, it modifies the network and the transport layer headers. In other words, a NAT changes the source IPv4 address in packets going towards the Internet, and changes the destination IPv4 address in packets coming from the Internet.

Communicating through either ALGs or NATs involves changes to the network header and source and destination addresses. Communication through ALGs or NATs also involves changes to the transport header. Confidential communication under these circumstances does not seem possible. Secure IP, when used for confidentiality, encrypts the entire transport layer end-to-end.

Interconnecting routing realms using application-layer gateways or network layer translators relies on the Domain Name System. For example, fully qualified domain names need to be unique across interconnected sets of routing realms even if the network layer addresses are not unique. It is likely that a site running an ALG or NAT will need to run two DNS servers, one inside and one outside the NAT or ALG. These DNS servers would give different answers to identical queries.

In principle, interconnecting routing realms with either ALGs or NATs will have less functionality than if those Intranets were directly connected. However, in practice the difference in functionality may or may not make any difference because of individual circumstances.

Non-globally unique identifiers

Previously the IANA assigned network addresses in chronological order and the address assignment had nothing to do with the location of a recipient with respect to network topology. Since the advent of Classless Inter Domain Routing (CIDR), Dynamic Host Configuration Protocol (DHCP), and Point-to-Point Protocol (PPP), renumbering a given address space is becoming common. DHCP and PPP both encourage dynamic address allocation.

Hierarchical routing as established by CIDR [RFC 1518] improves scaling of routing within a routing realm, and within the Internet. CIDR assumes that address allocation reflects network topology as much as possible. Rather than being contained within a single organization, CIDR address aggregation can span multiple organizations such as an internet Service Provider and its subscribers. If a subscriber changes its provider, the subscriber probably needs to renumber to avoid adding overhead in the Internet routing system

IP address significance has indeed been changed. The uniqueness of an address is no longer assured and indeed can be quit short. In this case an address is no longer a good identifier and has some implications on end-to-end security.

Multicast and Anycast addresses

The introduction of multicast addressing with RFC 1112 expanded the meaning of IP addresses into including source and destination addresses. A multicast destination address is a locator for a group of host that can be topographically separated over a wide area. A multicast destination address lifetime can be short. In addition, a multicast destination address can traverse a NAT, and is not necessarily restricted to an Intranet or to the Internet.

An anycast address semantically locates any of a group of systems that perform equivalent functions. This kind of address is always a locator and is never an identifier because it does not uniquely identify a host.

Introducing IPv6 addressing

The IPv6 addressing scheme more closely accommodates the different user types because it is based on the demographic nature of the community it is to serve. Additionally, IPv6 addressing provides for compatibility and interoperability with today's IPv4 network architecture. This ability of IPv6 to coexist indefinitely with IPv4 in both host computers and routers, helps to preserve the world's enormous investment in TCP/IP.

IPv6 address allocation management

As the Internet transitions to IPv6, the plan for distributed allocation and assignment of the IPv4 address space established in RFC1466 forms a base for the distributed allocation and assignment of the IPv6 address space. The IPv6 address space must be managed for the good of the Internet community.

The Internet community recognizes that good management requires at least some central authority over the delegation and allocation of the address space. Therefore, the Internet community has delegated the responsibility for the management of the IPv6 address space to the Internet Assigned Number Authority (IANA.). The IANA is the principal registry for the IPv6 address space. As representatives of the Internet community, the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) provide advice to the IANA from time-to-time about management of the IPv6 address space.

The IANA will carry out address allocation management with an element of central authority over the delegation to regional registries. These regional registries will make specific address allocations to network service providers and other subregional registries.

As shown in the IANA delegates to regional registries the task of making specific address allocations to network service providers and other subregional registries. Individuals and organizations that need IP addresses obtain them from their internet service provider for from the appropriate registry. The IANA serves as the default registry in cases where no delegated registration authority has been identified.

The IANA can revoke address space it has assigned to an registry if the IANA believes that the registry has mishandled the address space. The IANA is obligate to due notice and due consideration of the operational implications when it revokes delegated address space. The IANA is also obligated to make every effort not to revoke addresses that are in active use unless there are overwhelming technical reasons for doing so.

Currently there are three Regional Registries: INTERNIC, RIPE NCC, and APNIC. The IANA itself can also directly allocated addresses. shows this division of address allocation and the corresponding Registry ID value for each Regional Registry. The IANA can allocate a Regional Registry more than one block of addresses. As a result, the Registry would have multiple Registry IDs associated with it. The Registry and other IDs associated with IPv6 addresses are described later in this chapter.

IANA responsibilities

The IANA is responsible for the development of:

• A plan for assignment of IPv6 addresses
• A method for the automatic allocation of IPv6 addresses to registries, ISPs, organizations, and individuals that already hold IPv4 address.
• A set of procedures for mediation and appeals concerning the delegation and revocation of IP address space assignments.

National Registries

The IANA allows Regional Registries to allocate blocks of address space to several National Registries. National Registries assign address space to individual providers within the country that the National Registry serves.

IPv6 addressing model

Technically IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. This is equivalent to an IPv4 address space squared twice; a very large number of addresses indeed. It should be noted however that the size of the address is less important than its structure. The emerging IPv6 protocols define three types of addresses:

• Unicast addresses of which IPv6 recognizes are three major types. A unicast address is an identifier for a single interface. The three types of unicast address consist of provider-based addresses, site-local-use addresses, and link-local-use addresses.

When you send a packet to a unicast address, the protocol routes the packet to the interface identified by that address.

• Anycast addresses which are a new kind of address. An anycast address is an identifier (a single value) assigned to a more than one interface. The set of interfaces assigned an anycast address typically belong to more than one computer.

When you send a packet to an anycast address, the routing protocol currently in use delivers the packet to the nearest interface identified by that address. The nearest interface is determined according to the particular routing protocol’s measure of distance.

• Multicast addresses whose address format allows for possibly trillions of multicast group codes. A multicast address is an identifier for a set of interfaces that typically belong to different nodes. Each multicast group code identifies two or more packet recipients. In addition a particular multicast address can be confined to a single system, restricted within a specific site, associated with a particular network link, or distributed worldwide.

When you send a packet to a multicast address, the protocol delivers the packet to all interfaces identified by that address.

IPv6 does not have broadcast addresses. The new IPv6 multicast addresses supersede broadcast addresses as used in IPv4.

IPv6 use the same model for subnets as IPv4:

• You can associate a subnet with only one link
• You can assign multiple subnets to the same link.

Addressing Rules

All types of IPv6 Addresses are assigned to interfaces, not nodes. Each interface belongs to a single node. This means that you can identify a node by any of its interfaces’ unicast addresses.

An IPv6 unicast address refers to a single interface. A single interface may have multiple IPv6 addresses of any of the IPv6 address types. The two exceptions to this rule are as follows:

1. You can assign a single unicast address to multiple physical interfaces under the following conditions:

• When you want load-sharing over multiple physical interfaces
• When the implementation treats the multiple physical interfaces as a single interface when it presents that interface to the internet layer

1. Routers can have unnumbered interfaces on point-to-point links. This means that no IPv6 address is assigned to the interface.

Point-to-point router interfaces do not need addresses if those interfaces are not the source or destination of IPv6 datagrams.

Text representations of IPv6 addresses

Traditionally IPv4 addresses have been represented in dotted decimal notation; each 32-bit address is divided into four 8-bit sections and a decimal number between 0 and 255 represents each section; for example 192.168.95.143.

The 128-bit IPv6 address uses a different method to represent the address. In fact, there are three forms for representing IPv6 address as text strings.

• The preferred form is the full IPv6 address in hexadecimal values. As defined in RFC 1884, the preferred form is X:X:X:X:X:X:X:X, where the X represent the hexadecimal values of the eight 16-bit pieces of the address. For example, an IPv6 address could have the following form:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

A colon separates each section and four hexadecimal numbers represent each 16-bit section. Sometimes a 16-bit section contains leading zero’s. It is not necessary to include the leading zero’s in an individual field, but there must be at least one numeral in every field in the text representation of an address as shown in the following simplified example IPv6 address:

1080:0:0:0:8:800:200C:417A

• The compressed form that substitutes zero strings with a special syntax to compress the zeros. This form uses double colons ( :: ) to indicate multiple groups of 16-bit zeros. You can use the double colon ( :: ) only once in an address. For example you can further simplify the address:

1080:0:0:0:8:800:200C:417A

described previously to

1080::8:800:200C:417A.

You can also use the double colon to compress the leading and/or trailing zeros in an address. shows the simplification of some IPv6 addresses using the double colon.

• The mixed form that is convenient to use for mixed environments of IPv4 and IPv6 nodes. This form takes the representation of X:X:X:X:X:X:D.D.D.D. The Xs represent the hexadecimal values of the six high-order 16-bit pieces of the address. The Ds represent the standard IPv4 decimal value representation of the four low-order 8-bit pieces of the address. shows some representative mixed form addresses in both a simplified and compressed form.

IPv6 address prefixes

IPv6, like IPv4 can have an address prefix. For our purposes, and IPv6 address prefix is defined as an IPv6 address and some indication of the leftmost contiguous significant bits within this address portion. The representation of an IPv6 address prefix is similar to the way IPv4 addresses prefixes are written in CIDR notation. An IPv6 address prefix takes the form shown in .

You can write the IPv6 address here using any of the address forms described previously (preferred, compressed, or mixed) with this difference: if the written address ends in a double colon ( :: ), you can omit the trailing double colon.

The prefix-length is a decimal value. It specifies the number of leftmost contiguous bits of the address that comprise the prefix. The following example shows the various legal representations the 60-bit prefix 12AB00000000CD3.

Example -1 Example of legal representation of a 60-bit prefix

12AB:0000:0000:CD30:0000:0000:0000:0000/60

12AB::CD30:0:0:0:0/60

12AB:0:0:CD30::/60

12AB:0:0:CD30/60

shows some representations that are not legal for this 60-bit prefix.

When you write a node address and the node's subnet prefix, you can combine and abbreviate them as shown in.

IPv6 address type representation and allocation

The leading bits of an IPv6 address indicate the specific type address. The variable-length field comprising these leading bits is called the Format Prefix (FP). RFC 1884 and shows the initial allocation of these prefixes.

The loopback address, the IPv6 Addresses with Embedded IPv4 Addresses, and the unspecified address all of which are discussed later in this chapter are assigned out of the 0000 0000 format prefix space.

Fifteen percent of the address space is initially allocated. This initial allocation of the IPv6 address space supports the direct allocation of provider addresses, local use addresses, and multicast addresses. In addition, as the table shows, there is reserved space for NSAP addresses, IPX addresses, and geographic addresses. The remainder of the address space is unassigned for future use. Such future use might include the expansion of existing uses and the introduction of new uses such as separate locators and identifiers.

The value of the high-order octet of the addresses distinguishes a unicast addresses from a multicast address. A value of FF (11111111) identifies an address as a multicast address; any other value identifies an address as a unicast address. Because Anycast addresses come from the unicast address space, they are syntactically identical to unicast addresses.

Table -6 Initial IPv6 address allocation

(IP6T6-06-addr-allo.doc)

Unicast addresses

The IPv6 unicast address is contiguous bit-wise maskable, and in this respect is similar to IPv4 addresses under Classless Inter Domain Routing [CIDR]. IPv6 supports three major types of unicast addresses as follows:

• Provider-based unicast addresses. Internet Service Providers (ISPs) assign these addresses to an organization. These address offer globally unique Internet addresses to all of the organization's members. Provider-based unicast addresses provide easy integration within the worldwide Internet community. The development of CIDR for IPv4 put the mechanisms in place for assigning these addresses through ISPs.
• Site-local-use addresses. This type of address can be assigned to network devices within an isolated Intranet. The organization can easily join the Internet community at a later time without adverse effect to their addressing structure. All of the organizations site-wide local addresses automatically become globally unique provider-based addresses with one administrative operation.
• Link-local-use addresses. This type of address is for use by individuals on a single communications link, such as mobile laptop computer users connected through phone lines (voice or ISDN) or radio links.

But that is not all, IPv6 also supports a number of other unicast address assignment forms. These include but are not limited to unspecified addresses, loopback addresses, NSAP addresses, IPX addresses, geographic-based addresses, and IPv6 addresses with embedded IPv4 addresses.

RFC 1887 "An Architecture for IPv6 Unicast Address Allocation", discusses some administrative requirements for obtaining and allocating IPv6 addresses. It also considers the technical aspect of such assignments mostly having to do with routing, both within and between routing domains.

Unicast address formats

The function of a node, if it is a host or a router for instance, determines how much knowledge that node has about the internal structure of IPv6 address. At the most basic level, a node could consider that the unicast address has no internal structure. This most simple form of unicast address has no address-defined hierarchy; and assumes the from shown in.

A different host might be aware of subnet prefixes for the links it is attached to. In this case, the unicast address would specify a subnet prefix within the 128-bit address. This divides the address into a subnet prefix with n-bits and an interface ID with 128-n bits as shown in.

Routers for example, can know of other hierarchical boundaries in the unicast address. These boundaries differ depending on where the router sits in the routing hierarchy.

Some unicast address formats will be more prevalent then others. A simple form of address autoconfiguration is possible using unique global interface identifies. For example, a node could listen to router advertisements messages sent by a router on its attached links to discover a subnet ID. The node could then fabricate an IPv6 address for itself by using its IEEE MAC address as the interface ID on that subnet.

shows a format for a unicast address for use on LANs and other environments where IEEE 802 MAC addresses are common. In this example the address structure now includes a subscriber prefix consisting of n-bits, a subnet ID of 80-n bits, and an interface ID. In this example the 48-bit Interface ID is an IEEE-802 MAC address. In other environments, other types of link layer addresses such as E.164 can be used for the interface ID.

Sometimes a site or organization needs additional layer of internal hierarchy. In this case, the unicast address can be further restructured by splitting the subnet ID portion into an area ID of n bits, and a subnet ID of n bits as shown in . The subscriber prefix of this address format is s bits while the Interface ID is defined as 128-s-n-m bits.

If an organization wanted more space for the additional layers of internal hierarchy, it could consider using a interface ID that was smaller than a 48-bit IEEE 802 MAC address. Such interface IDs could be administratively created and maintained by the site or organization.

The unspecified address

RFC 1884 defines some special addresses. One of the, the address 0:0:0:0:0:0:0:0 is called the unspecified address (). The unspecified address can also be represented as 0::0. This address indicates the absence of an address and might be used upon startup if a node does not yet have an assigned address. For example the unspecified address could be in the Source Address field of an IPv6 datagram sent by an initializing host before it has learned its own address. The unspecified address is never used as the destination address in either IPv6 datagrams or in IPv6 Routing Headers.

The loopback address

The unicast loopback address 0:0:0:0:0:0:0:1 is also represented as 0::1 (). A node uses this loopback address to send an IPv6 datagram to itself.

Observe the following rules when using the loopback address; never assign the loopback address:

• To any interface
• As the source address in an IPv6 datagrams sent outside a single node
• As the destination address in an IPv6 datagram sent outside a single node

IPv6 addresses with embedded IPv4 addresses

The transition mechanism for IPv4 to IPv6 defines two transition addresses for IPv4/IPv6 transition networks. The first mechanisms permits hosts and routers to tunnel IPv6 packets over the IPv4 routing infrastructure. IPv6 nodes that use this tunneling technique are assigned special IPv6 unicast addresses that carry an IPv4 address in the low-order 32-bits (). The node uses the entire 128-bit IPv4-compatible IPv6 address as the node's IPv6 address. The IPv4 address embedded in low-order 32-bits serves as the node's IPv4 address. Devices at the edge of IPv4 would use this special unicast address structure. This type of address is called an IPv4-compatible IPv6 address. The prefix to an IPv4-compatible IPv6 address is 96 bits of all zeros.

The second type of transition address is called an IPv4-mapped IPv6 address. This second type of address also holds an embedded IPv4 address. IPv4-only node that do not support IPv6 use this unicast address format. For example, an IPv6 host would use an IPv4-mapped IPv6 address to communicate with an IPv4 host that does not support IPv6. IPv4-mapped IPv6 addresses are never assigned to IPv6 nodes.

An IPv4-mapped IPv6 address has the format shown in. The prefix to an IPv4-mapped IPv6 address is 80 bits of zeros followed by 16 bits of ones.

Network Service Access Point addresses

Network Service Access Point (NSAP) address map into IPv6 addresses with the formation shown in. This address format begins with the seven bit sequence 0000001.

The NSAP address guidelines are quite similar to the CIDR RFC 1888 defines four mechanisms for NSAP-IPv6 mapping that accommodates the different sizes and different approaches described in these two addressing schemes.

Chapter 16 "Making the Transition to IPv6 Networking" briefly describes NSAP address mapping mechanisms described in RFC 1888 and identified in the following list

• Restricted NSAP address mapping into 16-octet IPv6 address. The term restricted indicates that this format is currently restricted to a subset of the ICD and DCC formats.
• Truncated NSAP address for routing, full NSAP address in IPv6 option. The term truncated indicates that a destination option with a complete NSAP address or an encapsulated CLNP packet is present.
• Normal IPv6 address, full NSAP address in IPv6 option. This mechanism relies on either of two destination option configurations.
• An IPv6 source node using normal unicast or anycast IPv6 addresses to supply an NSAP destination option header to the IPv6 destination node.
• An IPv6 source node using a truncated NSAP address in place of a normal IPv6 address as the destination.
• IPv6 address carried as OSI address. This mapping mechanism allows the embedding of an IPv6 addresses inside a 20-octet NSAP addresses

Internetwork Packet Exchange addresses

Internetwork Packet Exchange (IXP) addresses would be mapped into IPv6 addresses with a format that begins with seven bit sequence 0000010 as shown in.

Provider-based global unicast addresses

The Provider-based global unicast address begins with the value 010 and can contain many other fields. The initial assignment plan for these unicast addresses is similar to assignment of IPv4 addresses under the CIDR scheme [CIDR]. It is expected that this provider-based global unicast address format will be widely used for IPv6 nodes connected to the Internet. The provider-based address format consists of the following parts: Format Prefix, Registry ID, Provider ID, Subscriber ID, and an Intra-Subscriber part. The IPv6 global provider-based unicast address format is as shown in.

Provider-based address administration consists of a three level hierarchy: registry, provider, and subscriber. The provider-based address format allows flexible address allocation at each level of the address administration hierarchy and supports a wide spectrum of demands for addresses.

Format prefix field

The leading bits of an IPv6 address indicate the specific type address. The variable-length field comprising these leading bits is called the Format Prefix (FP). shown previously lists the initial allocation of these prefixes.

The Internet routing system doesn't make any assumptions about the specific structure and semantics of an IPv6 address, except for the structure and semantics of the Format Prefix part of the address, in this case 010, and the use of the "longest prefix match" algorithm on arbitrary bit boundaries for making a forwarding decision.

Registry ID

The Registry ID field identifies the registry that assigns the provider portion of the address. The Registry ID portion helps to facilitate geographic address allocation and the operations of the distributed Regional Registries.

NOTE: The term "registry prefix" refers to the high-order part of the address up to and including the registry ID.

The IANA) is the principal registry for the IPv6 address space. The IANA can allocate blocks of IPv6 addresses and delegate the assignment of those blocks to qualified Regional Registries. Currently there are three Regional Registries: INTERNIC, RIPE NCC, and APNIC. The IANA itself can also directly allocated addresses. shown previously, lists the Regional Registries and the corresponding Registry ID value for each one. If a registry has responsibility for more than one block of addresses, that registry would have multiple Registry IDs associated with it.

Individual registries have the responsibility of defining how much address space is given to providers and their subscribers. It is important that a registry design its Provider ID space to allow flexibility and at the same time use the address space efficiently.

Provider ID

The provider ID identifies the specific provider that assigns the subscriber portion of the address.

NOTE: The term "provider prefix" refers to the high-order part of the address up to and including the provider ID.

The value of the Provider ID is associated with an address block when a registry allocates that block to a particular provider. This value identifies that provider within the registry. Note that some subscribers might obtain their address space directly form a registry. Doing so makes their addresses independent of providers.

Subscriber ID

The subscriber ID field identifies a particular subscriber among multiple subscribers. The provider identified by the provider ID assigns the subscriber ID.

NOTE: The term "subscriber prefix" refers to the high-order part of the address up to and including the Subscriber ID.

Each provider specifies the structure and assignment strategy of Subscriber ID's. For example, a provider might decide to group its subscribers into regions. To accomplish this, the provider could allocate a small number of high-order bits of the Subscriber ID to a subscriber-Region ID. The purpose here would be to identify a group of subscriber that are close together topologically.

Intra-Subscriber

Individual subscribers define the intra-subscriber portion of the address. The provider-based unicast address format leaves 64 bits for the local portion of the address. Subscribers could divide the intra-subscriber portion of the address into a subnet ID and an interface ID. The subnet ID would identify a specific physical link and the interface ID would identify a single interface on that subnet.

For example, a subscriber could use the IPv6 auto-configuration capabilities described in RFC 1971 and generate address. This process could use link-specific addresses such as 48 bit IEEE-802 MAC address as the Interface ID. In this case 16 bits are left for the Subnet ID.

In this example, Providers could assign a subscriber a block of subscriber prefixes if a subscriber wanted to continue to use 48 bit IEEE-802 MAC addresses for interface IDs or if the subscriber needed additional subnets.

Additionally, a very large subscriber could have its own Provider ID. This subscriber would have additional bits of address space to create its own local address hierarchy.

Local-use addresses

RFC 1884 specifies two addresses for local use only; these are Link-Local and Site-Local. Link-Local addresses are for use on a single link. Link-local link addresses take the format shown in. The primary purpose for using a Link-Local address is for auto-address configuration, neighbor discovery, or when no routers are present. Routers never forward any packets with link-local source addresses. The Link-Local address begins with the binary value 1111111010 and includes an interface ID field.

A Site-Local address is for use in a single site. In particular, Site-Local address can be used by an organization that has not yet connected to the Internet. By using a Site-Local addresses, an organization does not need to request an address prefix from the global Internet address space. Site-Local addresses have the format shown in.

If the organization connects to the global Internet, it can then form global addresses by obtaining a subscriber prefix from their provider and replacing the site-local prefix with a subscriber prefix.

Routers never forward any packets with site-local source addresses outside of the site. A Site-Local address begins with the binary value 1111111011, and includes both a Subnet ID field and an Interface ID field.

Anycast addresses

Anycast addresses are a new kind of address. You can assign an anycast address to more than one interface. The set of interfaces assigned an anycast address typically belong to more than one computer.

When you send a packet to an anycast address, the routing protocol currently in use delivers the packet to the nearest interface identified by that address. The nearest interface is determined according to the particular routing protocol’s measure of distance.

Anycast addresses come from the unicast address space and can use any of the unicast address formats. An anycast address is therefore syntactically indistinguishable from unicast addresses. Assigning a unicast address to more than one interface turns that address into an anycast address. However, nodes to which you assign that address must be explicitly configured to know that it is an anycast address.

NOTE: An anycast address can be assigned to an IPv6 router only, it must not be assigned to an IPv6 host. Additionally, never use any anycast address as the source address of an IPv6 packet.

Anycast address prefix P

For any assigned anycast address, there is a longest address prefix P. The longest address prefix P identifies the topological region where the interfaces associated with the anycast address reside. Within the topological region, each member of the anycast set is considered a separate entity in the routing system. A routing advertisement that goes outside the topological region is an aggregate for prefix P.

If the members of the anycast set have no topological locality, the prefix P of the anycast set is null. In this case, the anycast address must be advertised as a separate routing entry throughout the entire internet. This could limit the number of global anycast sets that could be supported. It is quite possible that support for global anycast sets may be unavailable or very restricted.

Anycast address uses

RFC 1884 identifies several uses for anycast addresses; these include using anycast addressing to identify:

• A set of routers belonging to a particular Internet service provider
• A set of routers attached to a particular subnet
• A set of routers providing entry into a particular routing domain.

For example, an internet service provider might use anycast addresses to identify its set of routers. Using such addresses as an intermediate address in an IPv6 routing header could cause the routing protocols to deliver the packet through a particular provide or sequence of providers.

Required anycast address

One anycast address is predefined and required: the subnet-Router anycast address. shows the format for this anycast address. In this format, the subnet prefix identifies a specific link. This address begins with a variable-length subnet prefix and ends with zeros as a filler.

This form of anycast address is syntactically the same as a unicast address for an interface on the link that has the interface identifier set to zero. A packet sent to the Subnet-Router anycast address is delivered to one router on the subnet. All routers on that subnet must support this anycast address. This address is intended to be used for applications where a node needs to communicate with a member of a group of routers on a remote subnet.

Multicast addresses

An IPv6 multicast address identifies a group of nodes; more specifically, a multicast address identifies a set of interfaces that usually belong to different nodes. A multicast group consists of two or more interfaces. Multicast addressing in IPv6 supersedes the broadcast addressing of IPv4. (There is no broadcast addressing in IPv6.) All interfaces identified by the multicast address receive packets sent to that multicast address.

Multicast address format

Multicast address have the format shown in. A multicast address can be assigned to a single system, restricted to a specific site, associated with a particular network link, or distributed worldwide. Multicast addresses must not be used as source addresses in IPv6 datagrams or appear in any routing header.

A value of FF (11111111) identifies an address as a multicast address. The IPv6 multicast address has three other fields, the Flgs field, Scop field, and Group ID field.

The Flgs field consist of four flags. The high-order three flags should always initialize to 0 and are reserved.

• The T flag when set to 0 indicates a permanently-assigned multicast address. Such an address is known as a well-known multicast address. The global internet numbering authority assigns the well-known multicast addresses.
• The T flag when set to 1 indicates a non-permanently assigned multicast address. Such an address is known as a transient multicast address.

The Scop value limits the scope of the multicast group. lists the settings for this 4-bit multicast scope value.

The group ID identifies the multicast group within the scope. The group can be either a permanent multicast group or a transient multicast group.

Non-permanently and permanently assigned multicast addresses

Non-permanently-assigned multicast addresses (transient multicast addresses) have meaning only within a given scope. A group at one site using a non-permanent site-local address multicast address has no relationship to a:

• Group at a different site that is using the same address
• Non- permanent group with the same group ID but is using a different scope
• Permanent group the has the same group ID

A permanently-assigned multicast address is independent of the scope value. shows the effect of assigning an NTP servers group a permanent multicast address with a group ID of 43 (hex).

Predefined well-known multicast addresses

lists the predefined well-known multicast address types and addresses.

The solicited-node multicast address consists of the low-order 32-bits of the address appended to the 96-bit prefix FF02:0:0:0:0:1. This produces a multicast address in the range in the range FF02:0:0:0:0:1:0000:0000 to FF02:0:0:0:0:1:FFFF:FFFF. For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C.

IPv6 addresses that differ only in the high-order bits map to the same solicited-node address. This reduces the number of multicast addresses a node must join.

NOTE: An IPv6 node is required to compute and support a Solicited-Node multicast addresses for every unicast and anycast address it is assigned.

A node's required addresses

There are some address requirements for IPv6 and IPv6/IPv4 hosts and routers. First of all, the only predefined address prefixes in an implementation include the:

• Unspecified Address
• Loopback Address
• Multicast Prefix (FF)
• Local-Use Prefixes (Link-Local and Site-Local)
• Pre-Defined Multicast Addresses
• IPv4-Compatible Prefixes

Implementations should assume all other addresses are unicast unless specifically configured as anycast addresses. lists the addresses that a host or a router is required to recognize as identifying itself.

Address resolution

The Domain Name System (DNS) maps hostnames into both IPv4 and IPv6 addresses. DNS lists the 32-bit IPv4 addresses in A resource records. DNS has defined a new resource record type named AAAA to store a host's 128-bit IPv6 address. Host with more than one IPv6 address have and equal number of A or AAAA records. Resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records help IPv6/IPv4 nodes interoperate directly with both IPv4 and IPv6 nodes.

From here …

This chapter introduced the new IPv6 address format, discussed IPv6 address allocation management techniques and provided details and examples of the different IPv6 address types. For additional information, you may want to see the following:

• Chapter 3, "IPv4 Limitations and Constraints" describes the IPv4 addressing system and introduces IPv6 enhanced address including issues around DHCP, VLANS, IP address/DNS name assignment, and recycling of IP addresses.
• Chapter 7, "IPv6 Headers" describes the new IPv6 header and header extension options.
• Chapter 8 "IPv6 and Intranetwork Communications" discusses the impact of IPv6 on the RFC routing including the Internet Domain Routing Protocol (IDRP) for IPv4 and IPv6, the Routing Information Protocol (RIPing) for IPv6, and Open Shortest Path First (OSPF) Protocol for IPv6.
• Chapter 14 "Auto Configuration" describes autoconfiguration for IPv6 including information about link-local addresses, determining what information should be autoconfigured, and if addresses should be obtained through the stateless mechanism, the stateful mechanism, or both.
• Chapter 15 "IP Address Management Preparing forIPv4 and IPv6" describes the role of DHCP, CIDR, and other address configuration options and some strategies to conserve the IPv4 address space, for renumbering networks, and minimizing the impact of migrating to IPv6.
• Chapter 16, "Making the Transition to IPv6" introduces some guidelines for migrating to IPv6, discusses IPv6-over-IPv4 tunneling, upgrade dependencies, OSI NSAP address mapping, and IPv4-mapped IPv6 addresses and use of DNS AAAA records with these address formats.
• Chapter 18, "Possible Alternative to IPV6 to Handle Addressing" discusses the pros and cons of some alternative addressing schemes including NAT.