Re: IPv6 to the desktop

[Clark Gaylord <cgaylord () VT EDU>]

At Virginia Tech, we have been routing IPv6 natively on our campus since
the late 1990s, adding residence halls a few years later. It has simply
"been there" for nearly twenty years, and a substantial amount of LAN and
WAN traffic on campus is IPv6. In some areas local traffic is over 80% and
at times inter-domain traffic in/out of campus is over 50% IPv6. There are
many instances of IPv6-only systems, and in some cases this choice is made
for enhanced security, but I prefer to think of it more as a simpler, more
flexible design, which drives its own security advantages.

In 2008, I recall an Internet2 Joint Techs meeting where we declared the
technical challenges effectively "solved", and we were regularly seeing
successful end-to-end communication between campuses using IPv6. Of course
there is even now an occasional implementation glitch (e.g. most MLD
snooping implementations continue to be seriously flawed), and there
continue to be corner cases of discussion at the IETF level in terms of
protocol nuances. These are not serious impediments to operating IPv6 (aka
the current version of the Internet Protocol) as a first-class network
protocol in any environment.

In addition to simply being the responsible thing to do, we have realized
numerous advantages to having such a broad adoption of IPv6. Most notable
in this context is in the ability to limit the need of network address
translation. Over the last several years we have been using legacy NAT
(sometimes referred to as NAT44) to extend our addresses in wireless and
residence halls. This has made security analysis significantly more
difficult, as sensors (e.g. taps for IPS) must be placed in parts of the
network where they are not ideal and/or NAT state must be collected and
used throughout the security analysis. These data continue to be
"imperfect". Security is *always* enhanced when addressing is consistent
end-to-end, making the job of security analysis relatively easy and
transparent.

A secondary benefit is the use of temporary addresses on client systems,
the so-called privacy extension addresses. These help a lot with general
obscurity of client systems on the public internet, though of course they
are not a complete story to client system privacy. These temporary
addresses can be an impediment to operations in *server* systems, btw,
notably mail servers, so do be aware of that.

A priori, you might be inclined to wring your hands about exploding NDP
data from those temporary addresses, but in reality this is not as tragic
as you might fear. A properly implemented IP-to-MAC database can easily
accommodate the extra data and it's far better than the common connection
tracking data problem seen in overload NAT/PAT configurations.

Now with that said, the security product market sometimes lags in IPv6
support. Bro/Zeke is completely there, but some systems are less so. I have
been very disappointed by Palo Alto,  (a good example: although you can
configure PanOS with IPv6 DNS servers, it never will use IPv6 to resolve
DNS queries -- this kind of stupidity is frequent). Ten years ago we began
using IPv6 support as a minimum litmus test for general network vendor
cluefulness, and it has often been a very parsimonious proxy for this
purpose. Today, this is arguably the case in the security product space.

I also predicate this on having an environment in which you are able to
capture and retain layer 2-to-3 address mapping (ARP and NDP respectively)
and layer 2 forwarding information at the edge. In my experience, having
these data is essential to an effective security posture, though in some
environments a lack of central control of network operations or
organizational intransigence or other factors may have led you to address
these matters through other means (or you still haven't addressed it, and
you therefore harbor a nugget of self-loathing deep inside). There are
other approaches, and some might make IPv6 adoption "harder" for you (these
decisions may also foster such an aforementioned nugget.) At any rate, with
good data collection, adapting to IPv6 is hopefully not too terrible (you
did think to use PostgreSQL inet data types, right?)

Switching hats from my network engineer/security analyst role to research
institute CIO: in our corner of Virginia Tech, IPv6 plays an essential role
in system architecture and IT strategy, including from a security
perspective. An obvious example might be in connected and autonomous
vehicle research, where IPv6's huge address space has obvious benefit of we
are addressing every vehicle on the roads. While this is true, there's some
underbelly truth that it's a mixed bag: another truism is that
infrastructure components (e.g. signal controllers) tend to have very long
service lives, so there's a bit of a long tail for 100% IPv6 in the
intelligent transportation system space.

So, while we do require IPv6 for ITS, there are some ugly corners. However,
from a "protected data enclave/research computing/HPC" integration
perspective, IPv6 is essential, and once again this is because of the
assurance of end-to-end addressing. Since I have reasonable assurance of
"where" another host resides on the network (after all, you can spoof a
host but only within a subnet), I can implement sensible, yet flexible,
IP-layer access controls, either on hosts or at network/subnet boundaries.
This allows me to have secure data reduction labs that still have access to
HPC and large-scale storage resources across campus without expensive and
cumbersome tunneling. This extends even to research partners at remote
sites, who might have a very limited legacy IP allocation (e.g. a federal
research lab with a paltry /28).

Finally, the depth of understanding that our rank and file IT operations
staff has is greatly enhanced by using IPv6 on all hosts. It's an indirect
effect to be sure, but just as it is a useful proxy for vendor clue, so too
it raises the bar for staff. Rising tides and all that.

Hopefully this gives you something to chew on.

Regards
Clark

--
Clark Gaylord
cgaylord () vt edu
... autocorrect may have improved this message ...

On Mon, Nov 25, 2019, 09:56 Garmon, Joel <JSG () pitt edu> wrote:

> Hi,
>
> Does anyone have IPv6 implemented on their internal network to the
> desktop?  If you do, can you provide the benefits?
>
> Thank you,
>
> Joel Garmon
> Chief Information Security Officer
> Computing Services and Systems Development (CSSD)
> University of Pittsburgh
> 412-624-5595
>
>
>
> **********
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community