Deploying IPv6 Networks [Electronic resources] نسخه متنی

Address Policies and Registration Process

To fully understand the IPv6 addressing model, you must become familiar with the various IETF-related documents as introduced in Chapter 2, "An IPv6 Refresher," and throughout the first part of this book. The centerpiece is the IPv6 address architecture as defined in RFC 3513. An understanding of the address architecture needs to be complemented by an understanding of the current policies for IPv6 address-space allocation.

The IETF defines an IPv6 global unicast address format in RFC 3587. This RFC documents an IPv6 addressing structure that is compliant with the allocation of IPv6 addresses related to policy and to the stewardship of the IP similar to IPv4. The resulting format is an IPv6 global unicast address under the 2000::/3 prefix that is currently being delegated by the Internet Assigned Numbers Authority (IANA). The IPv6 address-management function was formally delegated to IANA in December 1995 as documented in RFC 1881. Table 12-6 presents the IPv6 address-space distribution as documented at http://www.iana.org/assignments/ipv6-address-space.

Note

The following notes add specific details on addressing architecture:

The "unspecified address," the "loopback address," and the IPv6_addresses with embedded IPv4 addresses are assigned out of the 0000::/8 address block.

0200::/7 was previously defined as an OSI NSAP-mapped prefix set in RFC 1888. This definition has been deprecated as of December 2004 by RFC-carpenter-obsolete-1888-01.txt.

The IPv6 unicast space encompasses the entire IPv6 address range_with the exception of FF00::/8.

FEC0::/10 was previously defined as a site-local scoped address_prefix. This definition has been deprecated as of September 2004 by RFC 3879.

0000::/96 was previously defined as the "IPv4-compatible IPv6_address" prefix. This definition has been deprecated by RFC-ietf-ipv6-addr-arch-v4-04.txt.

IANA allocates IPv6 prefixes to the five Regional Registries (RIRs) based on their needs:

AFRINIC http://www.afrinic.net

APNIC http://www.apnic.net

ARIN http://www.arin.net

LACNIC http://www.lacnic.net

RIPE http://www.ripe.net

The list of IANA prefixes assigned to the RIRs can be found at http://www.iana.org/assignments/ipv6-unicast-address-assignments

Note

Some prefixes might have a specific purpose, such as the following:

3FFE::/16 is an experimental allocation to the 6Bone as described in RFC 2471. This prefix will be returned to the unassigned address pool when the 6Bone is phased out on June 6, 2006 (see RFC 3701).

2001:0DB8::/32 has been assigned as a NONROUTABLE range to be used for documentation purpose as described in RFC 3849.

2002::/16 is reserved for use in 6to4 deployments based on RFC 3056.

IANA also handles the allocations of the IPv6 anycast and global IPv6 multicast address space. The respective allocation policies are described at the following websites:

IPv6 anycast address allocation http://www.iana.org/assignments/ipv6-anycast-addresses

Global IPv6 multicast address allocation http://www.iana.org/assignments/ipv6-multicast-addresses

The RIRs allocate, via the Local Internet Registries (LIRs), a ::/32 prefix (formerly ::/35) to Internet service providers (ISPs), government agencies, and National Research & Education Networks (NRENs). Recently, larger address space was allocated to ISPs and government agencies, such as the following:

KORNET 2400::/20

Deutsche Telekom AG 2003::/19

You can find a current list of allocations at http://www.ripe.net/rs/ipv6/stats/.

The prefix-allocation policies are well described by the RIR documents:

APNIC at http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599l

ARIN at http://www.arin.net/registration/ipv6/

RIPE at http://www.ripe.net/ripe/docs/ipv6-policyl

At the time of this writing, contrary to IPv4, an end user such as an enterprise cannot generally get a prefix from a registry, although there are historical exceptions. This rule, which intended to enforce route aggregation through assignment policies, is a significant departure from the IPv4 address allocation mechanisms. Its impact on network operations has to be clearly understood well before the need for integrating IPv6 becomes imminent.

There have been and there continue to be many discussions between experts on the topic of IPv6 address-allocation policies. RFC 3177 documents the current recommendations to the RIRs on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of the following:

/48 in the general case, except for large subscribers

/64 when it is known that one and only one subnet is needed by design

/128 when it is absolutely known that one and only one device is connecting

The last two rules are practical, because they are based on specific boundaries. Nevertheless, departures from these recommendations are possible (discussion about shorter prefix than /48 are still ongoing) because at this level in a network, address assignment depends on the business and design models of each service provider or enterprise.

To conclude, there is a need to add to the equipment- and operations-related costs the cost of subscribing an IPv6 prefix. For ISPs, this cost is documented by the RIRs and LIRs. For enterprises and end users, fees associated with IPv6 services from an ISPs can vary from zero dollars (often the case when this is offered as a trial or beta service or the ISP wants to build service references) up to fees similar to IPv4 services. To evaluate the pricing associated with IPv6, contact your local ISP to learn about its capability to deliver the services. (For example, it is also possible to check out the Japanese ISP market from