Connecting to the Production IPv6 Internet
As mentioned, the deployment of the production IPv6 Internet started in July 1999 when the RIRs allocated production IPv6 spaces to very large providers.
The core of the production IPv6 Internet already exists. It is small compared to the current IPv4 Internet, but it has been growing steadily. The production IPv6 Internet is very similar to its equivalent in IPv4.
IPv6 ISPs exchange traffic in the NAPs such as in IPv4, and they provide connectivity to customers.
The following sections briefly cover these topics:
Basic steps to become an IPv6 provider on the production IPv6 Internet
IPv6 support needed in NAP for the exchange of routes by IPv6 providers
Things customers should understand when they get IPv6 connectivity from an IPv6 provider
Examples of IPv6 address space reassignment to customers by IPv6 providers
Route aggregation by IPv6 providers
How transition and coexistence mechanisms can be used in specific circumstances to provide IPv6 connectivity
Becoming an IPv6 Provider
As with IPv4, ISPs are the core of the IPv6 Internet. They have multiple responsibilities to assume to provide efficient and reliable IPv6 connectivity to their customers. These responsibilities are very similar to those in IPv4 and include the following:
Obtaining IPv6 space— One of the first steps of becoming a commercial IPv6 ISP is getting IPv6 space. For Tier-1 and very large providers, the IPv6 address space must be requested from one of the three RIRs. Then, intermediate IPv6 providers such as Tier-2 and Tier-3 providers should request their IPv6 address spaces from Tier-1 providers. The number of intermediate levels is not fixed.
Peering— After the ISPs receive their IPv6 address spaces, they have to establish peering between them through neutral places such as NAPs. BGP4+ is the de facto EGP routing protocol used between ISPs to perform peering for IPv6.
Address space reassignment— Customers and enterprises want addresses and IPv6 connectivity, but they cannot request IPv6 space from RIRs. Therefore, ISPs must reassign IPv6 address space to their customers. The reassignment of the address space has one consequence for the customers. If a customer changes IPv6 providers, it must renumber its site because of IPv6's strict aggregation policy. Moreover, IPv6 does not support the concept of portable address space. However, IPv6 has mechanisms to facilitate network renumbering in a site.
Route aggregation— In IPv6, it is mandatory for ISPs to aggregate the routing entries from their customers. In practice, only the prefixes allocated by the registry to the ISP must be announced in the global IPv6 routing table. The strict aggregation should limit the number of entries in the global IPv6 routing table.
Exchanging Traffic in NAPs
Network access points (NAPs) are neutral places where providers can exchange traffic and routes. NAPs generally have high-speed network infrastructures to interconnect the providers' links and routers.
If you are operating an IPv6 ISP, you probably need to be connected to an IPv6 NAP to exchange traffic with other peers. ISPs within NAPs exchange routes, but no default route is announced. Many advanced NAPs offer route servers to optimize peering and enforce route policing.
Because NAPs are generally based on Layer 2, it is possible for them to enable native IPv6 on their infrastructure with minimal effort. With IPv6, the agreements between the peers and the NAPs should not need to be modified because the IPv6 protocol does not introduce new issues. However, if a route server is present in the NAP, it must be enabled to IPv6 to be exploited by the IPv6 peers.
NAPs that support IPv6 are emerging around the world. In January 2003, 13 native IPv6 NAPs were operational and offering services to IPv6 Tier-1 providers—six in the U.S., two in Japan, two in the U.K., one in Germany, one in the Netherlands, and one in South Korea.
NOTE
You can find a list of the operational IPv6 NAPs at www.v6nap.net/
Scenarios for Establishing IPv6 Peering
The following are scenarios for establishing peering between the IPv6 ISPs in a NAP:
Using link-local address for BGP4+— IPv6 ISPs within a NAP might not want to use the IPv6 prefix from other IPv6 ISPs to configure their router's interfaces. By configuring IPv6 link-local addresses in their BGP4+ configurations, the IPv6 ISPs do not need a specific IPv6 prefix. This scenario appears as neutral for establishing peering between the IPv6 ISPs. However, the use of a link-local address in BGP4+ mandates a specific configuration. Refer to the section “Configuring BGP4+ for IPv6 Using Link-Local Addresses” in Chapter 4 to get detailed information about this specific configuration.
Using the aggregatable global unicast prefix registered by the NAP— APNIC, ARIN, and RIPE NCC assigned /48 and /64 prefixes to NAPs to establish peering between the IPv6 ISPs. This scenario can also appear as neutral for the establishment of peering between the IPv6 ISPs. Refer to www.ripe.net/cgi-bin/ipv6allocs to see the list of aggregatable global unicast prefixes assigned to NAPs.
Sharing prefixes between IPv6 ISPs— Another conventional scenario is the sharing of prefixes between IPv6 ISPs connected in the NAP, especially if the NAP does not provide IPv6 connectivity or aggregatable global unicast prefixes to IPv6 ISPs.
Coexistence and Transition Strategies
With the transition from IPv4 to IPv6, some NAPs might offer coexistence and transition mechanisms such as 6to4 relay and tunnel server services. Chapter 5 has detailed information about the 6to4 relay and tunnel server.
Connecting Customer Networks to IPv6 Providers
Assume that a customer wants IPv6 addresses and connectivity. The first step for the customer to get addresses and connectivity consists in finding a commercial IPv6 ISP. Because IPv6 can coexist concurrently on IPv4 infrastructures, it is highly possible that your IPv4 provider is already offering IPv6 connectivity through coexistence or transition mechanisms. Otherwise, the customer needs to interconnect its network to an IPv6 provider.
Following the agreement with the IPv6 provider, the customer should receive at least one /48 prefix and possibly more depending of its needs.
After the customer receives its IPv6 address space from the provider, it should design an IPv6 addressing plan using these two rules:
Determine the number of current and future subnets within its sites
Assign one /64 prefix to each subnet (not working with different netmask values as with IPv4)
Figure 7-8 shows prefix allocations within a customer site. First, an IPv6 provider allocates the 2001:420:0100::/48 prefix to the customer. Then the customer assigns one /64 prefix to each subnet within the network. The subnet between routers R1 and R2 is 2001:420:0100:1::/64, the subnet between routers R1 and R3 is 2001:420:0100:2::/64, and so on.
There are no clear guidelines for the reassignment of IPv6 prefixes within a site. However, an IETF informational document proposes an efficient method to help people making their addressing plans for IPv6. This IETF Internet draft can be found at www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt.
Address Space Reassignment by IPv6 Providers
Figure 7-9 shows an aggregatable global unicast IPv6 address space allocated to four customers by two providers. The ISP NY gets the prefix 2001:0400::/32 from its RIR. Then it assigns 2001:0400:45::/48 to customer LGA and 2001:0400:b10::/48 to customer JFK. The second ISP UK gets the prefix 2001:0600::/32 from its RIR. Then it assigns 2001:0600:a1::/48 to customer LHR and 2001:0600:a2::/48 to customer YXU.
Routing and Route Aggregation by IPv6 Providers
Figure 7-10 shows typical routing for the two ISPs and the four customers' sites connected. The routing table in ISP NY shows that the route 2001:0400:45::/48 points out customer LGA's router, and the route 2001:0400:b10::/48 points out router R2 of customer JFK. The routing table in ISP UK shows that the route 2001:0600:a1::/48 points out customer LHR's router, and the route 2001:0600:a2::/48 points out router R4 of customer YXU.
Both ISPs aggregate routes of their customers and announce only one route each to the IPv6 Internet. Therefore, the IPv6 Internet global routing table contains only the aggregated routes of these providers.
Connecting as Host Using Transition and Coexistence Mechanisms
Hosts located on the current IPv4 Internet can link to the IPv6 Internet using transition and coexistence mechanisms. As mentioned in Chapter 5, the configured tunnel and the 6to4 mechanism can be used to connect a single host with dual-stack support to an IPv6 network over the IPv4 Internet.
The provider can also deploy a tunnel server or a router acting as a 6to4 site on the IPv4 Internet to provide IPv6 connectivity to its clients through the current IPv4 infrastructure.