What would a Step-by-Step Framework for Planning an IPv6 Deployment Look Like?

[Mukom Akong T.]

Hello all,

One of the questions I often get asked during after teaching/facilitating
and IPv6 session is: "Now I know all these tech bits and how they come
together, but what are the steps for deploying IPv6?"

I've often scratched my head because I thought 'that's obvious', however I
gave have detailed and have decided to provide a framework that anyone
could use and would like to get critiques and suggestions on how to improve
this for folks looking how to kickstart their IPv6 deployment project.

http://techxcellence.net/2013/01/28/step-by-step-framework-for-planning-ipv6-deployment/

Surprisingly, these are very familiar steps that almost everyone who has
done a project in the past can relate to. The steps are:


   1. Set Clear Goals for the IPv6 Deployment Project.
   2. Identify the List of Tasks Required to Achieve each Goal.
   3. Identify Resources Required to Accomplish each Task.
   4. Get Management Approval/Sign-off for the Project.
   5. Execute the Plan, Documenting Everything as you go.
   6. Update Relevant Organisational Processes to Integrate new
   Capabilities Resulting from the Deployment.

These are quite obvious steps, however what each of them means and the
thought process required to clarify each is what have detailed. I'd like
your comments and also your suggestions on what you can do to move your
IPv6 Deployment project from and "incomplete pile of unclear stuff" to and
organised set of tasks that will surely lead you towards a working IPv6
deployment? Please share.

Regards and have a wonderful week!

[Disclaimer]: Like with all my posts, ALL opinions are mine and do not
necessary represent the views or positions of any of my professional
affiliations.

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
--
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
---

Re: IPV6 in enterprise best practices/white papaers

[Karl Auer]

On Sun, 2013-01-27 at 12:31 -0500, William Herrin wrote:
> Right. On a each local machine you can often override the default
> behavior. That default dynamically kicks in for all machines as soon
> as there's an IPv6 router on the LAN. Configurable? Sort of. Realistic
> solution to the cited problem? Not in your wildest dreams.

Well - not on my *wildest* dreams, no :-) But in some of my more modest
dreams a draft RFC has appeared allowing the distribution of source and
destination address preferences via DHCPv6. In my dream, it even has a
name:

   draft-ietf-6man-addr-select-opt-08

Not a solution for SLAAC, though I suppose a similar extension would be
possible in SLAAC.

If you run a standard operating environment, the fact that source and
destination address preferences are configurable means you can put it in
your SOE right now.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

Re: IPV6 in enterprise best practices/white papaers

[Mark Andrews]

In message 
, Harald 
Koch writes:
> On 26 January 2013 17:38, Mark Andrews  wrote:
> > As for "breaking" your LAN, if the applications take 60 seconds to
> > fallback to the other address they were already broken.  Go complain
> > to your application vendor.  Some vendors have already fixed this
> > problem with their applications.
> 
> The question was about *enterprise* deployment, which raises two issues:
> 
> 1) most vendors are waiting for customer IPv6 demand before
> implementing support (or fixing bugs) - chicken and egg problem.

This is not a IPv6 bug.  The bug is present in IPv4 only networks.
It is a bug in the applications multi-homing support.  Adding IPv6
just makes every destination multi-homed.  Just think about how
much money has already been spent to work around this bug.

> 2) I don't know many enterprises running production software less than
> a year (or more) old.
> 
> In the meantime, the network engineers struggling with this stuff need
> workarounds (like the tuning parameters you and others have
> mentioned).
> 
> -- 
> Harald
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPV6 in enterprise best practices/white papaers

[Måns Nilsson]

Subject: Re: IPV6 in enterprise best practices/white papaers Date: Sun, Jan 27, 
2013 at 12:31:37PM -0500 Quoting William Herrin (b...@herrin.us):
 
> Right. On a each local machine you can often override the default
> behavior. That default dynamically kicks in for all machines as soon
> as there's an IPv6 router on the LAN. Configurable? Sort of. Realistic
> solution to the cited problem? Not in your wildest dreams.

Well, I'm doing a careful, slow rollout of v6 in an enterprise. Things
like this can be herded so as to be way below the threshold of noticeable
for 99% of the users. The only quirk we've found is a LAN that first
got v6 and then lost it (long story of IOS upgrades enforcing sanity and
breaking hackish deployments). Clients on other segments were a bit upset.
 
> That's right, blame the applications for the defective API. After all,
> any skilled application programmer can work around the problem, given
> sufficiently long experience with IPv6.

IMNSHO, the API is not as defective as you might think. The idea was to
replace v4. If we cling to v4, what is going to happen? (Well, ask just
about any ISP except HE and a few others, they can tell how it feels to
cling to v4 and go LALALALALALALACANTHEARYOU when customers ask for v6)
The happy eyeballs fix is of course convenient, but only necessary when
the network is so broken for v6 that you should not have turned RA on..

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
How do you explain Wayne Newton's POWER over millions?  It's th' MOUSTACHE
...  Have you ever noticed th' way it radiates SINCERITY, HONESTY & WARMTH?
It's a MOUSTACHE you want to take HOME and introduce to NANCY SINATRA!


