Creating an IPv6 implementation plan
Iljitsch van Beijnum
iljitsch at muada.com
Wed Aug 22 18:25:51 CEST 2007
On 5-aug-2007, at 18:41, Rebecca Karpinski wrote:
> 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/
- 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
- 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
> 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
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:
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
> 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
> 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
> 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
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:
> 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
> d. BGP?
See http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf and/or
> (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
> (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
More information about the ipv6-ops