How to join the 6bone

So be clear what your goals are when you start this process, and help us make IPv6 better!

A BIT OF INFO ON IPv6 ADDRESSES

Many folks ask about how to get IPv6 addresses. The long answer to this is, read the rest of this write-up, the relevant standards documents etc. and you will eventually learn how this works. However, a shorter answer might help the newcomer, so here goes.

Globally addressable IPv6 unicast addresses are in the IPv6 Global Unicast Address Format which has a three level hierarchy that includes a Public Topology (the 48 bit external routing prefix), a Site Topology (typically a 16 bit subnet number), and an Interface Identifier (typically an automatically generated 64 bit number unique at least on the local LAN segment).

The Public Topology has two or more levels of hierarchy, specifying the Top Level Aggregator (typically a high level ISP), Next Level Aggregators (zero or more mid-level ISPs) and a final Next Level Aggregator which is the end-user-site. The point here is that end-user-sites get their address prefix from an ISP that provides them IPv6 service.

To date there are two types of Top Level Aggregator (TLA) prefixes:

    the one for the 6bone whose first 16 bits are 3FFE::/16 (in IPv6 Address Representation)
        the top level aggregators here are called pseudo-TLA's, or pTLA's, which are assigned
        through a process defined by the 6bone community.

    the one for early production assignments whose first 16 bits are 2001::/16
        the top level aggregators here are called sub-TLA's, which are assigned
        through the International Regional Internet Registry (RIR) Process.

In a nutshell, to get your first 6bone IPv6 address, become an end-site of an existing pTLA 6bone ISP (i.e., getting your 48 bit IPv6 external routing prefix from that pTLA), operate for 3 months and look into at applying for your own pTLA (if you are an ISP) based on the 6bone process above.

To get your first production IPv6 address, find a production IPv6 ISP (i.e., that has a sub-TLA) to get your prefix from. If you want your own sub-TLA, look into the RIR process above.

A third way for a site to get its own public IPv6 address is to use the newly emerging "6to4" automatic tunneling mechanism to specify an IPv4 address of an end-user-site router for an IPv6 over IPv4 tunnel to reach the end-user-site. Addresses of this type have the first 16 bits of 2002::/16, with the next 32 bits (thus making up the entire 48 bit external routing prefix) containing the IPv4 address of a router on your site supporting this mechanism. However, this is too long a topic to cover here, so read the write-up mentioned, and ask questions.

ROUTERS

We won't make any value judgement as to what router(s) you should use.  The following is just information about current implementations.  But do realize that whatever you do, it is highly likely that you will need a stand alone router device (albeit a workstation or a real router) dedicated to this purpose until the time you can integrate IPv6 into your sites network.

For router implementations, please look at the IETF IPv6 Working Group Implementation pages.

As for using a workstation as a router, there are several alternatives.  Again, please look at the IETF IPv6 Working Group Implementation pages (especially look at the KAME host implementation as it works in various BSD derivatives).

Whatever you choose, you want the ability to support packet forwarding from one interface to another (Ethernet would be adequate as bandwidth is not likely to be an issue at this time), where there is an IPv6 workstation on one of them and a connection to a subnet of your site that will get you to the external Internet using an IPv4 configured tunnel to the 6bone to carry your IPv6 packets.

You could do this with just one interface (a "one-armed router"), but it might make it harder to debug and monitor, and eventually could become a performance problem as  traffic will be doubled on the single interface (what comes in must go out the same way). 

For peering to the 6bone you need to either support a static route, RIPng or BGP4+.   If you were acting as a 6bone pTLA (i.e., backbone site) you must use BGP4+, but this is a totally different discussion to have as you couldn't become a pTLA unless you could decide all these issues without help from this basic entry primer!

Any modern workstation/pc will work for many of the host implementations.

Although there is no absolute reason that you can't pick a random 6bone site and ask them to support your connection, there are practical routing considerations of the underlying IPv4 path that you use.  In particular, as your IPv6 packets are in carried in an IPv4 tunnel, the route they take is not under your control.   Thus if you pick a pTLA in Korea to attach to, your packets will follow whatever IPv4 routing path currently exists from your site to Korea, and then back from Korea to wherever your intended destination site is.  Of course if you are in Korea this is great.  If you are in France, maybe not so great.

Thus a new site should seek a 6bone point that appears to be reasonably adjacent (close to) your normal IPv4 paths into the Internet.  There is no substitute here for some detective work using the 6bone Registry, the 6bone pTLA list and IPv4 pings and trace routes.  The 6bone pTLA list makes a hot link from the name of the pTLA to its 6bone Registry entry.  Also, pTLAs are listed with their country or state (for the US). So if you are in Oklahoma, for example, then maybe using MERIT/US-MI would work (middle of the country and all that).  So you go to Merit's 6bone registry entry and get an IPv4 tunnel endpoint IPv4 address from it and try a traceroute and/or ping.

A few tests such as this will give a new site a first cut idea of what pTLA might be best to try.  To try various pNLA transits takes more work with the registry, but is still the same idea.  The Lancaster Univ. IPv6 registry web pages have excellent displays to help make this easier to do.

Now that you have a short list of potential 6bone pTLA/pNLA transits you might connect/tunnel to, using their registry data contact one of their listed registry contacts by email directly (and don't copy the 6bone list - no one wants to see all the detail business that goes on). Note that at times site contacts might be unresponsive, or slow to respond, so don't wait more than a week for response. When all else fails, query the 6bone list and ask for help in finding a contact.

Once you have an agreement from a 6bone pTLA/pNLA transit to connect you, you are ready for more serious business!

The preferred method of creating/updating 6bone registry entries is the Viagenie 6BONE REGISTRY DATABASE WEB INTERFACE. This interface provides good authorization protection by requiring all entries be protected by mntner entries with an encrypted password authentication scheme.

Addresses used are the new style Aggregatable Global Unicast Addresses assigned under the 6BONE TEST TLA assignment to pseudo TLAs and on to pNLAs under them and on to the user/leaf site.  That is, your address is totally determined by your provider/point-of-attachment to the 6bone.  The 6bone Test TLA (RFC 2471) document and the 6bone Test TLA sample usage page give a good overview of this to help your understanding of the concept.

Your 6bone provider (pTLA/pNLA) site will create your inet6num object for you with the appropriate address delegated to your site.  Basically this will be a 48-bit Public Routing Topology prefix completely specifying the hierarchical tiering from your site to the 6bone. 

The remaining 80-bits of the 128-bit IPv6 address are yours to use per the address specification.  You need not justify nor disclose your plans for this address space as you often must do to get scarce IPv4 addresses.  You essentially have a 16-bit SLA field you can use as you wish, e.g., as a subnet designator, and full use of the 64-bit Interface ID field for your workstations/routers' network interface. Of course in the normal mode of Neighbor Discovery you won't have to bother about these as they are automatically formed from the Ethernet MAC addresses for the interface.

This means that with no effort you can support 65K subnets at your site,each one with as many end systems/hosts as you wish, i.e., essentially a number bounded only by your site's equipment and underlying networking infrastructure limitations, not by an ISP's limitations.

Your 6bone provider now will now work with you to build your configured tunnel to reach them.  This tunnel information must be added by you to your ipv6-site object to document it has been done (never make this tunnel entry without full agreement of the other end-point of the tunnel).  These tunnel specifiers are used by countless utilities on the network to learn network topology, tobuild network diagrams and to test out reliability, reachability and performance.  They are important, so keep them updated!