signature.asc
Description: Digital signature

Re: IPV6 in enterprise best practices/white papaers

[Måns Nilsson]

Subject: Re: IPV6 in enterprise best practices/white papaers Date: Sun, Jan 27, 
2013 at 10:01:04AM -0800 Quoting joel jaeggli (joe...@bogus.com):

> Tunning dekstop operating systems is not the scalable side of
> enterprise network deployment.
 
No problem if it is a deployment. If it is the usual chaos, yeah, then
there is a problem.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I'm encased in the lining of a pure pork sausage!!


signature.asc
Description: Digital signature

Re: IPV6 in enterprise best practices/white papaers

[Jima]

On 2013-01-27 11:01, joel jaeggli wrote:

On 1/27/13 9:01 AM, Harald Koch wrote:

In the meantime, the network engineers struggling with this stuff need
workarounds (like the tuning parameters you and others have
mentioned).


Tunning dekstop operating systems is not the scalable side of enterprise
network deployment.


 Yes and no.  OS tuning can be rolled out via AD GPO, or other 
configuration management frameworks that might be present for other OSes 
(Puppet, CFEngine, etc).


 Jima

Re: IPV6 in enterprise best practices/white papaers

[Jima]

On 2013-01-26 09:41, Sander Steffann wrote:

after that I can start configure bgp with ISP.


No. *First* talk to your ISP, get address space (either from your ISP or 
provider independent), make an addressing plan, configure your firewalls and 
configure your back bone, then connect to your ISP, then deploy IPv6 on servers 
and clients (first on small test networks in your lab if possible), then 
advertise it in DNS.


 As the token IPv6 SME in a moderate-sized enterprise, I'd like to +1 
Sander's recommended path.  I was going to chime in, but this sums up 
what I would have advised.


 Jima

Re: IPV6 in enterprise best practices/white papaers

[joel jaeggli]

On 1/27/13 9:01 AM, Harald Koch wrote:

On 26 January 2013 17:38, Mark Andrews  wrote:

As for "breaking" your LAN, if the applications take 60 seconds to
fallback to the other address they were already broken.  Go complain
to your application vendor.  Some vendors have already fixed this
problem with their applications.

The question was about *enterprise* deployment, which raises two issues:

1) most vendors are waiting for customer IPv6 demand before
implementing support (or fixing bugs) - chicken and egg problem.
I'm wondering what you mean by most vendors? an enterprise 
switch/router/firewall/os vendor without ipv6 support has some 
explaining to do.

2) I don't know many enterprises running production software less than
a year (or more) old.
Not sure what you even mean. if you have have an application that 
doesn't support for v6 don't publish  records for it.

In the meantime, the network engineers struggling with this stuff need
workarounds (like the tuning parameters you and others have
mentioned).

Tunning dekstop operating systems is not the scalable side of enterprise 
network deployment.

Re: IPV6 in enterprise best practices/white papaers

[William Herrin]

On Sat, Jan 26, 2013 at 5:38 PM, Mark Andrews  wrote:
> In message 
> , William 
> Herrin writes:
>> In their infinite(simal) wisdom the architects of IPv6 determined that
>> a host configured with both a global scope IPv6 address and an IPv4
>> address will attempt IPv6 in preference to IPv4. If you configure IPv6
>> on a LAN without first installing your IPv6 Internet connection, that
>> LAN will break horribly.
>
> The default is to tune for IPv6 first but it been configurable for
> years now.  Given one generally wants to use IPv6 over IPv4 to avoid
> having you packets going through CGN boxes this is a good thing for
> you and your ISP.

Right. On a each local machine you can often override the default
behavior. That default dynamically kicks in for all machines as soon
as there's an IPv6 router on the LAN. Configurable? Sort of. Realistic
solution to the cited problem? Not in your wildest dreams.


> As for "breaking" your LAN, if the applications take 60 seconds to
> fallback to the other address they were already broken.  Go complain
> to your application vendor.  Some vendors have already fixed this
> problem with their applications.

That's right, blame the applications for the defective API. After all,
any skilled application programmer can work around the problem, given
sufficiently long experience with IPv6.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPV6 in enterprise best practices/white papaers

[Harald Koch]

On 26 January 2013 17:38, Mark Andrews  wrote:
> As for "breaking" your LAN, if the applications take 60 seconds to
> fallback to the other address they were already broken.  Go complain
> to your application vendor.  Some vendors have already fixed this
> problem with their applications.

The question was about *enterprise* deployment, which raises two issues:

1) most vendors are waiting for customer IPv6 demand before
implementing support (or fixing bugs) - chicken and egg problem.
2) I don't know many enterprises running production software less than
a year (or more) old.

In the meantime, the network engineers struggling with this stuff need
workarounds (like the tuning parameters you and others have
mentioned).

-- 
Harald