Educause Security Discussion mailing list archives
Re: IPv6 and DHCP
From: Phillip Deneault <deneault () WPI EDU>
Date: Wed, 23 May 2012 11:59:54 -0400
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 --------------------------------------------------------------------
Current thread:
- IPv6 and DHCP Martin Manjak (May 10)
- Re: IPv6 and DHCP John Ladwig (May 10)
- Re: IPv6 and DHCP Kern, Paul (May 10)
- Re: IPv6 and DHCP John Hoffoss (May 23)
- Re: IPv6 and DHCP Phillip Deneault (May 23)
- Compromised Accounts Procedures Robert Meyers (May 23)
- Re: Compromised Accounts Procedures Tonkin, Derek K. (May 23)
- Re: Compromised Accounts Procedures Aaron Kirby (May 23)
- Re: Compromised Accounts Procedures Jacobson, Dick (May 23)
- Re: Compromised Accounts Procedures Aaron Kirby (May 23)
- Re: Compromised Accounts Procedures Robert Meyers (May 23)
- Re: Compromised Accounts Procedures Tonkin, Derek K. (May 23)
- Re: Compromised Accounts Procedures Rich Graves (May 23)
- Re: Compromised Accounts Procedures Bidwell, Lesley (May 23)
- Re: Compromised Accounts Procedures Pollock, Joseph (May 23)
- Re: IPv6 and DHCP John Ladwig (May 10)