Re: IPv6 RA vs DHCPv6 - The chosen one?

[Ray Soucy <rps () maine edu>]

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
> >  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/