Creating an IPv6 implementation plan

Wed Aug 22 18:46:44 CEST 2007

Hello,

Just FYI, Outlook 2007 successfully works with IPv6 on SMTP/POP3/IMAP4
servers.
Check my headers for example.

The same is with II6, DNS on Windows 2003 systems.
I haven't checked the DHCP Server on Windows 2003. But Vista can be IPv6
only connected system and I hope that Windows 2008 will fully support IPv6
as one available protocol in the system and/or active directory environment.

-- 
Marcin Gondek / Drixter
e-utp.net
NIP: PL1181589645
REGON: 140584662
Tel. +48602159929
Fax. +48222012418
office at e-utp.net
http://www.e-utp.net

-----Original Message-----
From: ipv6-ops-bounces+drixter=e-utp.net at lists.cluenet.de
[mailto:ipv6-ops-bounces+drixter=e-utp.net at lists.cluenet.de] On Behalf Of
Jeroen Massar
Sent: Wednesday, August 22, 2007 4:32 PM
To: Rebecca Karpinski
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: Creating an IPv6 implementation plan

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=c
ourse_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: smime.p7s
Type: application/x-pkcs7-signature
Size: 4576 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070822/db65a180/attachment.bin>