Re: IPv6 and DHCP

[Phillip Deneault <deneault () WPI EDU>]

Woah... don't go blaming that on me. That's Randy's idea. ;-)

There are several methods one could use to address an IPv6 network.  I
have a technical presentation in which I details lots of this
information, but I'll go through a few quickly here so people get a
sense of the problem and where to go with it.  Forgive me if you've
heard this song before. :-)

There are three main ways you address an IPv6 network, statically,
dynamically via SLAAC, and dynamically via DHCPv6.  There are pros and
cons to each one.

Static addressing: Performed the same way you would with IPv4 in all the
same situations, managed the same way, with all the same caveats and
problems.  Most sites do not statically address large parts of their
campus because it is a beast to maintain.

To the point that Randy made, you could assign one address, or one
subnet per device you ever see, but IPv6 still follows address
allocation and subnetting conventions just like IPv4, so that model
doesn't work because most sites don't build their networks that way.
Additionally, it might be impractical to define that many routes in your
router.  Additionally, the most traditional way an IPv6 address is
broken down is by a 64-bit prefix length (AKA subnet identifier) and a
64-bit host length (host address) and in normal operation a system may
have multiple host addresses in the same prefix, acting somewhat like a
mini subnet (although routing for those instances is handled inside the
system stack).

In short, the common convention would NOT be to do it this way, but
Randy is an out-of-the-box thinker and its an interesting scenario to
think about.

The more common conventions are SLAAC and DHCPv6.

SLAAC (StateLess Address AutoConfiguration) takes information made
available on an IPv6 network via router advertisements to populate the
prefix length, and pairs it with a host address the system will
automatically generate to make a valid address.  The address space is so
large (2^64) that collisions are highly improbable.  SLAAC does NOT
configure (at present) any other information useful for making
enterprise networks run... like DNS servers or NTP servers.  That's
generally not how most universities want to operate.  There is currently
a RFC to add DNS information to SLAAC, but I have not seen an
implementation yet.  (http://tools.ietf.org/html/rfc6106)

DHCPv6 has two modes, one that works WITH SLAAC to provide the
additional information, and another mode where it provides everything
including the routable addressing.  It is likely you will run a DHCPv6
server on your network in one of these two modes.  A key difference in
DHCPv6 and DHCPv4 is the use of a 'DUID' instead of a MAC address to key
information from.  In fact, the MAC address does not have to be provided
at all to a DHCPv6 server to get an address.  It was a design decision
that the DUID would change as minimally as possible, typically ONLY
changing when the system was re-formatted.  Since a DUID defines a
system and not a network card, the same DUID can be used on multiple
networks, which breaks the model of most campus's existing IPv4 network
registration systems, so even if you thought about making people record
their DUID in your netreg system, you might find yourself coding a
special case.

At my university, using a MAC-based NAC system to only allow switches to
pass traffic for which we have a registered MAC address, and utilizing
SLAAC with DHCPv6 is _probably_ the way we are going to go initially
that offers the most parity.  That might change as we develop more
experience in managing hybrid v4/v6 networks and determine what the
strengths and weaknesses of the approach are.

What is going to make or break any of these strategies from a security
perspective is:

1. How much oversight on IP utilization, user IP tracking, and
user-to-physical-location tracking do you need for your environment?

2. What technologies do you have in place on IPv4 networks which can
help you manage both similarly?  (v4/v6 feature parity on layer 2
devices, NAC methodologies, firewalls and other security devices, etc)

3. Can you get some of this information by other means like polling
routers for NDP information (the IPv6 equivalent of ARP)?

4. What does your policy landscape looks like?

Some of you might be realizing why I have a 90 minute presentation going
over this sort of thing... :-)

Shameless plug:  I am presenting my IPv6 technical talk in Connecticut
on June 4th, so if you want to talk about these or other IPv6 topics and
you are in the area, you may wish to sign up.
http://www.nercomp.org/index.php?section=events&evtid=170

Thanks,
Phil


On 5/23/2012 8:48 AM, John Hoffoss wrote:
> One interesting proposal coming out of the IPv6 presentation by Randy
> Marchany and Phillip Deneault at EDUCAUSE Security last week was the
> possible idea that you statically assign addresses using DHCP, even
> guests and devices you may only ever see once. I'm not deep enough on
> any of the tooling to know if the capability exists today, but if we
> have enough space in IPv6 to assign addresses to every cell (using a
> rough 10 trillion cell estimate) in every human on earth, we can
> probably afford to assign static addresses to every MAC we ever see.
> Of course, we hopefully don't bed the MAC into that address to make
> addressing privacy concerns just a little easier.
>
>
> -jth
>
> On May 10, 2012, at 14:43, "John Ladwig" <John.Ladwig () SO MNSCU EDU>
> wrote:
>
> > I think even within the IETF there's no longer a strong assumption
> > that IPv6 will be "self-managing" in all, or even most, networks.
> >
> > Since we're in a security forum, I think it's pretty easy for us to
> > realize that "self-managing networks" would need an awful lot of
> > bolt-around management/monitoring tricks to keep up with the normal
> > sorts of incident response that we deal with daily in IPv4
> > networks.
> >
> > My personal expectation is that the IPv6 internet will end up much
> > like the current IPv4 Internet - a mix of static addressing for
> > servers and network devices run by organizations, and DHCP in
> > client networks.  Future Internet-of-devices scenarios may result
> > in good use cases for SLAAC, but I can't personally fathom how I'd
> > manage response on a big campus network of SLAAC+Privacy mode
> > addressing on end-user devices.
> >
> > I'd also be interested in experience reports; our IPv6 work hasn't
> > quite gotten to DHCPv6 testing.
> >
> > -jml
> >
> > -----Original Message----- From: The EDUCAUSE Security Constituent
> > Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of
> > Martin Manjak Sent: Thursday, May 10, 2012 2:29 PM To:
> > SECURITY () LISTSERV EDUCAUSE EDU Subject: [SECURITY] IPv6 and DHCP
> >
> > If you're running IPv6, and you've tested, or deployed, DHCP tools,
> > we are interested in what you may have discovered.
> >
> > Our staff were using the following as a starting place for looking
> > into this issue:
> > https://en.wikipedia.org/wiki/IP_address_management
> >
> > Granted, we could have a debate about whether it makes sense to
> > manage an addressing protocol designed to be self-administering.
> > But I think we have to first determine whether or not it's
> > feasible.
> >
> > So any experience with the products on the wikipedia page, or
> > anything else, would be greatly appreciated.
> >
> > Marty
> >
> >
> >
> > Martin Manjak CISSP, GIAC GSEC-G Information Security Officer 
> > University at Albany MSC 209 518/437-3813
> >
> > The University at Albany will never ask you to reveal your
> > password. Please ignore all such requests.

-- 
--------------------------------------------------------------------
  WPI Information Technology will never ask for your password and
you should never give it.  http://www.wpi.edu/+infosec/phishing.html
--------------------------------------------------------------------
Phil Deneault                           Information Security Officer
deneault () wpi edu                              Information Technology
http://www.wpi.edu/~deneault/        Worcester Polytechnic Institute
--------------------------------------------------------------------