[161282] in North American Network Operators' Group
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Mar 6 21:51:25 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <51378FD8.60804@mompl.net>
Date: Wed, 6 Mar 2013 18:48:10 -0800
To: Jeroen van Aart <jeroen@mompl.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 6, 2013, at 10:50 AM, Jeroen van Aart <jeroen@mompl.net> wrote:
> On 03/05/2013 05:41 PM, Owen DeLong wrote:
>> I think it's also important to cover the following topics somewhere =
in the process:
>>=20
>> 1. This will affect the entire organization, not just the IT =
department and
>> will definitely impact all of apps, sysadmin, devops, =
operations, and
>> networking teams within the IT department.
>>=20
>> 2. Training will be required for virtually all levels of the =
organization. End users
>> won't need more than a ~2 hour introduction to what to look for =
during and
>=20
> I've migrated (or enabled) offices (and homes) to IPv6 without them =
even realising it. If it's just enabling IPv6 connectivity there may be =
very little to be done with regards to training and informing end users. =
The beauty of IPv6 in my experience is that it is quite transparent, you =
don't even notice it is there (or shouldn't, if done properly).
You can usually get away with this for the home.
In the enterprise, I wouldn't recommend it.
If the users get surprised, it's a lot worse than if they know what's =
coming. Rumors rapidly get way out of hand before corrective action can =
quell a problem. OTOH, if the user base knows what to expect and that =
the problems are anticipated and/or being properly worked, you tend to =
get a greater level of patience and understanding.
Further, a little training up front can go a long way to getting better =
user reports into the help desk to reduce the time consumed in =
troubleshooting.
As I said, a 2 hour introduction is about all that's required, but it =
really is helpful.
As to other things, consider that once you enable stuff on IPv6, you =
need to be able to monitor it. If you're looking at IPv6 transition from =
an enterprise perspective, it's not just delivering IPv6 to every =
desktop, but making sure that all of your internal applications and =
services are also available on IPv6. That can be a significant =
development undertaking.
I agree just enabling the network to use it is a useful and positive =
step forward that can be taken fairly easily.
However, it's certainly not an end in and of itself and should not be =
where your efforts stop in any real plan.
> Adapting your current software to IPv6, that could be more tricky. =
Although if you use the right IPv6 aware libraries and functions it =
could be relatively easy in code. In my own apps it's just a matter of =
changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done so =
yet. Although interestingly that may have complications (sudden loss of =
connectivity or more subtle issues). So I can relate to the fact it can =
be tricky.
Yep. The important thing is for the enterprise to be aware of what is =
required and realize that it spans development, systems administration, =
networking, logistics, and will have end-user impacts worthy of some =
consideration.
Owen
