Creating an IPv6 implementation plan

[Jeroen Massar]

Rebecca Karpinski wrote:
> Well, here's hoping we're not too late to join the party. 
> This will probably be long, and for that I apologize in advance.

Asking before breaking is a good practice.

> My Goal:
> Create an IPv6 implementation plan for our company (smallish cable company &
> ISP in mid-west USA) that accommodates our plans for growth (SIP anyone?)
> through the projected IPv4 runout but does not hinder said growth by being
> generally defective and losing our established customer base to the big-boys
> playing in our sandbox.

You can always request more IPv4 space from the RIR in advance, just to
be sure that it won't run out on you, and claim that you have a business
plan which requires that IP address space,. Of course you will need to
satisfy the needs of the RIR before they will allocate you more space.

[..]
> "Challenges"
> Much of the documentation that I'm finding that details implementation plans
> for ISPs deploying IPv6 predate 6bone being dismantled, and all predate the
> issues with Type 0 Routing Headers. (Does that matter?  I don't know.)  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)

6to4 is RFC3056, which is what everybody can use who has a public IPv4
address. Reverses can be got from http://6to4.nro.net/. Big problem with
 6to4 is that the path taken by packets is fairly unknown and quite
uncontrollable, when something is broken it is hard to figure out where.
Having a local 6to4 relay, which is anycasted, helps only a bit.
Good reading: http://en.wikipedia.org/wiki/6to4

6over4 is RFC2529 and has been deprecated since and afaik also never
really used. (See also http://en.wikipedia.org/wiki/6over4).

tunneling, is what you use when you can't reach the other endpoint/site.
NAT is horrible in IPv4 and you should simply avoid it for IPv6, if you
are going to NAT anyway, better stick to IPv4.

p2p link numbering, most people tend to use ::1 + ::2 in a /64. Some
choose /80's or even /126's. Don't use /127's though as the
subnet-anycast address (which is <pfx>::/126) messes your routing up,
using 2x /128 of course works again. /64 prefix sizes are the standard.

For the rest, directed questions and/or a good book might help.
I might suggest (amongst others):
  http://www.runningipv6.net
  http://www.sunny.ch/publications/f_ipv6.htm
  http://www.benedikt-stockebrand.de/books_e.html#ipv6-in-practice
  http://www.deployingipv6.net/

All have their niche, depending on what you are looking for one is more
appropriate than the other. The "IPv6 Bible" used to be
http://www.huitema.net/ipv6.asp but as it is aging quite a few things
are not up to date anymore in there.


> Plan thus far:
> 1. Dual stack our core network, which currently consists of a mix of
> Foundry, Juniper, and Cisco gear.
>    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.

Depends completely on your network, which is why there is not a real
BCP. It seems that there are a couple of 'common' methods though, which
are a mix of ideas from:
 - Chop the network in two /33's, use only the first part
 - Counting the number of current PoPs/clients + expected future ones
   and splitting the /32 based on that into chunks of /44's or similar
 - Using a single /48 (usually the first or the last in the /32) for
   numbering backbone links

In the ARIN request you should actually have provided a possible network
layout, you can start off from there. One general thing: each customer
gets a /48, as such that /32 is not that much address space in quite a
number of cases. Also you want to try and have the minimal amount of
iBGP, which becomes easy if you split the network into regions and just
route based on the aggregates. You can always have a more specific for
special cases.

>    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)

And if they actually work: only way to find out: lab tests and real life
tests. Other way to find out: list your gear here and ask if people had
problems with them.

> 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.

DOCSIS3 is the way to go there. In the mean time you can setup a Teredo
relay to make sure that your customer traffic using Teredo stays close
in the network. Setup 6to4 if you want too. And if you want setup a
Tunnel Broker service in your network for your customers so that they
can use that, for that you can of course DIY, get a box of Hexago or
smile into the direction of me&pim (SixXS) to help you out for free.
The tunnel stuff is temporary, and if you number clients with /64
tunnels and /48 subnets you can later easily move them to native
infrastructure where possible, thus them keeping the same address space.

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

Should not be a big problem, though biggest issue here is providing the
configuration to them. DHCPv6 is an option and nowadays there is a draft
for DNS options in RA's. But easiest way is to probably simply have
<pfx>::53 and anycast that in your local network telling customers to
use that. Most DNS traffic is IPv4 based anyway as the roots are not
fully IPv6 enabled yet (yes there are rootservers doing it but they
don't per default return the correct glue).

>    b. Hosted sites

Enable IPv6 on the box, enable Apache/lighttpd/etc to use IPv6,
configure it correctly and then see a lot of scripts fall over as they
expect x.x.x.x and not 2001:db8::/32

>    c. DHCP?

There are a couple of servers for that, but it doesn't seem they are in
heavy use yet.


>    d. BGP?  (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, but I believe Sprint will do
> tunneling if we bat our eyelashes whilst we hassle them endlessly)

A tunnel to hop into the upstream ASN is not bad, it does get you
started and shows that you as a customer of theirs wants it.
See also: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit for a
list of transit providers. and as we are pointing there anyway, might I
ask you to signup for GRH (http://www.sixxs.net/tools/grh/) so that we
have a view on your network and you can check up on problems too? :)

>    e. Email (this is outsourced so that is a big question mark...)

SMTP is probably one of the many things that is soooo easy to make IPv6
capable that most people I guess don't even think about it. Just add
AAAA's and most mail servers will get it. Mail clients are not so easy
though, Outlook doesn't for instance which is a large portion of the
commercial/business users. Thunderbird happily does (check headers in
this email for instance :)

> 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.)

That, log files and a lot more that processes IP addresses are
'interesting' to move over to indeed. Asking vendors or simply testing
is one of the many ways to go.


> [..] Classes would be AMAZING, conferences would be good, and books and
> articles to use vs. avoid would also be helpful.

Books, see above. Articles, depends, ask for the specific subject.
Conferences, loads, but mostly political, not technical. Classes, I know
that Silvia Hagen (http://www.sunny.ch/education/f_workshops.htm) does
them, she wrote IPv6 Essentials listed above. Internet2 also has
workshops I believe and even IBM has a course:
http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=NCD90
Though, they all depend on what you want to learn if they are actually
appropriate. IMHO doing it yourself and playing with it is better.

Another good spot to look at is http://www.ipv6forum.com/ where Jim
Bound and a lot of other people are doing great work in education and
awareness. They can probably help you out with more information too,
especially in the US.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070822/a02efd03/signature.bin