Creating an IPv6 implementation plan
Jun-ichiro itojun Hagino
itojun at itojun.org
Wed Aug 22 16:12:19 CEST 2007
> 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.
> 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.
the numbering is much like the same as IPv4, if you would like to
share the same physical medium with IPv6. there's no magic wand.
you just have to think about address aggregation within your
organization a little bit.
> 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)
Foundary, Juniper and Cisco are pretty much all IPv6-capable. you
would need to pick a specific firmware branch/version for Cisco.
> 2. Locate subscribers willing to become V6 testers. It appears that it
there are a lot! basically, people are starved of IPv6 connectivity
so people are keep using tunnels. you are likely to get contacted
with geek types, either from their homes or their corporates.
> 3. Implement test environment for subscribers including
> a. DNS
> b. Hosted sites
> c. DHCP?
> 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)
> e. Email (this is outsourced so that is a big question mark...)
at this point, there are so much dependencies with existing IPv4
plans, your routers, customer devices and so forth. so there are
too many choices. let me know your details and we can sort that out.
(privately if you wish)
> 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.)
if you do not eat your own dog food, noone will.
an issue you haven't checked is: support and call centers, how to
educate them with IPv6. actually, it is easy - if they hear the word
"IPv6", they have to escalate it to upper level engineers.
More information about the ipv6-ops