Re: IPv6 RA vs DHCPv6 - The chosen one?

[Ray Soucy <rps () maine edu>]

I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)

We have been running IPv6 in production for several years (2008) as
well (answering this email over IPv6 now, actually) yet I have
completely different conclusions about the role of RA and DHCPv6.
Weird.

On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski <tpoder () cis vutbr cz> 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
> - DHCPv6 should be extended by route options as proposed in
>  http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
> - DHCPv6 should be extended by layer 2 address to identify
>  client's L2 address (something that we can see in RFC 6221)
> - DHCPv6 should be the common way to autoconfigure an address
>  in a IPv6 environment
>
> 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.
>
> - Clients have to support both SLAAC and DHCPv6 to be able to work in
>  both environments
> - 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)
> - 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.
> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
>  process in the user space. Diagnostic and troubleshooting is more
> complicated.
> - 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.
>
> 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.
> - 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.
>  It also happens accidentally by "connection sharing" in Vista, Win7
>
> (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)
> - 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.
> - 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 :-( )
>
> Comparing to SLAAC, DHCPv6 have several advantages:
> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it.
> - DHCPv6 can potentially do much more - for example handle an information
>  for PXE, options for IP phones, prefix delegation.
> - 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.
> - Frankly said, I have not found any significant benefit that SLAAC brings.
>
> 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.
>
> For those who are interested in that area there are several
> articles/presentations where we mentioned that topic.
>
> [1] IPv6 Autoconfiguration - Best Practice Document
> http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd117.pdf
>
> [2] IPv6 - security threads
> http://www.fit.vutbr.cz/research/view_pub.php?id=9835
>
> [3] Deploying IPv6 in University Campus Network - Practical Problems
> http://www.fit.vutbr.cz/research/view_pub.php?id=9836
>
>
> Regards,
>    Tomas Podermanski
>
>
>
> On 12/20/11 8:31 AM, Owen DeLong wrote:
> > Different operators will have different preferences in different environments.
> >
> > Ideally, the IETF should provide complete solutions based on DHCPv6 and
> > on RA and let the operators decide what they want to use in their environments.
> >
> > Owen
> >
> > On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote:
> >
> > > Hi,
> > >
> > > IPv6 devices (routers and hosts) can obtain configuration information
> > > about default routers, on-link prefixes and addresses from Router
> > > Advertisements as defined in   Neighbor Discovery.  I have been told
> > > that in some deployments, there is a strong desire not to use Router
> > > Advertisements at all and to perform all configuration via DHCPv6.
> > > There are thus similar IETF standards to get everything that you can
> > > get from RAs, by using DHCPv6 instead.
> > >
> > > As a result of this we see new proposals in IETF that try to do
> > > similar things by either extending RA mechanisms or by introducing new
> > > options in DHCPv6.
> > >
> > > We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
> > > DHCPv6 to do what RA does. And now, we have
> > > draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
> > > the NTP information that is currently done via DHCPv6.
> > >
> > > My question is, that which then is the more preferred option for the
> > > operators? Do they prefer extending RA so that the new information
> > > loaded on top of the RA messages gets known in the single shot when
> > > routers do neighbor discovery. Or do they prefer all the extra
> > > information to be learnt via DHCPv6? What are the pros and cons in
> > > each approach and when would people favor one over the other?
> > >
> > > I can see some advantages with the loading information to RA since
> > > then one is not dependent on the DHCPv6 server. However, the latter
> > > provides its own benefits.
> > >
> > > Regards,
> > > Ravi D.



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/