Creating an IPv6 implementation plan

[JORDI PALET MARTINEZ]

Forgot this before ... Lots of info also available at www.ipv6tf.org

Regards,
Jordi




> De: Jeroen Massar <jeroen at unfix.org>
> Organización: Unfix
> Responder a: <ipv6-ops-bounces+jordi.palet=consulintel.es at lists.cluenet.de>
> Fecha: Wed, 22 Aug 2007 15:32:09 +0100
> Para: Rebecca Karpinski <rkarpinski at cablesystem.com>
> CC: <ipv6-ops at lists.cluenet.de>
> Asunto: 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=cou
> rse_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
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.