[147790] in North American Network Operators' Group
Re: IPv6 RA vs DHCPv6 - The chosen one?
daemon@ATHENA.MIT.EDU (Ray Soucy)
Thu Dec 22 00:02:38 2011
In-Reply-To: <9B747991-09CC-47E2-A245-846C3ABD9005@delong.com>
Date: Thu, 22 Dec 2011 00:01:37 -0500
From: Ray Soucy <rps@maine.edu>
To: Owen DeLong <owen@delong.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@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
>> =A0and 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
>> =A0http://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
>> =A0client'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 DUID=
s
> isn't so bad. It does (at least potentially) allow you to identify the sa=
me client
> across a NIC replacement, which can be useful in some environments.
>
>> - DHCPv6 should be the common way to autoconfigure an address
>> =A0in 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 th=
is
> 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
>> =A0both environments
>
> So?
>
>> - There must be solved a situation what to do when SLAAC and DHCPv6
>> =A0provides some conflict information (quite long thread with various
>> opinions
>> =A0can 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 th=
e
> 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 settin=
g
> host source address selection priorities.
>
>> - The first hop security have to be solved twice - for SLAAC and for
>> DHCPv6. Both
>> =A0of then uses a differed communication way. SLAAC is part of ICMPv6,
>> but DHCPv6
>> =A0uses "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
>> =A0process 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
>> =A0a DHCPv6 client have to wait until some RA message arrives to start D=
HCPv6
>> =A0discovery. 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) =A0RA packet
>> can destroy
>> =A0the 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.
>
>> =A0It 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-greg=
r.pdf)
>> - The full protection against that behavior it's impossible today.
>> RA-Guard or
>> =A0PACL can be bypassed using extension headers or fragmentation
>> =A0(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
>> =A0protection/inspection, IP source guard/Dynamic lock down, because
>> =A0all this techniques are based on a MAC-IP database created during
>> =A0a communication with a DHCP server. There are some attempts (ND
>> protection, SAVI)
>> =A0but 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:
>
> =A0 =A0 =A0 =A01. =A0 =A0 =A0They dynamically enable the switch to accept=
packets from
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a client, in which case, SLAAC based clien=
ts would be blocked
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0until they registered with DHCP anyway.
> or
> =A0 =A0 =A0 =A02. =A0 =A0 =A0They don't effectively block an attacker who=
cobbles his own
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0address 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 o=
f
> 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).
>> =A0Nobody uses it today. Do we really need go through same death way aga=
in?
>> =A0(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 i=
t.
>
> That just makes it familiar, not necessarily better for all environments.
>
>> - DHCPv6 can potentially do much more - for example handle an informatio=
n
>> =A0for 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
>> =A0hosts (differed lease time, search list, DNS atc.). With SLAAC it is
>> =A0impossible and all host on a subnet have to share the same set of
>> =A0the configuration information.
>
> Which is not an issue in 99+% of environments.
>
>> - Frankly said, I have not found any significant benefit that SLAAC brin=
gs.
>
> 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 =A0=3D us=
e
>> 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. =A0 =A0 =A0Choose link local address (fe80::EUI64)
> 2. =A0 =A0 =A0Send RS packet to all-routers multicast address
> 3. =A0 =A0 =A0Receive one or more RA packets.
> =A0 =A0 =A0 =A0a. if Packet contains prefix information:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i. =A0 =A0 =A0Set timers, apply addresses =
to interfaces
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(first regular packet can =
be sent at this point)
> =A0 =A0 =A0 =A0b. If packet has O bit set:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i. =A0 =A0 =A0Send DHCPv6 request to DHCP =
server
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ii. =A0 =A0 Get response
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0iii. =A0 =A0Configure accordingly.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(If a was false (a and b a=
re not mutually exclusive), then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you can now send your firs=
t 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
>
>
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
