The first steps for ISPs to take today, do not involve planning IPv6 rollout or even testing IPv6 in the lab. Many users on the IPv4 Internet are already using IPv6 today through various types of tunneling schemes. For the past few years, many new computers (Apple PCs, Solaris servers, Linux servers) have had IPv6 support installed by default. Devices like the Apple Airport WiFi gateway already set up 6to4 relay tunnels for IPv6 devices on end user networks.
So the first step to take is to make sure that your network facilitates the use of these tunneling technologies. There are three separate steps to take.
See IPv6 Transition Mechanism for a comparison of the various IPv6 Transition mechanisms, outside of providing native connectivity.
If you are going to get, or have your own IPv6 allocation from ARIN, you will either have a large network yourself and peer with everybody, or you will need to get Transit (i.e., an upstream ISP). See IPv6 Transit Providers for ISPs who are offering IPv6 Transit possibilities in the various parts of the world.
Like IPv4 Transit, you will most likely want to have at least two upstream providers over diverse paths to ensure that either of them goes down that the other can take over. If you only have one upstream, you may simply have static routes to direct IPv6 traffic to you, and a default route outbound. If you have two upsteam, you will use BGP to announce routes, and can either set up a separate BGP session for your IPv6 route, or add your IPv6 route to your IPv4 BGP session.
If your IPv6 connectivity is different than your IPv4 connectivity, be careful when sizing the bandwidth needed. Even though today IPv6 traffic is fairly minimal for pretty much everyone, it has the potential to grow quickly now that more stuff comes with IPv6 support out of the box. If someone then adds an AAAA record to a service that generates a lot of traffic, a noticeable amount of traffic can move from IPv4 to IPv6 over night. You'll want to be able to add additional bandwidth on fairly short notice or else supplement the native IPv6 access with an IPv6 tunnel over your IPv4 access connection to the upstream who provides IPv6 service.
Setup peering with GRH and provide your routing tables to the system. This tool allows you to see easily which prefixes you are missing in your network and where you might want to improve IPv6 Transit. It also provide the community with a look into the quality of your network and ability to have a shot of debugging when something looks wrong.
This allows your customers to use your globally registered IPv4 addresses to create a globally unique /48 prefix in the
reserved 6to4 prefix 2002::/16 This makes the site behind the IPv4 address able to communicate
using IPv6. The method is even workable across NAT devices since it leverages your network addresses, not the customers.
First, you might want to review RFC's 3056 and 3068. Also, it would be good to read your router vendor's documentation on 6to4 relays because you set up the 6to4 relay service on routers which respond to the 6to4 anycast address assigned in RFC 3068.
A complete description of 6to4, how to setup clients (in case you don't want the automatic configuration) and how to setup a 6to4 Relay in different platforms, is available at The IPv6 Portal.
Check the following pages for more details on specific vendors:
Configure 6to4 relay service on two well-connected IPv6-enabled routers in your network and make sure you see a route to the 126.96.36.199 address propagated in your IGP.
Assuming you have already configured your normal IPv6 connectivity then don't forget to route 2002::/16 and sprinkle some "redistribute connected" over your favorite routing protocols.
If you want to run a public gateway, announce 188.8.131.52/24 and
2002::/16 over BGP.
No need to do tunneling at leaf nodes (i.e., ones where all the traffic goes into one direction) and if you have at least two in your network one location can be backup for another, so then one per location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money.
But doing it on non-dedicated routers is fine as well as long as you're sure an excess of IPv6 traffic isn't going to cause problems.
Here is a list of ISPs currently announcing a 6to4 prefix. Add yourself to the list after you start announcing one.
Teredo is an alternative IPv6 transition technology specifically for providing IPv6 connectivity behind a NAT device by using UDP tunneling. The protocol is described in RFC 4380. ISPs should run a Teredo Relay to optimize IPv6 connectivity for Teredo clients accessing the ISPs native IPv6 hosts. Establishing a local relay does not require any modification of Teredo clients - Teredo relay discovery is built-in to the protocol.
Teredo client functionality is built-in to Windows. Macintosh and UNIX systems can use Miredo.
Tunnel Brokers can be set up using a variety of different software, including Microsoft Windows. RFC 3053 defines the role of a tunnel broker. Here are some pointers to various HowTo documents.
Tell you customers what you have set up and point them to some resources that explain how to best make use of 6to4, Teredo and tunnel brokers. In addition, let them know about the Customer problems that could occur and provide some advice on how to address these problems.
After you have accomplished this, it is time to begin the planning and education process which will result in offering native IPv6 Internet access services at all PoPs where you currently offer IPv4 Internet access. You will need to run dual-stack on your backbone and servers, and will need to push IPv6 all the way to the edge. Here are some pages which will help with that.