IPv6 Pain Experiment

Wed Oct 2 20:46:35 UTC 2019

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
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,
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.

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

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.)

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.