Look at that, for once I agree with Owen on all points made. ;-) On Wed, Dec 21, 2011 at 6:18 PM, Owen DeLong <o...@delong.com> wrote: > > On Dec 21, 2011, at 11:16 AM, Tomas Podermanski 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 > > Except that there are many environments where that's not true. > >> - DHCPv6 should be extended by route options as proposed in >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > > I haven't read the particular draft, but, I do think dhcpv6 route options > should be added. > >> - DHCPv6 should be extended by layer 2 address to identify >> client's L2 address (something that we can see in RFC 6221) > > I'm neutral on this one. Once you get used to dealing with it, using DUIDs > isn't so bad. It does (at least potentially) allow you to identify the same > client > across a NIC replacement, which can be useful in some environments. > >> - DHCPv6 should be the common way to autoconfigure an address >> in a IPv6 environment > > DHCPv6 should be a common option for operators that want to use it, but > there is no reason to take SLAAC away from operators that are happy with > it. > >> >> 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. >> > > I agree that the requirement to run both is broken. I don't agree that this > means we should remove the option of using SLAAC in environments > where it makes sense. > >> - Clients have to support both SLAAC and DHCPv6 to be able to work in >> both environments > > So? > >> - 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) > > SLAAC and DHCPv6 can't really provide conflicting information unless > the router is misconfigured. Even if a host gets different answers for the > same prefixes from SLAAC and DHCP, it should be able to use both > host addresses. There's the question of source address selection, but, > the answer to that question at the IETF level should only be a matter > of what the default answer is. There are configuration options for setting > host source address selection priorities. > >> - 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. > > Solved for SLAAC -- SEND. > Allegedly, there is Secure DHCPv6 for DHCP, but, I haven't seen any > actual implementations yet. > >> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a >> process in the user space. Diagnostic and troubleshooting is more >> complicated. > > That seems like an argument for SLAAC, if anything. > >> - 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. > > While I agree with you that the standard is broken in this regard, there is at > least one OS vendor that already violates that rule anyway. >> >> 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. > > Yes, but, it does it in a much simpler way with a lot less overhead which > can be a benefit in some 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. > > This is what RA-Guard is for and it's quite simple to deploy. SEND makes > it even better, but is a bit more complicated. > >> It also happens accidentally by "connection sharing" in Vista, Win7 >> > > This is an argument for burying Windows, not an argument for burying > SLAAC. It's not like ICS in IPv4 didn't create rogue DHCP servers. If you > were to bury SLAAC, Micr0$0ft would simply switch to breaking DHCPv6 > instead of breaking SLAAC. > >> (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) > > Yes and no. RA Guard implementations are getting better at addressing > those issues. > >> - 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. > > Most sites don't need that level of security. I agree there should be a > way to disable SLAAC reliably at a site as a policy matter, but, frankly > the techniques you're talking about come in one of two flavors: > > 1. They dynamically enable the switch to accept packets from > a client, in which case, SLAAC based clients would be blocked > until they registered with DHCP anyway. > or > 2. They don't effectively block an attacker who cobbles his own > address even without SLAAC. > > In the former case, you get the security you want and force DHCP anyway, > so I don't see a problem. In the latter case, you only had the illusion of > security to begin with, so, SLAAC just makes it easy to disillusion you. > >> - 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 :-( ) > > Not a fair comparison. There were a number of additional issues with 1256 that > prevented it from gaining acceptance in IPv4. > >> >> Comparing to SLAAC, DHCPv6 have several advantages: >> - DHCPv6 is very similar to DHCP(v4) and many people are used to using it. > > That just makes it familiar, not necessarily better for all environments. > >> - DHCPv6 can potentially do much more - for example handle an information >> for PXE, options for IP phones, prefix delegation. > > True, but, that comes at a cost of complexity and overhead which may not be > desirable in all environments. > >> - 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. > > Which is not an issue in 99+% of environments. > >> - Frankly said, I have not found any significant benefit that SLAAC brings. > > Perhaps you have not, but, others have. I have seen environments where > SLAAC is much more useful than DHCPv6. I've seen environments where > DHCPv6 is needed. > >> >> 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. >> > > That's no really a fair characterization. Yes, DHCPv6 is more complex > than DHCPv4, but, not significantly so. > > In reality it can be summed up relatively quickly: > > 1. Choose link local address (fe80::EUI64) > 2. Send RS packet to all-routers multicast address > 3. Receive one or more RA packets. > a. if Packet contains prefix information: > i. Set timers, apply addresses to interfaces > (first regular packet can be sent at this point) > b. If packet has O bit set: > i. Send DHCPv6 request to DHCP server > ii. Get response > iii. Configure accordingly. > (If a was false (a and b are not mutually exclusive), > then > you can now send your first regular packet). > > Yes, there are a few corner cases not completely addressed above, > but, unless you're building the software to implement the standards, > they are mostly irrelevant. Even if you add them in (interactions between > the M, A, and O bits), you can still describe it in about a page, not > ten. > > Owen > >
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
