|
|
Address Policies and Registration ProcessTo 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:
IANA allocates IPv6 prefixes to the five Regional Registries (RIRs) based on their needs:
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:
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:
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:
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: 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:
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 http://www.ipv6style.jp/en/statistics/services/index.shtml.) Some enterprises or end users would expect IPv6 services to be added for free to their current IPv4 subscription; however, this is not always possible because this represents an operational cost for the ISP, too.  |
|
|