Creating an IPv6 implementation plan

[Iljitsch van Beijnum]

On 5-aug-2007, at 18:41, Rebecca Karpinski wrote:

> "Challenges"
> Much of the documentation that I'm finding that details  
> implementation plans
> for ISPs deploying IPv6 predate 6bone being dismantled,

Yes. That's why, in my opinion, the internet isn't the best resource  
to use to find out about something new. It's great when you want the  
answer to a specific question, but because old information keeps  
hanging around for so long, often without much indication that it's  
old or outdated, it's hard to come away with a complete picture of  
the current state of affairs.

> and all predate the
> issues with Type 0 Routing Headers. (Does that matter?  I don't know.)

Don't worry about it, it's much overblown and your equipment / OS  
vendors will take care of the issue for the most part.

> I find myself trying to correlate many disparate and contradictory  
> sets of
> instructions and it is beyond confusing. (6 to 4, 6 over 4,  
> tunneling, NAT,
> DON'T NAT, p2p link numbering, and so much more)

I recommend reading one or more books, because you get to know the  
opinions and prejudices of the writer(s) so you know where the advice  
is coming from and you get a more complete picture. Just have a look  
on Amazon and make sure that they're not from before 2003. While I'm  
at it, let me plug my own book: http://www.runningipv6.net/

That said

- 6to4 is great because it works automatically and it's in a lot of  
OSes and some equipment (most notably the Apple Airport Extreme  
802.11n base station) but performance and reliablity aren't always  
the best

- forget 6over4 in an ISP environment

- native is better than tunnel, but if a few tunnel hops are the most  
efficient way to get the packets where they need to go, that's ok.  
Just don't tunnel halfway across the world

- don't do NAT, even if it's desireable for IPv6, ISPs shouldn't do  
it for their customers

- point to point links: I like using EUI-64 addressing where  
possible, so I'll use /64. If you don't want to use /64, use /112,  
that's still enough for 2^48 subnets from a /64 and the subnet  
boundary is conveniently at a colon

> Plan thus far:
> 1. Dual stack our core network, which currently consists of a mix of
> Foundry, Juniper, and Cisco gear.

Think about whether you can / want to run IPv6 on ALL your routers or  
on a subset. Also think about which routing protocol you're going to  
use. If you use IS-IS you'll want to use that for IPv6 too, but make  
sure your gear supports multi-topology unless you upgrade ALL links.  
If you don't use IS-IS for IPv4, use OSPFv3 for IPv6.

You may want to start with Juniper because their IPv6 config is 98%  
identical to their IPv4 config, with Cisco the difference is more  
substantial, don't know about Foundry.

>    a. Can't find consensus on BCP for numbering this network.  It  
> doesn't
> help that we don't follow BCP for numbering in IPv4, but this might  
> be an
> opportunity to do things "right" - if I could figure out what that  
> means.

Set aside the all-zeros subnet for your servers, this gives you nice  
short IPv6 addresses. Use the next one or whatever for your internal  
infrastructure, and yet another for /64 subnets towards customers.  
Keep a few in reserve and use the rest for customers. At this stage  
in the game, you may as well give all customers a /48 rather than  
spend time thinking about what they actually need.

For your internal network, if you use VLANs, put the VLAN ID in the  
subnet bits of the /48 that you use for your internal stuff. So VLAN  
485 gets IPv6 range 2001:db8:1:485::/64. This leaves the subnet  
numbers with letters in them for non-VLAN based subnets. Cisco and  
Juniper support EUI-64 addressing, so rather than keeping track of  
which router is 1 and whcih 2, you just say:

!
interface FastEthernet2/0.485
  encapsulation dot1Q 485
  ipv6 address 2001:db8:1:485::/64 eui-64
!

>    b. Still need to find out where each piece of hardware is on the  
> spectrum
> of IPv6 readiness.  (Not possible vs. needs upgrades vs. ready)

When you get some experience you just bang on it and listen how  
hollow it sounds.  :-)

> 2. Locate subscribers willing to become V6 testers.  It appears  
> that it
> would be much easier from a technical standpoint to do so with our  
> Direct
> Ethernet and Frame Relay customers than our Cable Modem subscribers  
> as we
> are still trying to find equipment to TEST that is/will be  
> supposedly DOCSIS
> 3 compliant.  Unfortunately, our business customers are... shall we  
> say,
> less adventurous than many of our residential cable modem  
> subscribers, so we
> may not have any takers until we can implement V6 capable CMTS and  
> modem
> equipment.

I'd recommend setting up a tunnel broker for your customers. Even if  
the modems support IPv6, most regular users won't be able to do much  
with that because their home routers won't be able to handle it. With  
tunneling, you can either bypass the home router or use one that can  
terminate the tunnel, such as the Airport base station I mentioned.

I use a Cisco ADSL router at home which is great, but a bit complex  
and too expensive for regular users. Don't know if there are similar  
products for cable.

> 3. Implement test environment for subscribers including
>    a. DNS

Not a problem, but some caveats, have a look at:

http://www.apress.com/book/supplementDownload.html?bID=10026&sID=3120

>    b. Hosted sites

Mail and web are easy, just make sure everything works before jumping  
in with both feet.

>    c. DHCP?

IPv6 works very well without DHCP except that there is no easy way to  
configure DNS resolver addresses automatically. However, if you run  
both IPv4 and IPv6 you can use IPv4 for that so in practice this  
isn't a huge problem.

You may want to run a dual stack proxy. This way, if people use the  
proxy, IPv6-only users can reach the IPv4 world, and IPv4-only users  
can reach the IPv6 world. Apache 2 does this really well, Squid not  
so much, unless things have changed fairly recently.

Running your own 6to4 and/or Teredo gateways for the benefit of your  
customers that use these can also be useful to increase their  
performance.

>    d. BGP?

See http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf and/or  
http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html

> (We are currently multi-homed with 4 different providers, about
> to add a fifth, and have 10 OC-12 & OC-3 circuits with said  
> providers.  Of
> those, I don't believe ANY have native IPv6,

Find out elsewhere, because even if they do, chances are the people  
you talk to (especially sales people) don't know about it. Many of  
the tier-1s do IPv6 in some shape or form but you wouldn't know it as  
a regular customer.

> 4. Implement a test environment for our internal/corporate  
> network.  (this
> may happen prior to # 2, but I have serious concerns that our billing
> software will be... problematic.)

In my experience, it's better to have a lab network that is separate  
from the corporate stuff, because the needs of the two are so  
different...

> (Well, there are a few people who still think we won't run out of  
> v4 until
> 2030, but I consider them to be a rather vocal minority.)

Well, if we go from using some 170 million addresses per year, what  
we've been doing the last few years, down to 53 million a year, we  
can make the remaining 1173 million last that long. There have been  
two years that were below that since 1990, so I guess it can be done.  
Then again, China alone has received 30 million addresses so far this  
year...

ILjitsch