Cost of IPv6 for IT operations team

[Nick Buraglio]

This is a really good list, thanks for sharing. I just gave a talk on this
topic this week, this is timely. For operational reality, the
implementation phase is highly dependent on the environment. For an
environment that has full control of systems to peerings, the overhead will
be less than an environment that has less control on end points or has a
fractured internal structure.

The point of the protocols being ships in the night is very important and
is often forgotten, keeping that in mind is key as is minimizing the method
of users disabling IPv6 to fix issues. I often recommend someone on the
deployment team setting up an IPv6 only station and using it to see what
does and does not function, both internally and externally. A VM works well
for this but I find that an actual workstation makes me actually use it
more. This does a few things, but most importantly it makes it obvious what
doesn't work on v6, which will be at least 50% of your initial roll out
troubleshooting.

Keep good metrics and monitoring on *both* IPv4 and IPv6, this helps both
up front and over time. Anything that is measured and monitored in v4
should also by measured and monitored for v6 in my opinion. Make sure your
security policy is as close to v4 as you can reasonably get it (but be
mindful of ICMP) .his includes all packet captures, filters, ACLs and
security appliance provided services.

nb






---
Nick Buraglio
ESnet Network Engineering Group (AS293)
Lawrence Berkeley National Laboratory
buraglio at es.net
+1 (510) 995-6068

On Thu, Mar 26, 2015 at 6:33 AM, John Mann <john.mann at monash.edu> wrote:

> Hi,
>
> Deployment work overload could be 5%.
>
> For deployment of dual stack, you should minimise work overload by:
> - taking advantage of normal refresh cycles and bundle enabling of dual
> stack into the refresh or deployment of new management systems, procedures,
> and services
> - picking "low hanging fruit" tasks that will advance deployment with
> minimum effort
>    (some legacy systems may never be capable of or required to be accessed
> over IPv6 - leave them).
> - don't provide some IPv6 network or service that doesn't have similar
> performance and reliability as IPv4 has; wait until you can
> - taking things slowly to allow time for staff to mentally adjust to
> dual-stack as being normal,
>   and to keep IPv6 issues from being on the critical path
>
> For run phase, I think it really depends upon what type of IT issues you
> normally see:
> - something used to work over network and now it doesn't == need to check
> IPv6 as well as IPv4.
> - database management, or PC malware == no IPv6 involvement
> - IPv4 address space micromanagement == easy as IPv6 /64 subnet is never
> too small
>
> Run-time recommendations:
> - make sure setup *and* changes to firewall / ACL rules permit/deny
> equivalently for IPv4 and IPv6
> - promptly investigate any network problems that could be blamed on IPv6
> to avoid users advising each other
>    "just turn off IPv6 to fix things", and then never turning it back on
> again.
>
> Thanks,
>     John
>
>
>
>
>
>
>
>
>
> On 26 March 2015 at 20:04, BERENGUER Christophe <
> Christophe.BERENGUER at solucom.fr> wrote:
>
>>  Hello everybody,
>>
>>
>>  I work for a consulting firm.
>>
>>
>>  For a client, I would like to estimate the work overload for IT
>> operations team to deploy IPv6 dual stack and for day to day operations.
>>
>>
>>  On the internet, I have found an estimation around 20% of work overload
>> for the run phase. But if you have operational feedback it would be the
>> best!
>>
>>
>>  Thanks in advance for your answers,
>>
>> Have a nice day.
>>
>>
>>  Best regards,
>>
>>
>>   *Christophe BERENGUER*
>> Consultant
>> Fixe : +33 (0)1 49 03 85 86
>> christophe.berenguer at solucom.fr
>> solucom
>> Tour Franklin : 100 - 101 terrasse Boieldieu
>> 92042 Paris La Défense Cedex
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150326/12cf2423/attachment.htm>