IPv6 RA vs DHCPv6 - The chosen one?

Tomas Podermanski tpoder at cis.vutbr.cz
Fri Dec 23 13:51:58 CST 2011


Hi,

On 12/23/11 7:07 AM, Mohacsi Janos wrote:
>
> 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....

Port security does not help in that case (same as 802.1x). Port security
is a layer 2 feature so all layer 3 attacks can be still performed. That
prevents only against source MAC address spoofing. All other attacks
like DAD DOS, NDP Exhaustion, RA flooding etc. can be performed even
though the port security is implemented.

>
>>
>> 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)....

That is true, but we know solution for IPv4 (DHCP snooping, ARP
protection, source address validation) and there are access switches on
the market having that security features. Switches supporting such
features for IPv6 are usually much more expensive. And there is another
problem. Although you have money for that hardware it does not protect
you against malicious attacks.


Tomas

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