mailing list archives
Re: IPv6 RA vs DHCPv6 - The chosen one?
From: Tomas Podermanski <tpoder () cis vutbr cz>
Date: Fri, 23 Dec 2011 21:06:26 +0100
On 12/23/11 4:33 AM, Owen DeLong wrote:
Sent from my iPad
On Dec 23, 2011, at 3:46 AM, Tomas Podermanski <tpoder () cis vutbr cz> wrote:
On 12/22/11 12:18 AM, Owen DeLong wrote:
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
It makes the client side more difficult to implement (=more expensive).
What worse SLAAC and DHCPv6 are differed protocols, so there is bigger
probability for attacks (overflow, flood etc.). For example in UNIX-like
systems autoconfiguration have to be solved by 3 parts of the system:
1. some SLAAC options are usually processed by a kernel (address
selection, MTU) and behavior of that process can be changed via sysctl
2. some SLAAC options are processed by rdnssd daemon (processing DNS
3. DHCPv6 options are processed byt dhcpv6-client
All those parts have to cooperate together. At the first sight it is
obvious that there is pretty good probability that something can go
wrong. Troubleshooting then is really piece of cake. For example in IPv4
environment we have following scenario:
1. DHCP options are processed by dhcp-client
Except when they are processed by BIOS, Kernel, or something else.
Sure, in all this parts (you probably meant PXE, network booting) we
will have more difficult code. If developers are ok with that and I will
have all that code in PXE, grub and a kerel code...
Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options
are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other
parts of the system, so, there's roughly similar amount of interaction either way.
- 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
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.
I am not thinking about address. It is the easier part - we can use all
provided. There are other options like DNS servers, search list, NTP
If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is
broken, any one of them should work and provide the same answers as the others.
You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on
the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think
this is a tempest in a teacup.
- 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.
Solved for SLAAC -- SEND.
Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any
actual implementations yet.
Right, very easy to write but pretty difficult (impossible) to use
today. None of operating systems supports SEND and some will probably
If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running
just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than
I can not agree with that. Many operators having customers into a shared
segment and uses security features I mentioned before ( again DHCP
snooping, ARP protection, source address validation). In IPv6 is quite
difficult to implement it even thou an ISP have a lot of money for new
equipment. That is a reason why some operators prefer to block all
protocols except IP(v4) and ARP instead of deploying IPv6. So we can not
be surprised then that only less than 0.5% users have native IPv6
connectivity. I do not claim that is the only reason but one small piece
of a bigger problem.
as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx
However, Microsoft does not support SEND in any version of Windows.
I have found only one implementation for Linux
(http://amnesiak.org/NDprotector/) that is not ready for production. So
we can not think seriously about SEND today. SEND also brings another
set of problems like certificate management, etc., but is a little
Right. Actual security is hard. No surprise there. Moreover, administrators are lazy. Also no surprise. Limited
threat, lazy administrators, hard security, no action. This is the same in IPv4, IPv6, and doesn't really change
whether you use SLAAC or DHCP or even static addresses.
It is also question of money. For implementing more difficult
environment the more experienced staff and more money is needed.
- SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
process in the user space. Diagnostic and troubleshooting is more
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 .
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.
I have to admit that less overhead is one of benefit of SLAAC. But
having experience with DHCP(v4) all devices that we have today (phones,
cameras, etc.) do not have a problem to process DHCPv4 packets, so there
is no reason why same devices could not do it for DHCPv6. The sensor
networks mentioned in one mail before is a very special case of use. I
believe SLAAC might be useful there but is not typical case.
How many RFID sensors do you see managed on an IPv4 network? Thought so.
The reality is that IPv6 has to support a much much wider range of hardware and applications than were ever
considered for IPv4. Just because these may not apply to your environment does not mean that they are not important
to other parts of the world.
I do not think that there is problem with that. SLAAC can be still an
option. Today SLAAC is mandatory and DHCPv6 is an option.
- 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
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.
I can not agree. Access switches usually do not support RA-Guard or
IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500,
6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series
(all with K software). All this series are not suitable (means too
expensive) in a role of access switches. What worse RA-Guard can be
So even if you buy 3 times more expensive switches it does not help you
:-(. As I wrote before - SEND is not an option today.
RA-Guard is in most Juniper switches today. Yes, there are improvements needed. However, it's not like DHCP is immune
to spoofing attacks, so, I'm not sure why you think this is so much worse than the current state of IPv4 and/or IPv6
if we went with DHCP only.
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.
- The full protection against that behavior it's impossible today.
PACL can be bypassed using extension headers or fragmentation
Yes and no. RA Guard implementations are getting better at addressing
How that is getting better. Can you provide an example.
No, because some of what I know is currently NDA. However, it's not like vendors aren't hearing about these concerns
and it's not like they aren't working to address them.
- 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.
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.
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.
Agree. The firs option is the answer but you have to have DHCPv6 only
But you don't need to eliminate SLAAC from everyone else's network to make that work. There's no need to deprecate
SLAAC/RA from places where it works just fine to achieve what you want. That's my point.
- 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 :-( )
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.
As I wrote before. I do not think that overhead is an issue today.
And as I wrote before, I think that comes from a narrow view of the implementation spectrum.
- 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.
It is true today, because not all operating systems supports DHCPv6. In
many cases DHCPv6 is not an option.
I have seen environments where even if everything supported DHCPv6, SLAAC would still be a better solution for that
environment. That's my point. Administrators should be able to choose the solution that best fits their environment.
I'm all for the ability to create a DHCP-only environment, but, I don't want to see SLAAC/RA eliminated from
environments where it provides benefit.
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.
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
And when we compare it with IPv4
- send DHCP request to DHCP server
Uh, no. DHCP request is never sent by client to DHCP server. Request is sent to broadcast. Then some magic happens
(helper address) in most cases to forward it to the DHCP server, then some more magic happens to get the response
back to the original client.
I deliberately used just the same description of obtaining information
from a DHCP server. You have twisted it and trying to show DHCP(v4) in
worse light. Just same (as you said) magic happen in DHCPv6. The only
difference is that multicast address is used instead. And there is
another difference. DHCP(v4) client renews an address (and options)
directly from the server where the client get it from. DHCPv6 uses
multicast for whole communication.
- get response
- configure accordingly
Assuming that the client understands all the correct options, that all the options fit in a single packet, etc.,
No waiting for RA packets, no additional "IFs", no additional conditions
and all corner cases are solved. Why it can not work similar in IPv6? I
know, there maybe is many reasons :-).
Uh, no, there are many corner cases I have encountered where DHCPv4 is a non-option and administrators have had no
other choice in IPv4 but to use static addressing. Some of them would actually work just fine with SLAAC.
Can you be more specific? I can not imagine situation where SLAAC could
solves a problem that DHCP would not. So I will be happy to hear that