If you're a network operator, the first step should be IPv6-enabling your network. Talk to your upstream provider(s) about adding IPv6 to your existing service arrangement. If they're not ready or it looks to be too much of a hassle, consider using a tunnel broker. I've had good experience with Hurricane Electric and they will allocate you a /48 and peer with your existing BGP ASN with almost no hassle.
Take your time enabling IPv6 on each device. Vendor test coverage for IPv6 features is definitely not what it is for IPv4. Expect issues and downtime. If you're not OK with this, stop. Let others deal with the pain and revisit when 'www.cisco.com' and 'www.juniper.net' start returning AAAA records.
Figure you'll run dual-stack indefinitely. IPv4 will be around for a long time. If you're running OSPF, that means now you're running both OSPF and OSPFv3 indefinitely. IS-IS is a little nicer in this respect since it will handle both natively (but what's the chance you're already using it?). MP-BGP also lets you combine IPv4 and IPv6 updates in the same session. If you're really hard-core, you could change your IBGP sessions to peer via IPv6--if your IPv6 breaks, you'll know it because you'll lose all your v4 routes!
Embrace auto-configuration and DNS. Resist the temptation to statically configure addresses. Particularly if you go with a tunnel broker to start, consider that you may want to move to another provider. Unless you're big enough to get a direct allocation from a RIR, that means renumbering to the new provider's space. If you've used auto-configuration everywhere, renumbering your entire block will almost be a non-event.
Don't switch unsuspecting users over until IPv6 works at least as well as your existing IPv4 service. A lot of browsers and OSes will prefer AAAA records over A records and the user will never know he's using IPv6. If you're shoving thousands of users' IPv6 traffic through a crappy tunnel, all the user will know is that your network sucks.
It may not be fully up to date because most ISPs started this a couple of years back but it still has lots of good info. The major gap is lack of info on NAT64 and emphasis on NAT-PT. It is still a good idea to use NAT-PT in some scenarios but do a little research and comparison with NAT64 first.
First, make sure you can actually handle it. As in, updates on router OS, etc. Servers are less critical as they are more dynamic, so make sure the routers work first.
Second, you run your own AS, I assume, so start peering IPv6. Don’t expose this to customers, just start using it internally. Move your internal administrative networks over.
Then offer it to customers.
It pretty much runs down to clearing. Supplant your /21 with a proper IPv6 address space (/48 or smaller prefix).
If you're a network operator, the first step should be IPv6-enabling your network. Talk to your upstream provider(s) about adding IPv6 to your existing service arrangement. If they're not ready or it looks to be too much of a hassle, consider using a tunnel broker. I've had good experience with Hurricane Electric and they will allocate you a /48 and peer with your existing BGP ASN with almost no hassle.
Take your time enabling IPv6 on each device. Vendor test coverage for IPv6 features is definitely not what it is for IPv4. Expect issues and downtime. If you're not OK with this, stop. Let others deal with the pain and revisit when 'www.cisco.com' and 'www.juniper.net' start returning AAAA records.
Figure you'll run dual-stack indefinitely. IPv4 will be around for a long time. If you're running OSPF, that means now you're running both OSPF and OSPFv3 indefinitely. IS-IS is a little nicer in this respect since it will handle both natively (but what's the chance you're already using it?). MP-BGP also lets you combine IPv4 and IPv6 updates in the same session. If you're really hard-core, you could change your IBGP sessions to peer via IPv6--if your IPv6 breaks, you'll know it because you'll lose all your v4 routes!
Embrace auto-configuration and DNS. Resist the temptation to statically configure addresses. Particularly if you go with a tunnel broker to start, consider that you may want to move to another provider. Unless you're big enough to get a direct allocation from a RIR, that means renumbering to the new provider's space. If you've used auto-configuration everywhere, renumbering your entire block will almost be a non-event.
Don't switch unsuspecting users over until IPv6 works at least as well as your existing IPv4 service. A lot of browsers and OSes will prefer AAAA records over A records and the user will never know he's using IPv6. If you're shoving thousands of users' IPv6 traffic through a crappy tunnel, all the user will know is that your network sucks.
Now that you've built your rock-solid, well-connected IPv6 network, Ask Google for AAAA records, or you could wait for June 8, 2011 and see how things go.
Read the help information that is on ARIN's IPv6 wiki at http://www.getipv6.info
It may not be fully up to date because most ISPs started this a couple of years back but it still has lots of good info. The major gap is lack of info on NAT64 and emphasis on NAT-PT. It is still a good idea to use NAT-PT in some scenarios but do a little research and comparison with NAT64 first.
Acquire an IPv6 allocation, which shouldn't a problem since you have a large IPv4 allocation. You can't do anything till you do that.
They make sure your Cisco routers are all 12.4.x or greater.
First, make sure you can actually handle it. As in, updates on router OS, etc. Servers are less critical as they are more dynamic, so make sure the routers work first.
Second, you run your own AS, I assume, so start peering IPv6. Don’t expose this to customers, just start using it internally. Move your internal administrative networks over.
Then offer it to customers.
It pretty much runs down to clearing. Supplant your /21 with a proper IPv6 address space (/48 or smaller prefix).
One word: 6to4