Creating an IPv6 implementation plan

Jun-ichiro itojun Hagino itojun at
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 mailing list