mailing list archives
Re: IPv6 RA vs DHCPv6 - The chosen one?
From: Mohacsi Janos <mohacsi () niif hu>
Date: Fri, 23 Dec 2011 06:56:24 +0100 (CET)
On Wed, 21 Dec 2011, Tomas Podermanski 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
Your opinion is very extreme. Another extremity would be to add some
extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms
have their merits. They have to interporate! Every environment should
develop their policy according to their needs!
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
They already do. If not they have to be fixed.
- 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
Administrators are deliberately providing conflicting information?
- The first hop security have to be solved twice - for SLAAC and for
of then uses a differed communication way. SLAAC is part of ICMPv6,
uses "own" UDP communication what does not make things easier.
This can be an argument for remove DHCPv6 completely....
- SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
process in the user space. Diagnostic and troubleshooting is more
Some operating system do the SLAAC processing in user space. What is the
- 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.
I think it is matter of implementation.
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.
But suitable in certain environments.
- SLAAC is quite difficult to secure. One (really only ONE) RA packet
the IPv6 connection for all clients in a local network just in a few
It also happens accidentally by "connection sharing" in Vista, Win7
Their is an RAguard RFC to prevent this.
- The full protection against that behavior it's impossible today.
PACL can be bypassed using extension headers or fragmentation
For solution See propoosal of Fernando Gont about atomic ICMPv6 messages.
- 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
but it does not provide the same level of security.
What is missing?
- Just the same technique was introduced in IPv4 as Router Discovery
Nobody uses it today. Do we really need go through same death way again?
(Oh right, we are already going :-( )
Nobody? Every modern Windows OS.
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.
RA is just matter of swtiching on first hop router. You don't have to
- Frankly said, I have not found any significant benefit that SLAAC brings.
Configuration of thousands of device without much overhead on server side?
Unfortunately there is another issue with DUIDs in DHCPv6. But it is a
little bit differed tale.
It is a big issue.
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
It is written very badly! It has to be completed by results from:
 IPv6 - security threads
 Deploying IPv6 in University Campus Network - Practical Problems
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.