IPv6 Pain Experiment

Wed Oct 2 21:23:42 UTC 2019

On Wed, Oct 2, 2019 at 3:46 PM John Levine <johnl at iecc.com> wrote:

> In article <CAHdm834jbwky2sPpH6HmJoYu=
> Rcjz0Hb1bCq2zy1hsdYOSN9sQ at mail.gmail.com> you write:
> >For a small organization with limited staff and small margins, I'm curious
> >where the actual burden in supporting IPv6 lies. In my experience, it's
> not
> >any more costly than deploying IPv4 is ...
>
> Right, but that means it doubles your deployment costs since IPv4
> isn't going away any time soon.  First you have to get IPv6 into your
>

I'd strongly disagree that it anywhere near doubles costs. Ultimately
you're buying hardware X and it's going to cost whatever it costs. So what
more do you really need to do to support IPv6? Well, let's say you're using
OSPF. This means you'll also need to use OSPFv3, but that's not hard
because your OSPFv3 configs are going to basically mirror your OSPF
configs. You'll need to run IPv6 over iBGP, perhaps, and over eBGP to your
peers and transits, but that's just another set of addresses bound to
interfaces, sessions that mirror the IPv4 ones, and policy rules/filters.
If you're doing super heavy TE, then the filter configs might take some
effort, but if we're talking about smaller shops, doing heavy TE is
unlikely. At that point, you just add a v6 address to your layer3
interfaces and you're good to go for the network side.

Most of the time you spend configuring things won't be v4 or v6 specific,
and the v4 specific configurations can be copy/pasted with a quick string
swap to support v6 in a lot of cases.

network, directly or through a tunnel (thanks, HE.)  Then you have to
> assign IPv6 addresses to every device that has a name, put that in
> your DNS and configure the devices, either by whatever means the
> device has (typically a web control panel) or maybe by a DHCP entry,
>

But once you have the basics down - your layer3 gateways, routing
protocols, etc - this process of getting the hosts on board can take as
long as you'd like. The only deadlines are ones you impose.

if the device can be persuaded to use DHCP rather than SLAAC.  In
> many cases, notably web servers, you need yet more configuration to
> connect each v6 address with whatever service the v6 adddress is
> supposed to provide.
>

I've done this plenty of times and never found it to be particularly
difficult or time-consuming. If you have a lot of systems, hopefully you
have some sort of automation or configuration management which will allow
you to test and deploy to production in at least a less-manual fashion. If
you don't have a lot of systems, then you can just iterate through them and
take 10-15 minutes each to get a v6 address bound and firewall rules
updated.

> Then you have to set up firewall rules to match your v4 firewall rules.
>

Which usually means copy/pasting and a quick string swap.

> Then you spin it all up, and you have to check that every device
> actually does respond on its IPv6 address, and that it acts reasonably
> to mixed v4 and v6 requests (so-called happy eyeballs.)
>

Or just throw it in the monitoring system you already have, but again, this
can all be part of a process that happens over as long a course of time as
you need it to.

>
> None of this is impossible, I've done it all, but I've also often
> asked myself what exactly is the benefit of doing all this.  On my
> home network the v4 stuff is behind a NAT so v6 allows me access
> to devices from the outside (carefully managed with the firewall)
> but on my hosted servers which have v4 addresses for everything, meh.
>

I think ultimately the perception of the work required to deploy IPv6 is a
much greater hurdle to IPv6 adoption than the actual work required to
deploy IPv6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191002/99828f1c/attachment.html>