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
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
Conflict between RA and DHCP in MIF case)
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
)
