IPv6 RA vs DHCPv6 - The chosen one?
rps at maine.edu
Wed Dec 21 14:40:19 CST 2011
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
We have been running IPv6 in production for several years (2008) as
well (answering this email over IPv6 now, actually) yet I have
completely different conclusions about the role of RA and DHCPv6.
On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski <tpoder at cis.vutbr.cz> wrote:
> 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
> - DHCPv6 should be extended by route options as proposed in
> - DHCPv6 should be extended by layer 2 address to identify
> client's L2 address (something that we can see in RFC 6221)
> - DHCPv6 should be the common way to autoconfigure an address
> in a IPv6 environment
> 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.
> - Clients have to support both SLAAC and DHCPv6 to be able to work in
> both environments
> - There must be solved a situation what to do when SLAAC and DHCPv6
> provides some conflict information (quite long thread with various
> can be found at
> - 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.
> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
> process in the user space. Diagnostic and troubleshooting is more
> - 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.
> Some other issues are also described in .
> I personally prefer to bury SLAAC once forever for several reasons:
> - In fact SLAAC does nothing more what DHCPv6 can do.
> - 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
> It also happens accidentally by "connection sharing" in Vista, Win7
> - The full protection against that behavior it's impossible today.
> RA-Guard or
> PACL can be bypassed using extension headers or fragmentation
> - 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.
> - 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 :-( )
> Comparing to SLAAC, DHCPv6 have several advantages:
> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it.
> - DHCPv6 can potentially do much more - for example handle an information
> for PXE, options for IP phones, prefix delegation.
> - 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.
> - Frankly said, I have not found any significant benefit that SLAAC brings.
> 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 . I believe that is not what we really wanted.
> For those who are interested in that area there are several
> articles/presentations where we mentioned that topic.
>  IPv6 Autoconfiguration - Best Practice Document
>  IPv6 - security threads
>  Deploying IPv6 in University Campus Network - Practical Problems
> Tomas Podermanski
> On 12/20/11 8:31 AM, Owen DeLong wrote:
>> Different operators will have different preferences in different environments.
>> Ideally, the IETF should provide complete solutions based on DHCPv6 and
>> on RA and let the operators decide what they want to use in their environments.
>> On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote:
>>> IPv6 devices (routers and hosts) can obtain configuration information
>>> about default routers, on-link prefixes and addresses from Router
>>> Advertisements as defined in Neighbor Discovery. I have been told
>>> that in some deployments, there is a strong desire not to use Router
>>> Advertisements at all and to perform all configuration via DHCPv6.
>>> There are thus similar IETF standards to get everything that you can
>>> get from RAs, by using DHCPv6 instead.
>>> As a result of this we see new proposals in IETF that try to do
>>> similar things by either extending RA mechanisms or by introducing new
>>> options in DHCPv6.
>>> We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
>>> DHCPv6 to do what RA does. And now, we have
>>> draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
>>> the NTP information that is currently done via DHCPv6.
>>> My question is, that which then is the more preferred option for the
>>> operators? Do they prefer extending RA so that the new information
>>> loaded on top of the RA messages gets known in the single shot when
>>> routers do neighbor discovery. Or do they prefer all the extra
>>> information to be learnt via DHCPv6? What are the pros and cons in
>>> each approach and when would people favor one over the other?
>>> I can see some advantages with the loading information to RA since
>>> then one is not dependent on the DHCPv6 server. However, the latter
>>> provides its own benefits.
>>> Ravi D.
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
More information about the NANOG