IPv6 RA vs DHCPv6 - The chosen one?

Masataka Ohta mohta at necom830.hpcl.titech.ac.jp
Fri Dec 23 15:00:16 CST 2011


Tomas Podermanski wrote:

> It sounds good, but according to  RFC 6434 ( IPv6 Node Requirements)
> SLAAC is required,

Not at all. SLAAC is required only if ND is supported, which
is optional.

Note that ND works poorly over link layers such as 802.11
where multicast is unreliable.

> but DHCPv6 is only optional.

DHCPv6 works over link layers with unreliable multicast
better than ND.

						Masataka Ohta


 So any manufacturer of
> operating systems or devices do not have to support DHCPv6.
> 
>>
>>> - 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)
>>
>> Administrators are deliberately providing conflicting information?
> 
> Not administrators, but attackers then could have more ways for harmful
> activity.
> 
>>
>>> - 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.
>>
>> This can be an argument for remove DHCPv6 completely....
> 
> Why not :-), but SLAAC can provide only a subset functionality comparing
> to DHCPv6. It is actually the reason why DHCPv6 was added into IPv6.
> Sothe  world without DHCPv6 had already been there.
> 
>>
>>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
>>>   process in the user space. Diagnostic and troubleshooting is more
>>> complicated.
>>
>> Some operating system do the SLAAC processing in user space. What is
>> the problem.
> 
> As I wrote. Troubleshooting is more difficult.
> 
>>
>>> - 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.
>>
>> I think it is matter of implementation.
> 
> Because DHCPv6 is depended on a information provided by SLAAC (RA
> messages) and DHCPv6 client have to wait. I hope that this dependency
> will disappear when the route option is added into DHCPv6. Nice thread
> on this topic is on
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg12183.html.
> 
>>
>>>
>>> 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.
>>
>>
>> But suitable in certain 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.
>>>   It also happens accidentally by "connection sharing" in Vista, Win7
>>>
>>> (https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf)
>>>
>>
>> Their is an RAguard RFC to prevent this.
>>
>>> - 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)
>>
>> For solution See propoosal of Fernando Gont about atomic ICMPv6 messages.
>>
>>> - 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.
>>
>>
>> What is missing?
> 
> It works quite well in DHCPv6 only environments (with M and A flag set).
> But not all devices supports DHCPv6, because DHCPv6 (as I said) is
> optional. So it is kind of catch XXII. It was specially problem when
> apple did not support DHCPv6. So XP and older apple devices can not have
> IPv6 connectivity in that environment. Fortunately things are going
> better. Another problem is with support in devices - I discussed it in
> one of the previous mail.
> 
>>
>>> - 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 :-( )
>>>
>>
>> Nobody? Every modern Windows OS.
> 
> I do not know whether Win 7 supports that option (in win 2000, XP there
> was an option to enable it), but I have never seen any network that uses
> it to handle router information. If there is any network that uses it I
> am eager to hear about it.
> 
>>
>>> 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.
>>
>> RA is just matter of swtiching on first hop router. You don't have to
>> configure anything.
>>
>>> - Frankly said, I have not found any significant benefit that SLAAC
>>> brings.
>>
>> Configuration of thousands of device without much overhead on server
>> side?
> 
> Agree, can be another advantage. But in fact it seems that networks with
> thousand devices will rather prefer dhcpv6 instead.
> 
> 
>>
>>>
>>> Unfortunately there is another issue with DUIDs in DHCPv6. But it is a
>>> little bit differed tale.
>>
>> It is a big issue.
> 
> Agree.
> 
>>
>>>
>>> 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
>>>
>>
>> It is written very badly! It has to be completed by results from:
>> http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf
>>
> 
> It is always matter of a personal opinion. There is always chance to
> comment, extend, discuss or write the new one document with own point of
> view.
> 
> 
> Tomas
> 
>>
>>
>>> [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
>>>
>>
>> Best Regards,
>>          Janos Mohacsi
>>
>>
>>>
>>> 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.
>>>>
>>>
>>>
>>>
> 
> 
> 




More information about the NANOG mailing list