IPv6 RA vs DHCPv6 - The chosen one?

Mohacsi Janos mohacsi at niif.hu
Fri Dec 23 06:07:29 UTC 2011




On Thu, 22 Dec 2011, Tomas Podermanski wrote:

> Hi,
>
> On 12/21/11 9:40 PM, Ray Soucy wrote:
>> I'm afraid you're about 10 years too late for this opinion to make
>> much difference. ;-)
>
> My opinion is that there is never too late to make thinks easier to
> implement and operate, specially in situation when things are
> unnecessary complicated. I do not hide that my opinion about SLAAC might
> look extreme but I have wrote my reasons for that. I do not expect that
> anything will be changed but the fact that I can see discussion about
> that topic approximately 2 or 3 times per month  (v6ops, dhcwg, ipv6,
> ...) and that shows that this problem is pain for many people/ISP. Have
> you ever seen similar discussion related to DHCP(v4). I have not,
> because there nothing to discuss about. It just works. It works in
> simple and logical way.
>
>>
>> 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.
>
> Well, then how many devices do you have in the network that uses IPv6?
> Do you have implemented first hop  security? What will you do when some
> user runs RA flood attack
> (http://samsclass.info/ipv6/proj/flood-router6a.htm). What will you do
> when some user runs NDP Table Exhaustion Attack
> (http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf) ? It is quite easy
> to bring IPv6 into a server subnet or a small office network. Providing
> stable and secure connectivity into the network with thousands of access
> port for the paying customers/users is really a serious issue today.


This is implementation issue. Has to be fixed. Or your have to think about 
port-security....

>
> I am very interested how the sites with similar number of access ports
> (users/customers) solve that problems.

If users are not seperated by interfaces you can see similar issues in 
IPv4 (spoofing attacks)....


> I can see that many ISPs prefer
> to solve that by blocking whole IPv6 traffic instead. But it does not
> look as a good strategy for deploying IPv6 :-(.
>
> Tomas
>
>>
>> On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski <tpoder at 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.
>>>
>>
>>
>
>
>




More information about the NANOG mailing list