6bone
6bone stands for “IPv6 backbone.” The 6bone is a test-bed network that was created in 1996 by the IETF next-generation transition from IPv4 to IPv6 (NGtrans) working group to validate the new standards related to the IPv6 protocol. Another goal of the 6bone was to test the IPv6 implementations and network services to provide feedback to developers and protocol designers. Then, the 6bone was used to validate operational procedures and test transition and coexistence mechanisms.
The 6bone is informally operated by the IETF NGtrans working group, and it is managed on a collaborative, best-effort basis by its worldwide users. In 2002 (based on the 6bone registry database), more than 1100 sites located in 57 countries were connected to and participating on the 6bone. Because registration of IPv6 sites connected to this test-bed network in the 6bone registry database has never been mandatory (but was strongly recommended), the number of sites actually connected to the 6bone might be higher than 1100.
NOTE
The computing department of Lancaster University in the U.K. provides different statistics about and views of countries and sites connected to the 6bone. You can find information about sites connected to the 6bone at www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html.
However, these statistics represent only sites that are fully registered in the 6bone registry database, which you can find at www.6bone.net.
The 6bone is a network of IPv6 networks. The links between the IPv6 networks on the 6bone are made using IPv6. The IPv6 protocol is carried over WANs, over LANs in exchange points, and over IPv4 tunnels such as configured tunnels and 6to4 tunnels through the current IPv4 Internet.
NOTE
For more information about configured tunnels, see Chapter 5, “IPv6 Integration and Coexistence Strategies.”
In 1996, the 6bone started as a virtual network over the IPv4 Internet using IPv6-over-IPv4 tunnels to enable easy IPv6 connectivity and peering between IPv6 networks. Later, native IPv6 links were deployed between IPv6 networks. Past experience on the IPv4 Internet such as with the Mbone (multicast datagrams over the IPv4 Internet) suggested the deployment of IPv6-over-IPv4 tunnels until all links are converted to native IPv6 links.
NOTE
When network administrators of IPv6 networks such as ISPs, organizations, and companies, agree to exchange their IPv6 traffic for free, this is called peering. Administrators also define how the routes are advertised.
The 6bone is now a network made up of native IPv6 and tunneled links. New 6bone links are mostly native, and old tunneled links are gradually being replaced by native IPv6 links.
NOTE
The 6bone is not a production network with 24/7 support. 6bone operation is best-effort.
The following sections present 6bone's topology, architecture, addressing, connection, and routing policy.
6bone Topology
The 6bone topology is a hierarchy of providers. As illustrated in Figure 7-1, the first level of the hierarchy consists of 6bone's backbone nodes, representing the pseudo-Top-Level Aggregators (pTLAs).
Figure 7-1. Hierarchical Topology of the 6bone, with pTLAs, Providers, and Sites
NOTE
These backbone nodes are called pseudo because the 6bone is a test-bed backbone simulating production service providers. On the production IPv4 Internet, these first-level nodes are called Tier-1 providers (Tier-1 ISPs).
The pTLAs connect with other pTLAs in the default-free zone, where no default IPv6 route is advertised.
NOTE
The default-free zone is the place in the network where ISPs and other large networks use the global IPv6 routing table to exchange traffic. Within the global IPv6 routing table, no default route exists, and only aggregated IPv6 routes are present. The IPv4 Internet has the same topology, but routes are not fully aggregated as with IPv6.
These first-level nodes (pTLAs) are called aggregators because they must aggregate the IPv6 traffic of all their downstream customers and announce only a few IPv6 prefixes on the 6bone. As discussed in Chapter 1, “Introduction to IPv6,” the aggregation of routes in IPv6 promotes efficient and scalable routing to the IPv6 Internet. Figure 7-1 shows that each pTLA on the 6bone provides IPv6 connectivity and IPv6 spaces to its downstream providers and sites.
The pTLAs peer with other pTLAs using BGP4+ to exchange their IPv6 routes. The peering between the pTLAs on the 6bone may be done over native IPv6 links or IPv6-over-IPv4 tunnels.
NOTE
BGP4+ is also called BGP4 with multiprotocol extension. BGP4+ supports IPv6. Refer to Chapter 4, “Routing on IPv6,” for detailed information about the BGP4+ routing protocol.
Figure 7-2 shows the real peering between the pTLAs on the 6bone. This representation comes from the 6bone registry database and reflects only the peering information registered.
Figure 7-2. Peering Between pTLAs on the 6bone
Source: IPv6 Resource Centre of the Lancaster University Computing Department in the U.K., www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/backbone.gif
6bone Architecture
The 6bone topology is the conceptual view of this backbone, but the architecture of the 6bone has been made over time with a diversity of links. Moreover, as mentioned in the preceding section, the pTLAs on the 6bone are connected using a mix of native IPv6 links and tunnels over the IPv4 Internet.
Figure 7-3 shows the different types of links used between the pTLAs of the 6bone. pTLAs A, B, C, and D are connected through a native IPv6 NAP using native IPv6 links and pTLAs D and F have native IPv6 links to pTLA E. Finally, pTLAs F and G are connected to pTLA D using IPv6-over-IPv4 tunnels through the IPv4 Internet. These IPv6-over-IPv4 tunnels are simply acting as point-to-point links.
Thus, adjacent pTLAs in Figure 7-3 can enable BGP4+ peering between them to exchange IPv6 traffic by announcing and receiving IPv6 routes through their peering. Therefore, all these connected pTLAs form the worldwide IPv6 network called the 6bone.
A pTLA on the 6bone can provide addressing and connectivity to any provider, intermediate provider, or site directly connected to the pTLA.
In Figure 7-4, the pTLA at the top provides connectivity and addressing space to a first-level provider, intermediary provider, and site. Then, the provider can allocate address prefixes to the sites directly connected while the intermediary provider allocates address prefixes to another level of downstream providers.
As shown in Figure 7-4, prefixes are allocated from the pTLA to the end sites via different levels of providers. In the other direction, upstream providers aggregate the end sites' traffic and address prefixes. Therefore, upstream providers announce only one (or a few) aggregated prefixes directly to the pTLA or through another level of upstream provider.
IPv6 Addressing on the 6bone
As described in RFC 2471, IPv6 Testing Address Allocation, the aggregatable global unicast IPv6 address space assigned by the IANA for the 6bone is the 3ffe::/16 prefix. The 3ffe::/16 prefix is for experimental purposes only. This address space can be reclaimed in the future, forcing pTLAs, providers, and sites to renumber their networks.
RFC 2921, 6Bone pTLA and pNLA Formats (pTLA), defines the 6bone's address allocation policy. The 6bone policy has evolved over time:
First allocation policy (1996 to 1999)— 6bone's first address space allocation started at 3ffe:0000::/24 and ended at 3ffe:3900::/24. Each pTLA received one /24 prefix. A total of 58 pTLAs received one /24 prefix. This policy allowed a maximum of 256 pTLAs on the 6bone.
Second allocation policy (1999 to 2002)— The second address space allocation changed to allow a larger number of pTLAs on the 6bone. Each pTLA received one /28 prefix. The allocation started at 3ffe:8000::/28 and ended at 3ffe:8370::/28. A total of 56 pTLAs received one /28 prefix. This policy allowed a maximum of 4096 pTLAs on the 6bone.
Current allocation policy— In March 2002, the address space allocation changed again to increase the maximum number of pTLAs on the 6bone. With this policy, each pTLA can receive one /32 prefix. The allocation starts at 3ffe:4000::/32, and the last prefix available for the policy is 3ffe:7fff::/32. The new policy, coupled with the /24 and /28 prefixes assigned to pTLAs in the past, allows a maximum of 16,384 pTLAs on the 6bone.
NOTE
Additional information about address space allocations already done on the 6bone can be found at www.6bone.net/6bone_pTLA_list.html.
The address allocation policy also defines the prefix lengths of subnets and end sites on the 6bone:
Site prefix— The policy defines that each end site on the 6bone receives one /48 prefix from its upstream provider. The /48 is the minimum required for a site on the 6bone.
Subnet prefix— The policy defines that each subnet within a site receives one /64 prefix within the site prefix. The allocation of the /64 prefix to the subnet is important for enabling the stateless autoconfiguration mechanism on networks.
NOTE
In theory, one /48 prefix allows a site to have up to 65,536 /64 prefixes. However, as discussed in Chapter 1, IP's address space IPv4 and IPv6, like any other addressing scheme, is not optimal. Therefore, the 65,536 /64 prefixes within one /48 is only a theoretical number.
Figure 7-5 shows the hierarchical allocation of prefixes between the 6bone prefix 3ffe::/16 to the subnet prefix in sites. The first level is the 16-bit prefix of the 6bone, followed by the pTLA allocation, which is based on 32-bit prefixes. Then comes the provider level, which can allow one to several providers in a hierarchy between the pTLA and a site. 16 bits are available for the provider level. Finally, Figure 7-5 illustrates the /48 allocated to sites and /64 prefixes assigned to subnets within sites.
Figure 7-5. Hierarchical Allocations Within the 6bone Prefix 3ffe::/16
Becoming a pTLA on the 6bone
It is possible for providers and ISPs to qualify as pTLAs on the 6bone. RFC 2772, 6bone Backbone Routing Guidelines, defines the rules, criteria, and policy for becoming a pTLA on the 6bone:
To become a pTLA, the applicant must have a minimum of three months of qualifying experience as a 6bone end site. During the requested period, the applicant must have done the following:
- Registered its site in the 6bone registry database. A web interface of the 6bone registry database is available at www.viagenie.qc.ca/en/ipv6/registry/index.shtml
- Maintained BGP4+ peering and connectivity between the applicant's boundary router and an appropriate connection point into the 6bone (a pTLA)
- Maintained AAAA and PTR records for its border router in a local DNS server
- Maintained an IPv6-accessible system providing at least one web page or more of information
The applicant must have the ability and the intent to provide “production-quality” 6bone backbone service. More specifically, the applicant must claim to have the support staff and tools to operate as a pTLA.
The applicant must have potential end users who would be served by it as a pTLA.
The applicant must conform to the 6bone's routing policy by doing the following:
- Announcing permitted IPv6 routes within the 6bone address space, production of IPv6 Internet address space, and 6to4 address space
- Announcing legal prefix lengths allocated over time on the 6bone and on the IPv6 Internet
- Not announcing prohibited routes
The applicant must send its request to a steering committee for review purposes.
NOTE
Detailed information about rules, criteria, and policies with regard to becoming a pTLA on the 6bone can be found in RFC 2772. An overview of this RFC is presented in the next section.
Routing Policy on the 6bone
The routing policy for the 6bone is described in RFC 2772. This policy was defined and designed to maintain the stability of routing on the 6bone by having a common set of rules and guidelines.
The routing policy has to be applied by 6bone providers and by all pTLAs. The routing policy contains the following rules:
Prohibited address ranges— Specific ranges of addresses such as link-local, site-local, multicast, and loopback, of the whole IPv6 space must not be advertised by pTLAs on the 6bone. The “Prohibited Announcements” section details the prohibited address ranges on the 6bone.
Legal prefix lengths— Allocation of prefixes to pTLAs on the 6bone changed over time. The policy defines the maximum length of prefixes announced on the 6bone. The prefix lengths vary from /24 through /32. The “Legal Prefix Lengths” section details the prohibited address ranges on the 6bone.
Guidelines for the 6bone route registry— These are the guidelines that document the allocation of addresses and the connected sites in the 6bone route registry. The “6bone Route Registry” section provides an overview of the 6bone route registry.
Guidelines for enforcement— These are the guidelines for the enforcement of the routing policy. Organizations connected on the 6bone commit to implement the 6bone's rules and policies, they should report any issues and problems detected to the 6bone Operations Group, and they are responsible for working toward the problem's resolution. See RFC 2772 for more information about this rule.
Guidelines for DNS— These are the guidelines for maintaining DNS records (AAAA) and reverse (ip6.int) entries for the organization's router and at least one host system. See RFC 2772 for more information about this rule.
Permitted Announcements
This section describes the IPv6 address spaces that are permitted to be advertised on the 6bone by the pTLAs:
6bone address space— The 3ffe::/16 prefix that is assigned by the IANA for the 6bone operation is permitted. This means that any prefixes assigned to the pTLA within 3ffe::/16 may be advertised by pTLAs on the 6bone.
Production IPv6 Internet address space— The 2001::/16 prefix that is assigned by the IANA for the production of IPv6 Internet operation is permitted. Prefixes assigned to ISPs within the 2001::/16 prefix may be advertised on the 6bone. More information about the IPv6 Internet address space is presented later in this chapter.
6to4 address space— The 2002::/16 prefix that is assigned by the IANA for the 6to4 operation is permitted. Because the pTLA may implement a 6to4 relay in its network, it may advertise its 6to4 prefix to the 6bone. However, a pTLA announcing its 6to4 prefix on the 6bone must enable a 6to4 relay. The prefix of the 6to4 relay is based on the 6to4 router's globally unique unicast IPv4 address.
Legal Prefix Lengths
Because route aggregation is enforced on the 6bone and on the IPv6 Internet, 6bone has a strict policy of announcing only aggregated routes. For each IPv6 address space permitted in the preceding section, the pTLAs on the 6bone should announce only the following legal prefix lengths:
6bone— The allocation policy evolved over time. Therefore, the following prefix lengths are legal on the 6bone:
- 3ffe:0000::/24 through 3ffe:3f00::/24
- 3ffe:8000::/28 through 3ffe:83f0::/28
- 3ffe:4000::/32 through 3ffe:7fff::/32
Production IPv6 Internet— RIRs such as American Registry for Internet Numbers (ARIN), Asia Pacific Network Information Center (APNIC), and Réseaux IP Européens Network Coordination Center (RIPE NCC) started in 1999 with the assignment of /35 prefixes to ISPs. As with the 6bone, the allocation policy evolved over time. In 2002, registries started to assign /32 prefixes to ISPs instead of /35. Therefore, the following prefix lengths are legal on the 6bone:
- 2001:0000::/35 through 2001:ffff::/35
- 2001:0000::/32 through 2001:ffff::/32
6to4— Because the IPv6 prefix of a 6to4 relay is based on the 2002::/16 prefix followed by the globally unique unicast IPv4 address of the 6to4 router in hexadecimal representation, the 2002:xxxx:xxxx::/48 prefixes are the only legal length permitted on the 6bone.
Prohibited Announcements
Based on the 6bone's routing policy, the pTLAs on the 6bone must not advertise the following address ranges:
Link-local prefix (FE80::/10)— Because the link-local prefix is for a local scope purpose only, it must not be advertised on the 6bone by pTLAs.
Site-local prefix (FEC0::/10)— Because the site-local prefix is for a site local scope purpose only, it must not be advertised on the 6bone by pTLAs.
Multicast prefix (FF00::/8)— Because the multicast prefix is used only in a multicast context, multicast addresses must not be advertised by pTLAs in a unicast IPv6 routing domain (6bone).
Loopback and unspecified— The 1/128 (::1) and ::0/128 (::) prefixes must not be advertised on the 6bone.
IPv4-compatible prefix (::/96)— The IPv4-compatible prefix is for automatic tunneling. It has no need to change the IPv6 routing domain (6bone), so it must not be advertised on the 6bone.
IPv4-mapped prefix (::FFFF:d.d.d.d/96)— Because the IPv4-mapped prefix is used internally in the applications, there is no need to change the IPv6 routing. Thus, the IPv4-mapped prefix must not be advertised on the 6bone.
Default route— Because a pTLA must be default-free, the default route must not be advertised on the 6bone by any pTLA.
Other unicast prefixes— Any other unicast prefixes from undefined or unallocated prefixes by ARIN or RIRs that are not defined in the permitted announcement must not be advertised on the 6bone.
NOTE
Chapter 2, “IPv6 Addressing,” contains additional information about link-local, site-local, multicast, loopback, unspecified, IPv4-compatible, and IPv4-mapped addresses.
6bone Route Registry
On the IPv4 Internet, a route registry is useful for sharing network prefix information and identifying the usage of address prefixes. The route registry does the following:
Allows providers, ISPs, and registries to view the IPv6 address allocations.
Identifies people who can be contacted for information and debugging purposes.
Generates route filters by extracting all the routes in the registry. Thus, any pTLA can configure routing filters on its routers. The route registry can automate the process of route filtering required by the peering policy.
The 6bone route registry is available at www.6bone.net. All sites, providers, and pTLAs connected on the 6bone should register their sites in this IPv6 route registry.