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 <tpo...@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/