IPv6 RA vs DHCPv6 - The chosen one?

[rps at maine.edu (Ray Soucy)]

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
http://www.networkmaine.net/