IPv6 RA vs DHCPv6 - The chosen one?

Ray Soucy rps at maine.edu
Thu Dec 22 05:01:37 UTC 2011

Look at that, for once I agree with Owen on all points made. ;-)

On Wed, Dec 21, 2011 at 6:18 PM, Owen DeLong <owen at delong.com> wrote:
> On Dec 21, 2011, at 11:16 AM, Tomas Podermanski wrote:
>> Hi,
>> from my perspective the short answer for this never-ending story is:
>> - SLAAC/RA is totally useless, does not bring any benefit at all
>>  and should be removed from IPv6 specs
> Except that there are many environments where that's not true.
>> - DHCPv6 should be extended by route options as proposed in
>>  http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
> I haven't read the particular draft, but, I do think dhcpv6 route options
> should be added.
>> - DHCPv6 should be extended by layer 2 address to identify
>>  client's L2 address (something that we can see in RFC 6221)
> I'm neutral on this one. Once you get used to dealing with it, using DUIDs
> isn't so bad. It does (at least potentially) allow you to identify the same client
> across a NIC replacement, which can be useful in some environments.
>> - DHCPv6 should be the common way to autoconfigure an address
>>  in a IPv6 environment
> DHCPv6 should be a common option for operators that want to use it, but
> there is no reason to take SLAAC away from operators that are happy with
> it.
>> The long answer is:
>> I completely disagree with opinion that both DHCPv6 and RA (SLAAC)
>> should be supported. It is easy to say that both have place but it has
>> some consequences. I and my colleagues have been working on deploying
>> IPv6 for a few years and from the operation perspective we conclude into
>> a quite clear opinion in that area. Both SLAAC and DHCPv6 uses a
>> opposite principles although the goal is just one. DHCPv6 is based on a
>> central DHCPv6 server that assigns addresses. SLAAC does opposite -
>> leaves the decision about the address on a client side. However we have
>> to run both of them in a network to provide all necessary pieces of
>> information to the clients (default route and DNS). This brings many
>> implementation and operational complications.
> I agree that the requirement to run both is broken. I don't agree that this
> means we should remove the option of using SLAAC in environments
> where it makes sense.
>> - Clients have to support both SLAAC and DHCPv6 to be able to work in
>>  both environments
> So?
>> - There must be solved a situation what to do when SLAAC and DHCPv6
>>  provides some conflict information (quite long thread with various
>> opinions
>>  can be found at
>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14949.html)
> SLAAC and DHCPv6 can't really provide conflicting information unless
> the router is misconfigured. Even if a host gets different answers for the
> same prefixes from SLAAC and DHCP, it should be able to use both
> host addresses. There's the question of source address selection, but,
> the answer to that question at the IETF level should only be a matter
> of what the default answer is. There are configuration options for setting
> host source address selection priorities.
>> - The first hop security have to be solved twice - for SLAAC and for
>> DHCPv6. Both
>>  of then uses a differed communication way. SLAAC is part of ICMPv6,
>> but DHCPv6
>>  uses "own" UDP communication what does not make things easier.
> Solved for SLAAC -- SEND.
> Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any
> actual implementations yet.
>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
>>  process in the user space. Diagnostic and troubleshooting is more
>> complicated.
> That seems like an argument for SLAAC, if anything.
>> - DHCPv6 is currently tied with SLAAC (M,O flags), what means that
>>  a DHCPv6 client have to wait until some RA message arrives to start DHCPv6
>>  discovery. That unnecessary prolongs whole autoconfiguration process.
> While I agree with you that the standard is broken in this regard, there is at
> least one OS vendor that already violates that rule anyway.
>> Some other issues are also described in [1].
>> I personally prefer to bury SLAAC once forever for several reasons:
>> - In fact SLAAC does nothing more what DHCPv6 can do.
> Yes, but, it does it in a much simpler way with a lot less overhead which
> can be a benefit in some environments.
>> - SLAAC is quite difficult to secure. One (really only ONE)  RA packet
>> can destroy
>>  the IPv6 connection for all clients in a local network just in a few
>> milliseconds.
> This is what RA-Guard is for and it's quite simple to deploy. SEND makes
> it even better, but is a bit more complicated.
>>  It also happens accidentally by "connection sharing" in Vista, Win7
> This is an argument for burying Windows, not an argument for burying
> SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you
> were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6
> instead of breaking SLAAC.
>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf)
>> - The full protection against that behavior it's impossible today.
>> RA-Guard or
>>  PACL can be bypassed using extension headers or fragmentation
>>  (http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf)
> Yes and no. RA Guard implementations are getting better at addressing
> those issues.
>> - With SLAAC is difficult to implement security features like ARP/ND
>>  protection/inspection, IP source guard/Dynamic lock down, because
>>  all this techniques are based on a MAC-IP database created during
>>  a communication with a DHCP server. There are some attempts (ND
>> protection, SAVI)
>>  but it does not provide the same level of security.
> Most sites don't need that level of security. I agree there should be a
> way to disable SLAAC reliably at a site as a policy matter, but, frankly
> the techniques you're talking about come in one of two flavors:
>        1.      They dynamically enable the switch to accept packets from
>                a client, in which case, SLAAC based clients would be blocked
>                until they registered with DHCP anyway.
> or
>        2.      They don't effectively block an attacker who cobbles his own
>                address even without SLAAC.
> In the former case, you get the security you want and force DHCP anyway,
> so I don't see a problem. In the latter case, you only had the illusion of
> security to begin with, so, SLAAC just makes it easy to disillusion you.
>> - Just the same technique was introduced in IPv4 as Router Discovery
>> (RFC 1256).
>>  Nobody uses it today. Do we really need go through same death way again?
>>  (Oh right, we are already going :-( )
> Not a fair comparison. There were a number of additional issues with 1256 that
> prevented it from gaining acceptance in IPv4.
>> Comparing to SLAAC, DHCPv6 have several advantages:
>> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it.
> That just makes it familiar, not necessarily better for all environments.
>> - DHCPv6 can potentially do much more - for example handle an information
>>  for PXE, options for IP phones, prefix delegation.
> True, but, that comes at a cost of complexity and overhead which may not be
> desirable in all environments.
>> - DHCPv6 allows handle an information only for some hosts or group of
>>  hosts (differed lease time, search list, DNS atc.). With SLAAC it is
>>  impossible and all host on a subnet have to share the same set of
>>  the configuration information.
> Which is not an issue in 99+% of environments.
>> - Frankly said, I have not found any significant benefit that SLAAC brings.
> Perhaps you have not, but, others have. I have seen environments where
> SLAAC is much more useful than DHCPv6. I've seen environments where
> DHCPv6 is needed.
>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a
>> little bit differed tale.
>> At the beginning the autoconfiguration was meant as easy to use and easy
>> to configure but the result turned out into kind of nightmare. For those
>> who do not know what I am talking about I prepared two images. The first
>> one shows necessary communication before first regular packet can be
>> send over IPv4 (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png)
>> and just the same thing in IPv6
>> (http://hawk.cis.vutbr.cz/~tpoder/tmp/autoconf/IPv4.png). In IPv4 we
>> have very simple answer if somebody asks for autoconfiguration  = use
>> DHCP. In IPv6 the description how things work have to be written into
>> more than 10 pages [1]. I believe that is not what we really wanted.
> That's no really a fair characterization. Yes, DHCPv6 is more complex
> than DHCPv4, but, not significantly so.
> In reality it can be summed up relatively quickly:
> 1.      Choose link local address (fe80::EUI64)
> 2.      Send RS packet to all-routers multicast address
> 3.      Receive one or more RA packets.
>        a. if Packet contains prefix information:
>                i.      Set timers, apply addresses to interfaces
>                        (first regular packet can be sent at this point)
>        b. If packet has O bit set:
>                i.      Send DHCPv6 request to DHCP server
>                ii.     Get response
>                iii.    Configure accordingly.
>                        (If a was false (a and b are not mutually exclusive), then
>                        you can now send your first regular packet).
> Yes, there are a few corner cases not completely addressed above,
> but, unless you're building the software to implement the standards,
> they are mostly irrelevant. Even if you add them in (interactions between
> the M, A, and O bits), you can still describe it in about a page, not
> ten.
> Owen

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

More information about the NANOG mailing list