On Mon, 19 Dec 2011, 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.

Agree. Selection also influenced by the availability of the particular feature on a particular environments and habits of the operators. Best Regards, Janos Mohacsi

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.

Just to clear up a few misconceptions: ==== begin explanation current situation ==== Router advertisements are exactly what the name suggests, routers advertising their presence. The first function of router advertisements is to tell hosts where the routers are, so the hosts can install a default route. No RA means hosts won't send the router their packets. Of course routers that only talk to other routers don't need to send out RAs although nothing bad happens if they do so vendors may opt to send them out by default. All other functionality provided by RAs is optional. The first of those additional options the prefix option. This allows hosts to know which addresses are reachable on the local subnet so packets to those addresses don't have to go through a router but can be sent directly. Multiple prefix options may be present in an RA. Then there is the autonomous autoconfiguration (A) flag, which tells hosts that they should configure an address for themselves using the prefix in a prefix option. So only when at least one prefix option with the A flag set is present in an RA and the prefix length for that prefix is 64, stateless address autoconfiguration will be performed. Additional RA options can provide information such as a reduced MTU to be used on a subnet or a list of DNS server addresses. Unlike everything else mentioned so far, the latter is not very widely implemented. For DHCPv6, there are three variants: one that provides prefixes to routers, one that provides individual addresses (presumably) to hosts, and one that provides "additional information" such as DNS addresses. The first two require a stateful version of the DHCPv6 exchange to be performed, while the additional information can also be acquired using a lighter weight stateless exchange. Unless I'm very much mistaken, the DHCPv6 server can only perform the function the client has asked for. DHCPv6 is different from IPv4 DHCP in many ways, for instance the stateful/stateless distinction and the use of DUIDs rather than client identifiers. More importantly, DHCPv6 doesn't provide a prefix length or default gateway. This means that RAs are always necessary to provide this information (although some implementations may function without having explicitly learned the prefix length they should use). The trouble with having two mechanisms to do the same thing (stateless autoconfig and DHCPv6 address assignment) is how to decide which one to use. For this we have the M and O bits in RA. If M is set stateful DHCPv6 should be initiated for requesting an address and other information. If only the O bit is set stateless DHCPv6 should be initiated by hosts to request only other information. If both M and O are zero then no DHCPv6 should be initiated. Windows Vista and up and MacOS 10.7 support DHCPv6 address assignment. This means that as of six months ago, it became possible to assume DHCPv6 support in current versions of mainstream OSes. Before that, some of them lacked this capability so effectively, turning off stateless autoconfig and solely using DHCPv6 was impossible. ==== issues and way forward ==== Stateless autoconfig is a very nice system in un- or lightly managed environments, where it provides stable addresses to hosts without the need to have a central server keep track of those addresses using non-volatile storage. Unfortunately the DNS info isn't widely supported so at this point, at least stateless DHCPv6 is also needed to provide this information. In more tightly managed environments, stateless autoconfig has the downside that the hosts choose their addresses autonomously, so the information about which host has which address at which point in time isn't easily available to be logged. We have now reached the point were it's possible to turn off stateless autoconfig and use DHCPv6 address assignment instead to accommodate such logging. Of course none of this is bullet proof. Like with IPv4, there is some assumption that people on a shared subnet play nice. This may be an incorrect assumption. In that case, significant filtering and additional logging of L2 parameters may be necessary. Such features are not as widely available for IPv6 as for IPv4. There are some situations where it can be useful to give different hosts different information using DHCPv6, including information that is now provided using RAs, which are of course the same from the viewpoint of every host on a given subnet. In addition to that, some people just don't like RAs and want to run their network without them. These two groups want default gateway information to be added to DHCPv6 to accommodate those needs/wants. However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence. With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the problems that occur with IPv4 DHCP and the additional issues that would be introduced in IPv6 by adding this feature. Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality? I would like to make the following suggestion: rather than having DHCPv6 impose a default gateway with all the issues that that creates, why not implement a router preference option. This way, DHCPv6 can be used to select the "correct" default gateway from the list of possible default gateways that announce their presence through RAs. This doesn't have the first issue, because dead routers can't be selected. The second issue is still there but the deployment model is much better because partial deployment provides partial benefits, On 21 Dec 2011, at 3:44 , Don Gould wrote:

I would like to see a simple presentation of the different ways of setting up a small network at the edge with the features, benefits and issues, of each method.

With stateless autoconfig you have to configure very little. I don't think consumer home gateways even let you turn it off or mess with the M and O bits. So if you use that equipment, just go with the flow. Such equipment probably also has a stateless DHCPv6 server on board for DNS info. But if you run dual stack you can do DNS over IPv4 so it's not worth the time to mess with if that function isn't there for IPv6. If you have more advanced equipment you can have your router send out RAs with the M bit set and the A bit cleared and thus only use DHCPv6 for address configuration. However, that's not compatible with older hosts. Having the A bit set and thus have both types of addresses doesn't seem like a desirable configuration to me. Obviously with the M bit set you need to run a DHCPv6 server. Cisco has a good implementation but if you want control over IPv6 addressing it's probably easier to run a centralized DHCPv6 server that you can configure more easily than a bunch or routers and make the routers DHCPv6 relays. Be aware that if the DHCPv6 server is down and hosts don't have IPv6 addresses some OSes may still try to connect over IPv6 because they still have a default gateway. (I tested this way too long ago to remember which OSes.)

What I don't want is to end up with a bad name because I set up stuff 'the right way' but in such a way that the next tech the customer calls gets annoyed that what I've done is so complex that it will cost the customer $$$$$ to fix a fault.

I'm not saying that DHCPv6 is immature or doesn't work, but stateless autoconfig has been in active use for 15 years so it's not going to give you any nasty surprises. Yes, you can have problems with rogue RAs, but by definition those aren't the ones YOU are sending so that problem is orthogonal to the DHCPv6/statless autoconfig decision. You can't go out and disable stateless autoconfig on all the hosts in your network. (Ok, maybe you can but then you wouldn't be asking advice on NANOG.) Iljitsch

2011/12/28 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:

Granted that the notion of default router of IPv4 is no better than that of IPv6.

Please present a reasonable alternative. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

Iljitsch van Beijnum wrote:

...

...

Granted that the notion of default router of IPv4 is no better than that of IPv6.

...

Please present a reasonable alternative.

Obviously reducing down the entire DFZ to a single default route is a bad case of premature optimization,

Stop confusing "default router" and "default route". Masataka Ohta

2011/12/28 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:

According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities.

See the paper by Saltzer et. al.

So your entire argument is based on an academic paper from 1981 and that host systems should participate in IGP. We tried that. It didn't scale well. The Internet today is very different than the Internet in 1981. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Dec 29, 2011, at 2:27 AM, Vitkovsky, Adam wrote:

...

... host systems should participate in IGP

...

We tried that.

...

It didn't scale well.

...

The Internet today is very different than the Internet in 1981.

-did you? I thought CLNS with plethora of ip addresses compared to ipv4 was buried before it could be widely deployed, I was not around back than but would like to know why ES-IS did not scale well when integrated IS-IS is still used primarily for great scalability

??? CLNS carried NSAPs, not IP addresses. ES-IS was the protocol between hosts and routers, very much akin to ARP. IS-IS was the IGP used for CLNS. Yes, it's the same one that we use today for IP. Even in the ISO model, hosts did not participate in IS-IS. There was no particular scalability problem with ES-IS, other than the mcast burden that it imposed on the link layer. This is not radically different than the burden that ARP broadcasts require. Limit your broadcast domains. Tony

Valdis.Kletnieks@vt.edu wrote:

...

According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities.

That's only for hosts that are actively trying to communicate on more than one interface at a time,

Note that the end to end argument has the following statement I omitted to quote: (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) That is, there are incomplete solutions by intermediate systems which sometimes work.

and even then quite often the *actual* right answer isn't "run an IGP", it's "insert static routes for the subnets you need to reach via the other interface"(*).

With manual configuration, you can do anything. But, aren't we talking about autoconfiguration?

If it's a laptop that has both a wireless and a wired connection active, usually a simple "prefer wired" or "prefer wireless" is sufficient.

Usually? Can you see the word "complete" in the end to end argument?

Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default?

Sanity check with Windows? Are you sure?

If not, why does the net continue to function just fine without it?

It is often incomplete and incorrect unnecessarily requiring manual reconfigurations.

(*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static routes describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change.

If you are saying SLAAC is not enough in your case with complicated manual management, I don't think I have to argue against you on how to simplify it. Masataka Ohta

Valdis.Kletnieks@vt.edu wrote:

...

...

Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled by default?

...

Sanity check with Windows? Are you sure?

It's a quick sanity check to this statment:

...

...

According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities.

If it's the "only possible spolution", how come 99.8% of the end nodes do just fine without it? Oh yeah..

Because that's the Microsoft quality. PERIOD. Masataka Ohta

* Valdis Kletnieks:

...

...

According to the end to end argument, the only possible solution to the problem, with no complete or correct alternatives, is to let hosts directly participate in IGP activities.

If it's the "only possible spolution", how come 99.8% of the end nodes do just fine without it? Oh yeah..

Because there's a CPE which acts as a mediator, or the host uses some dial-up-type protocol which takes care of the IGP interaction. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

Valdis.Kletnieks@vt.edu wrote:

So what percent of the *CPE* in the average cable-internet or DSL farm *actually uses* an IGP,

As I wrote:

If a host receives RAs only from a router, the host can do nothing other than installing the router as the default router. If not, however, the host must directly be involved in IGP activities, or, the following end to end argument is applicable:

IGP snooping is not necessary if the host have only one next hop router. Masataka Ohta

Valdis.Kletnieks@vt.edu wrote:

...

IGP snooping is not necessary if the host have only one next hop router.

You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :)

IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly. Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument. Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router. Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated. Masataka Ohta PS Note that the paper was written in 1984, where as RFC791 was written in 1981.

Steven Bellovin wrote:

...

Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router.

VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days.

How much, do you think, more reliability required to the Internet today than in 1984?

There was a lot less understanding of the difference between hosts and routers in 1984 than there is today -- if nothing else, note how 4.2BSD and 4.3BSD considered all multihomed machines to be routers.

Unlike routers, multihomed machines without forwarding should listen IGP but must not advertise routes, which was well understood very well even at that time. It is the right thing to do, as is proven by the 99.8% argument that Microsoft don't do so. :-) Masataka Ohta

VRRP is still useful, and for those who find it useful it has been extended to IPv6 [RFC5798]. Vendors, such as Cisco, have already begun shipping functional implementations as well it would seem. There are certainly pieces of IPv6 that will need refinement (and we will likely see that happen over time, after it is dominant). Mobility and IPsec, for example, were touted as big benefits of IPv6, but they didn't end up being that important (or useful) in their current state. The ability to have multiple prefixes from different routers, and a failover mechanism was really a pre-NAT and pre-VRRP idea. It's not the common deployment that it was envisioned to be, and our expectations of how fast these things happen has become a lot higher. Still, minor extensions could be made to these standard to achieve a lot of the desired behavior, so I haven't given up on it all completely. It's hard to predict the future, and it's been over a decade since the design for IPv6 was solidified and began to be implemented. Let's not forget that what we call "Ethernet" today is very different from Bob Metcalfe's Ethernet. On Fri, Dec 30, 2011 at 11:47 AM, Kevin Loch <kloch@kl.net> wrote:

Steven Bellovin wrote:

...

VRRP?  The Router Discovery Protocol (RFC 1256).  But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days.

VRRP is an absolutely essential protocol in today's Internet.  We use it on every non-bgp customer port.  Routers still have routing and performance issues, hardware failures and routine software upgrades. The layer2 infrastructure between the routers and the customer is also susceptible to various hardware/software/maintenance problems and fiber cuts and VRRP can help work around some of those.  A nice side benefit is the virtual mac addresses that allow for migration to new routers without the mac address of the default gateway changing.

One key advantage of VRRP over RA's is that you can have multiple instances on the same layer2 network (vlan) with different functions.

It is very common to have different "routers" (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments.  It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations.

- Kevin

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said:

IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly.

Which is sufficient for 99.8% of hosts out there.

Beyond that, if there are multiple routers, having a default router and relying

Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all..

On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said:

Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work. Just because it is 0.2% today doesn't mean that it will be 0.2% in the future. As home users get more and more dependent on the internet working having diverse, independent network connectivity will become more and more important.

Agreed. But did you plug the cable router and the DSL router both into your PC, or into yet another box that needs routing smarts and then your PC just needs to know "talk to the smart box"? (Hint - if the cable router and the DSL router are both plugged into your PC, how do all the *other* devices in your house reach the internet? :)

On 12/29/2011 8:12 PM, Mark Andrews wrote:

Well I'd like to be able to plug in the cable router and the DSL router at home and have it all just work.

Well, that's not too far removed from the plugged-in laptop with the wireless still active. Toss-up which one wins default route. What would you "like" it to do? BGP feeds from both (likely not happening)? Defaults from both? Or you just want active/passive failover? The real-world case for host routing (IMHO) is a server with a public interface, an administrative interface, and possibly a third path for data backups (maybe four if it's VMware/VMotion too). Unless the non-public interfaces are flat subnets, you need some statics (today). It can be a challenge to get SysAdmins in a co-operative mindset to route that correctly (and repetitively if you have a server farm). I would be walking the fence on the virtues of automatic route discovery in that case versus the security of static routes/configurations. But home use from a host perspective? Jeff

Valdis.Kletnieks@vt.edu wrote:

...

Beyond that, if there are multiple routers, having a default router and relying

Yes yes we know, and we've understood this for a quarter century or so. My disagreement is that even though 99.8% of machines *don't* have multiple routers, you seem to be pedantically insisting that some sort of IGP is mandatory for *all* end hosts, even though only 0.2% or so will actually see any benefit at all..

Not. Though hosts should implement some IGPs, the default can be to just depend on default routers supplied from DHCP. A better default could be that IGP will be automatically invoked if DHCP does not supply a default router. If there are multiple IGPs are implemented, snooping IGPs' advertisement to know which is the locally available IGP may also be a good idea. My point w.r.t. multiple next hop routers is that RA supplied information is not good enough, which means DHCP is no worse than RA even if there are multiple next hop routers. Masataka Ohta

OK, this is getting ridiculous. Let's assume that we have a model where host systems receive the global routing table from service providers.  The stated reason for this is so that they could make their own routing decisions when multi-homed environment.  Presumably with each ISP connected to a L2 device; let's say an Ethernet Switch. So now we have ISP A, B, and let's even add C.  Each are providing all available routes in the global table, and path information, allowing the host to make intelligent routing decisions. Unfortunately, for bi-directional communication, the prefix assigned to the customer must be provider independent.  It's a residential service so maybe they have a single 64-bit prefix.  So we now need ISP A, B, and C to be announcing that prefix. Congratulations, you have just created a model where every customer would have their own entry in the global table (since route summarization and aggregation is now impossible), one that is exponentially greater than the production IP global table today. But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...). We could, of course, only provide customers with the global table, and have each ISP give hosts a different prefix.  This would allow for the selection of the best path by the host, but once that communication is established it would be locked into that path.  The remote host would have no knowledge of other available prefixes (even if there is a path change, and a different path becomes favorable).  To get around this we could develop another message that allows a host to announce alternative addresses to other hosts; which means systems now also need to keep a table of alternate peer addresses, and have the ability to quickly detect changes in path availability and quality. The result is still a very large amount of overhead.  You will still experience significant change propagation delay (slower than change propagation under the current model as it would be more complex, involve exponentially more peers, paths, etc, and be performed on commodity hardware). This all would be significantly more complex than IPv6 (which is already claimed, by the proponents of the beloved end-to-end model, to be too complex and have too much overhead), it would introduce even more delay (another complaint) than IPv6 due to that complexity. Limitations aside.  We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor.  Getting buy-in for such a fundamental shift in how the Internet is build would be almost impossible at this point.  To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it (when everything they want works "just fine" on the "old" network). I honestly can't believe we're even having this discussion.  It's really bonkers. 2011/12/29 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:

Valdis.Kletnieks@vt.edu wrote:

...

...

IGP snooping is not necessary if the host have only one next hop router.

...

You don't need an IGP either at that point, no matter what some paper from years ago tries to assert. :)

IGP is the way for routers advertise their existence, though, in this simplest case, an incomplete proxy of relying on a default router works correctly.

Beyond that, if there are multiple routers, having a default router and relying on the default router for forwarding to other routers and/or supplying ICMP redirects stops working when the default router, the single point of failure, goes down, which is the incompleteness and/or incorrectness predicted by the paper of the end to end argument.

Considering that the reason to have multiple routers should be for redundancy, there is no point to use one of them as the default router.

Developing more complicated IGP proxy makes the incompleteness and the incorrectness not disappear but more complicated.

                                       Masataka Ohta

PS

Note that the paper was written in 1984, where as RFC791 was written in 1981.

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

Well, it seems now you've also added the requirement that we also dramatically re-write all software that makes use of networking. Seemingly for the sake of never admitting that you can be wrong. You seem to think that the OSI model is this nice and clean model that cleanly separates everything and that you can just freely replace chunks of it. That was the idea; but in practice, there is a lot more grey area, and dependencies. Again, it's like you live in a theoretical world where physical limitations and operational realities don't exist. Honestly. Here is a thought: Go off and write up the RFCs to make this all work, and come back when you have an model implementation we can all look at. I think that would be a win-win for everyone. I normally don't try to dismiss people completely, but you're exhausting. You never directly respond to anything except with a one line assertion like "not at all," or by changing the parameters of the argument to a model that doesn't exist. I could do that too:

It can be assumed that default free routing table is small.

Yes, I agree completely. The default free routing table must have one route: a default route. See how frustrating that is? On Fri, Dec 30, 2011 at 4:49 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

Ray Soucy wrote:

...

But that is only the case if you let customers have a PI prefix (which I think is really required in a purist end-to-end model, but for the sake of argument...).

Multihoming by routing, by the intermediate systems, is against the end to end principle, which is why it does not scale.

...

The remote host would have no knowledge of other available prefixes

As IP layer is connectionless, let transport or application layer carry the information on the prefixes to try to keep connections.

...

(even if there is a path

change, and a different path becomes favorable).

The remote host can use IGP metric to know the initial best candidate and subsequent path changes.

It can be assumed that default free routing table is small.

In addition, the remote host may also use transport/application layer timeout to try other prefixes.

...

The result is still a very large amount of overhead. You will still experience significant change propagation delay (slower than change propagation under the current model

Not at all.

Transport/application timeout is no different.

Route propagation is no slower. Instead, smaller default free routing table means more rapid convergence.

...

This all would be significantly more complex than IPv6

It was IPv6 which was expected to support multiple addresses to suppress routing table growth. The result is a complex protocol with halfhearted support for multiple addresses.

...

We now know that it takes well over a decade for people to move to a protocol, even when it is almost operationally identical to its predecessor.

Unlike IPv4, IPv6 is poorly operational and still needs protocol modifications,

For example, multicast PMTUD causes ICMP implosion, which means rational operators filter ICMP packet too big often including those against unicast packets, which means PMTUD won't work.

Yes, fixing it requires more than a decade.

Then, it may be a good idea to obsolete SLAAC, which means IPv6 address can be only 8B long. You know, remembering 16B addresses is divine, which is an operational head ache.

...

To be frank, you would have to build a completely new and parallel network and hope you could somehow convince people to adopt it

Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6.

                                               Masataka Ohta

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

(*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static routes describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the liveware taking a meeting to discuss deployment of the change. Well the only reason why you still have a good night sleep with the primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp All of this just because the end station just can't route around a failed link

Ray Soucy wrote:

Sounds like we have one group saying that IPv6 is too complicated and that all the "overhead" of IPv6 had resulted in slow adoption.

Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP.

Not at all. It is wrong that ND is so complicated that it even act as IGP proxy. To simplify the situation, let separate address resolution and IGP, which is the conventional wisdom of IPv4. ND became too complicated unnecessarily trying to offer incomplete and incorrect assistance from routers to nodes, even though the nodes should take care of themselves using information provided through IGP. Having a default router is fine if there is only one router. However, with multiple routers, default routers and ICMP redirects are nothing more than an incomplete proxy of IGP.

There is a lot of academic and theoretical argument being made here, but not so much on the practical application side.

Though NANOG may not be a good place to discuss about practical application side, it may be helpful to mention IPv6 is totally broken for the side. That is, as the length of IPv6 extension headers is unlimited and there are extension headers inserted automatically without application control, there is no guaranteed minimal payload size left for the transport layer. As PMTUD of IPv6 is proven to be inoperational: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf we must assume MTU of 1280B. But, as IPv6 extension headers can be as lengthy as 1000B or 2000B, no applications are guaranteed to work over IPv6. Masataka Ohta

Multihoming with multiple addresses works at transport/application layer over existing IPv4 and IPv6.

May be there is some light with Multipath TCP: http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf http://datatracker.ietf.org/wg/mptcp/charter/ If you can live without UDP and other issues discussed in this bizarre discussion... -Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 esteve@cpqd.com.br www.cpqd.com.br

On Dec 29, 2011 6:38 AM, "Ray Soucy" <rps@maine.edu> wrote:

Sounds like we have one group saying that IPv6 is too complicated and that all the "overhead" of IPv6 had resulted in slow adoption.

Meanwhile we have others saying it doesn't have enough functionality, and should also include IGP.

Seems like IPv6 as it is has struck a balance somewhere in the middle. It's never going to be the perfect solution for every situation.

There is a lot of academic and theoretical argument being made here, but not so much on the practical application side. I think this discussion went down hill when we started seeing people point to "evidence" that IPv6 is "broken" being special use cases that IPv4 can't even handle properly.

Yep. How about you guys take this nonsense off list. The first post was well intentioned, the rest has been FUD and sour grapes. Next topic, ethernet is too chaotic and inefficient to deploy and support mission critical applications in LAN or WAN or data center. Cb.

On Thu, Dec 29, 2011 at 6:06 AM, Vitkovsky, Adam <avitkovsky@emea.att.com> wrote:

...

(*) If you think I'm going to run an IGP on some of my file servers when "default route to the world out the public 1G interface, and 5 static

...

describing the private 10G network" is actually the *desired* semantic because if anybody re-engineers the 10G net enough to make me change the routes, I have *other* things to change as well, like iptables entries and /etc/exports and so on. I don't *want* an IGP changing that stuff around wiithout the

...

taking a meeting to discuss deployment of the change.

Well the only reason why you still have a good night sleep with the

routes liveware primary path in flames and all those in stone carved static routes is that your server is connected via ether channel to a couple of boxes with dual RPs and redundant power supplies running VSS or vPC and routers running vrrp

...

All of this just because the end station just can't route around a failed link

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On 12/28/2011 03:13, Iljitsch van Beijnum wrote:

However, this has two issues. First, with RAs there are no risks that incorrect default information is propagated because the default gateway itself broadcasts its presence.

Unless you have a malicious user on the network in which case all traffic immediately switches to the malicious user's gateway. This is in contrast to DHCP where the similar attack only affects new/renewing hosts. I'm aware that SEND is trying to solve this problem, but it's not yet deployed.

With DHCP, it is possible to inject incorrect information. In my opinion, people are underestimating the problems that occur with IPv4 DHCP and the additional issues that would be introduced in IPv6 by adding this feature.

I think that people already know of and have solutions for the security issues that exist for DHCP today.

Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality?

10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the history, see https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html) The good news is that it's not too late to fix DHCPv6. We're at a watershed moment where it's just possible that we'll get the ability to assign a default gateway added to it due to, for lack of a better term, market forces. This would be a major paradigm shift. As you point out the development lead time on stuff like that is rather painful, however if we took advantage of the camel's nose under the tent and included "everything relevant that DHCPv4 can do" in that update, we'd be in a pretty good condition in a year or so. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton <dougb@dougbarton.us> wrote:

On 12/28/2011 03:13, Iljitsch van Beijnum wrote:

...

Second, publishing specifications, implementing them and waiting for users to adopt them takes a very, very long time. For DHCPv6 support, the time from first publication (2003) until wide availability (2011) has been 8 years. Are we ready to live in a half-baked world for another half a decade or more just so we can add this feature, while layer 2 filtering and VLANs more easily support similar functionality?

10-12 years ago I attempted to make 2 points to the IPv6 literati. First that IPv6 would not be widely adopted in the enterprise until it had full DHCP parity with v4. Second that the easiest way to do that would

+1000

be to declare all existing DHCPv4 options that are relevant to IPv6 as existing in DHCPv6 by fiat, and to prevent new v6-only options from using option numbers that already exist for v4 (and vice versa). I was laughed out of the room on both counts. (If anyone wants more of the

similarly folks keep laughing (or at least harumphing loudly) when enterprise folk say: "Hey, I use dhcp today for a large number of things, I can't NOT use it going forward, support the features in v4 dhcp that I use in your new v6 thingy." anyway, it seems to be getting slightly better, bolting more crud on ND so you can continue to say: "Yea, but you SHOULD use ...." is wasted breath. -chris

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.

On Wed, Dec 21, 2011 at 10:40 AM, Ray Soucy <rps@maine.edu> wrote:

On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

...

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

I'm afraid you're about 10 years too late for this opinion to make much difference. ;-)

I won't go so far as to say SLAAC should be removed from the IPv6 spec but it's never too late to deprecate a protocol that doesn't pan out. I'm with Owen: On Tue, Dec 20, 2011 at 4:58 AM, Owen DeLong <owen@delong.com> wrote:

Currently, most significant environments have to cobble together a complete solution from remnants of SLAAC and DHCP. This is far from ideal. Far better for organizations to look at 2 complete solutions and pick the solution that works best for them in their environment.

Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On 12/21/11 12:40, Ray Soucy wrote:

...

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.

And that's a very good reason not to deprecate SLAAC. Tomas may prefer DHCPv6, and he may provide reasons others may prefer DHCPv6. But he hasn't provided justification for deprecating SLAAC. I am not against SLAAC. I am against the way how DHCPv6 & SLAAC works today. Today, SLAAC can not live without DHCPv6 and DHCPv6 can not live without SLAAC (RA). Second reason is that we have two

Hi, On 12/22/11 12:04 AM, Michael Sinatra wrote: protocols/techniques to do just the same thing. I prefer to have just ONE common autoconfiguration method as we have it in IPv4. Because DHCPv6 is more complex and SLAAC can provide only subset of DHCP functionality I personaly prefer DHCPv6.

Many of us have been working with IPv6 for years and have found SLAAC to be quite useful. The biggest benefit it provides, which Tomas did not acknowledge, is the ability to autoconfigure hosts without running a central server. That said, I have also found DHCPv6 to be quite useful.

We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before). DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html).

I also agree with Owen: Provide two complete solutions, and let operators choose based on their needs. That implies fixing DHCPv6 so I don't have to go in and disable the autonomous flag on my routers and run RAs just to get a default route. But it also implies not deprecating either SLAAC or DHCPv6.

Although we have differed opinion whether we need one or two autoconfiguration protocols, I totally agree that "fixing" DHCPv6 is a really necessary step and It should have been done many years ago. Btw. not all people agree that DHCPv6 should be fixed in that way. There was a discussion in 2009 in dhcwg (thread available on: http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html). The current draft (draft-ietf-mif-dhcpv6-route-option-03) is the 3rd attempt to do it. In past, there were another two drafts trying to introduce route information into DHCPv6: draft-droms-dhc-dhcpv6-default-router-00, expired September 2009 draft-dec-dhcpv6-route-option-05, expired April 2011 So I hope that this time we will have more luck :-) Tomas

On 12/22/11 12:09, Tomas Podermanski wrote:

We have to use SLAAC as well because we do not have other choice. Not all operating systems supports DHCPv6 today. But we are not happy about it (problems with privacy extensions, security as I mentioned before).

DHCPv6 do not have to be run on a central server. DHCPv6 can be implemented as a part of a router as well. It is common for DHCP(v4) an implementations for DHCPv6 are available today (eg. cisco http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-dhcp.html).

But one of the advantages you cite for DHCPv6 was the ability for the central DHCPv6 service to make decisions about how to configure clients. Most US EDUs that I am familiar with do not wish to go out and touch every router when they want to make site-wide configuration changes. Even if you run DHCP[v6] on a router (and yes, I have done it), you're still running a separate service beyond routing and it still increases the complexity of your configuration. I agree with Bill: We're not hurting for choices in IPv4. What we don't need to do is reduce choice in IPv6 by deprecating SLAAC--a move which would also reduce the credibility of IPv6 itself. There was at least some criticism of the community for deprecating NAT-PT. By pushing SLAAC for many years, then deprecating it (as opposed to simply adding alternatives), we will be telling would be adopters "we really can't make up our minds as to how you're supposed to use this stuff." That would only stall IPv6 adoption, even if the ultimate result of keeping both protocols will be that a vast majority of folks use DHCPv6. michael

On Thu, 22 Dec 2011 21:04:42 +0100, Tomas Podermanski said:

Well, then how many devices do you have in the network that uses IPv6?

1,300+ wireless access points, 1,100+ switches, 30k+ users, around 55% doing at least some IPv6 traffic (mostly when they hit Google).

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

"First actual case of a bug being found" -- Lt Cmdr Grace Hopper I've asked around, and although everybody understands it's an issue, the number of people actually *seeing* one of these attacks is... Bueller? Bueller?

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

Hi, On 12/23/11 9:09 PM, Ray Soucy wrote:

On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

...

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. Yes, and over time similar Layer-2 security features will become available for IPv6 by default. The more people who work to deploy IPv6 and express these concerns to vendors, the more likely vendors are to give them priority.

RA Guard is one such example where vendors have responded to community concerns and have begun to implement the functionality.

All these problems exist for IPv4, and I would go as far as to say that the vast majority of networks don't even implement things like ARP inpsection, DHCP snooping, IP source verification, UUFB, etc. They're things that dramatically increase network stability, and things that are used by those of us who run larger networks, but they are certainly not typical by any measure.

I agree with you, that is not typical for many networks. For example in our network we have enabled some of that features (not all) only in some subnets. Unfortunately those subnets connects over 70% of our users (6500). Is also great that many produces are going to take that issues seriously. Actually we have quite big concerns with decision if: 1. to buy cheaper access switches (like HP 42xx) that have security features for IPv4 but will never have support for IPv6. The hardware does not support IPv6 at all. In that case we will be able to replace access switches in quite short time - one year. And in next five years we will be buy a brand new generation of switches that will have all those problems solved (I hope). or 2. to buy much more expensive switches (like HP 54xx) that supports some basic security features for IPv6 and there is some a probability that other features will be implemented. So we will be able to use ra-guard and ACLs immediately. In that case there is still a chance that some features will not be implemented due to hardware limits. So we will have to buy new generation of switches again in five years. Tomas

On Fri, 23 Dec 2011, Tomas Podermanski wrote:

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.

If you can limit number of ARP/NDP entries per interfaces and you complement RAGuard and DHCPv4 snooping your are done. With "extended port security" such a features are comming... Best Regards, Janos Mohacsi

On Fri, 23 Dec 2011, Jeff Wheeler wrote:

On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos <mohacsi@niif.hu> wrote:

...

If you can limit number of ARP/NDP entries per interfaces and you complement RAGuard and DHCPv4 snooping your are done.

That depends on how ARP/ND gleaning works on the box. In short, Cisco already has a knob to limit the number of ND entries per interface on some of their kit, and it is not a solution, only a damage mitigation measure. http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf

The solution is that you monitor your device: if limits reached then you get notified and you can resolve the problem. Best Regards, Janos Mohacsi

-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator  /  Innovative Network Concepts

On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

Well, then how many devices do you have in the network that uses IPv6?

Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it. I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional R&E network). At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above). We participate in Google's trusted IPv6 program, so Google announces AAAA's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing AAAA's yet. We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/s... for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html

Do you have implemented first hop  security? What will you do when some user runs RA flood attack

You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). For neighbor table exhaustion, I've written a set of scripts that I can use in a lab environment to perform the attacks against the platforms we use, and test how they fair. There is a pretty wide range of results. Most of the larger platforms that are the ones we would be concerned about actually hit CPU limitations before neighbor table exhaustion is accomplished, mainly because the neighbor discovery process doesn't appear to be implemented in hardware. It doesn't take much to pull off the attack either; a handful of residential connections would do the trick. This isn't an IPv6 problem so much as a vendor implementation problem, though. Like most DoS and DDoS attack vectors, vendors will need to take extra steps to harden equipment against these attack vectors as they become aware of them. Until vendors catch up (and that includes us having the funds to upgrade to new platforms that do a better job with it), we have opt'd to make use of longer prefixes than 64-bit (in fact we mirror the capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in IPv6). A good description of this is available in some slides by Jeff Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf While your mileage may vary with longer prefixes, with the same attacks we saw the impact on CPU usage to be less than half when longer prefixes were used, and that's pretty good. You can also keep external attacks from reaching internal routers if you don't do route summarization internally, which sees considerable gains, as more of that logic appears to be in hardware. On the deployment side, we make use of DHCPv6 and RA with M and O set, and A unset. Our DHCPv6 servers only hand out IPv6 addresses to registered systems that are in the database and have been flagged as OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host basis, rather than a network-wide basis (as you would need to do with SLAAC). This does have the consequence of excluding hosts from IPv6, piticurally Windows XP systems, and pre-Lion OS X systems. But since IPv6 isn't "required" yet (there is really no IPv6-only content yet), we take the position that we only provide IPv6 to systems that support DHCPv6 and have an adequate IPv6 host-level firewall as part of their IPv6 implementation. This makes it easy to exclude hosts that might be problematic to deliver IPv6 to, due to lack of security, or even bugs (RHEL 3 can kernel panic when connected to over IPv6, for example). It also keeps the pressure on to upgrade legacy systems. Wireless is an area we would really like to move forward with IPv6, but we still have concerns that need to be addressed before that can happen. In a Cisco environment, like ours, for example. IPv6 requires Ethernet Mode Multicast to be enabled on the WLAN. Unfortunately it doesn't provide tools to filter which multicast traffic is permitted, and at the scale we deploy wireless it just isn't practical. We might be able to re-architect wireless to better handle this, but that's a future project. I think the big picture here is that IPv6 isn't as "easy" as it should be for large deployments just yet, but that's the case with any new technology. The more people who begin to work through it, the more we will identify problems, and work to resolve them. The almost religious debate of RA vs DHCPv6 gets a lot of attention, but there are much more important issues in my view; like making sure our routers and switches provide the functionality we want them to, and this is an argument that takes away from that. Over 10 years of implementation for IPv6, both RA and DHCPv6 work nicely, well enough that they are reasonably functional and flexible. We can look to enhance them, but that will take another 10 years to wait for implementations to be updated (and then users to upgrade). I would much rather focus the energy of this list to things like neighbor table exhaustion, RA guard, etc. and getting vendors to understand the importance of addressing these concerns. It's a lot easier to upgrade one router than a thousand hosts. Furthermore, DHCPv6 "Other Only" implementations are trivial if you want to use SLAAC for DNS, and most routers already support it. DHCPv6 may not be the only option for DNS in a few years. Things from the ZEROCONF WG like multicast DNS for example (or even an anycast DNS standard) will more than likely come into play, allowing SLAAC without DNS information or DHCPv6 to function just fine on its own. IPv6 is also designed to last quite a while. We might not always be using DNS, something better might come a long, and keeping that out of RA would be my personal preference. But options are always good, and I have no problem adding DNS to RA and route information to DHCPv6; just understand that even if we do get these implemented, you won't be able to use them as a standard for another 5 years at minimum; it would be nice to see IPv6 adoption not be held up over re-designing something that already gets the job done. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Tue, 27 Dec 2011 22:23:48 +0100, Tomas Podermanski said:

I agree with you. Deploying IPv6 is really not easy and not cheep as some IPv6 enthusiasts claims.

It's probably as easy and as cheap as IPv4 is. You've just forgotten how expensive and painful it was to solve all the exact same problems on the IPv4 side when you built your IPv4 infrastructure all those years ago. Meanwhile, the IPv6 enthusasts have forgotten how hard it was to deploy their IPv6 infrastructure all those years ago.

On 12/27/11 10:53 PM, Ray Soucy wrote:

Much like with IPv4, we capture the DUID at the time of registration and store it in the database. We make use of a web-based registration system that allows users to register computers for network access with a valid ID (that piece is still in development, though).

There is still work to be done on DHCPd for IPv6. Along with the DUID we need support for specifying and logging IAID (especially with fixed-address statements).

My initial reaction to DUID was one of complete hatred at first, but like most things IPv6, having worked with it a while longer, it's actually quite useful. We just need tools and knowledge to catch up. So far the biggest "problem" was people creating system images poorly and not deleting DUID, leading to duplicates. Our systems people know better these days and it's a non-issue, though.

On a side note, you can build a DHCPd config these days that uses the MAC address as an identifier, and if a DUID is based on that MAC using one of the two methods that do, then it will make the association. It's not ideal, but it is a quick fix to the "we only have a list of MAC addresses" problem.

It was my initial idea to workaround DUID issue. But MAC address in DUID is not necessary the address of a communicating interface. It can be derived from wireless interface when a node is connected via an Ethernet adapter. So I had to leave that idea very soon. In addition, RFC refuses DUID to be treated in that way :-). There is an RFC 6221 that solves that problem, however I haven't seen any implementation yet. Tomas

I've actually been working to start an open source (free software) group dedicated to the development of IPv6 infrastructure systems based on Linux. Hopefully this summer I'll be at a point where we have some useful technology to provide. You can either talk about the challenges of IPv6 deployment, or actively try to find solutions to them for everyone is the general idea.

On Tue, Dec 27, 2011 at 4:23 PM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

...

Hi,

...

On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

...

Well, then how many devices do you have in the network that uses IPv6? Good question, and I applaud you for wanting to verify that people talking about IPv6 have legitimate experience deploying it.

I dug into the database I log all IPv6 traffic into. We have 8,509 active hosts using IPv6, that's in comparison to 35,229 on the IPv4 side, so about 24% (mind you, this is only the LAN networks we manage, we provide IPv6 transit to other entities as the regional R&E network).

At this point over 95% of IPv4 LAN networks have IPv6 available, wireless is still a challenge (which is a big part of the difference between the host numbers you see above).

We participate in Google's trusted IPv6 program, so Google announces AAAA's to us for nearly all their services, so a significant amount of bandwidth is actually over IPv6. I would say that Google does make up the majority of IPv6 traffic though; there isn't much else out there announcing AAAA's yet.

We have always taken the approach that IPv6 isn't ready to be deployed if you can't do so while maintaining the same standards you have for IPv4 in the areas of manageability, security, availability, and stability. And we literally spent a few years modifying internal systems (and implementing new ones) to support IPv6 before we started making it available. See http://reports.informationweek.com/abstract/19/2233/Network-Infrastructure/s... for the case I've been making the last few years, or listen to me (and others) talking a little about it on Cisco's Higher Education webcast series http://www.cisco.com/web/strategy/education/us_education/webcasts.html I've watched the webcast and I like it. It's very realistic approach and I especially agree with opinion that deploying IPv6 means going into many compromises. We have been faced with very similar (almost same)

...

...

Do you have implemented first hop security? What will you do when some user runs RA flood attack You can hear me talk a little about that in the Cisco webcast. Right now we maintain a PACL on our switches that filter RA or DHCPv6 server traffic originating from access ports. As you mentioned it doesn't protect against malicious attempts to disrupt services on the network (fragmented packets) but it does add a reasonable level of stability (e.g. prevent Windows ICS) to levels that are similar to IPv4. In addition, we have a process that monitors our routers for new RAs on the network, and alerts us to that (which would let us respond to a malicious RA that got past the PACL). We are doing things just in the same way. Using PACL where is it

On 12/23/11 7:48 AM, Ray Soucy wrote: troubles that you have been talking about. possible (almost nowhere) and rest of the network we are trying to monitor. In case when an invalid RA appears we tries to repair it. For that we use combination of scapy sripts and home made tools (we were not satisfied with ndpmon, rafixd, ...). My colleague had a talk at that topic that is available http://tv.funet.fi/medar/showRecordingInfo.do?id=/metadata/fi/csc/tapahtumat..., slides http://openwiki.uninett.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf .

Having over 120 subnets monitoring is not the perfect solution. Requires installation of extra probes into each segment (so we do it only for some segments) and can't solve malicious attacks. But is better than nothing - for many subnets it is the only thing we can do. At least it minimizes impact of Microsoft's ICS behavior.

We probably haven't see any malicious attack on that. It's quite difficult say it for sure, because is quite difficult to distinguish which RA's are originated on ICS or witch ones are "other" activity. But remains that monitoring of rogue RA shows to us sometimes a really weird traffic.

I believe that is a matter of time when viruses/trojans will start using IPv6 features to perform DNS hijack as we were able to observe it in IPv4 (DNSChanger) a few years ago. Fortunately from a user perspective there is still quite easy solution how to guard against that attack in the IPv6 environment. I think we all know that solution :-)

...

For neighbor table exhaustion, I've written a set of scripts that I can use in a lab environment to perform the attacks against the platforms we use, and test how they fair. There is a pretty wide range of results. Most of the larger platforms that are the ones we would be concerned about actually hit CPU limitations before neighbor table exhaustion is accomplished, mainly because the neighbor discovery process doesn't appear to be implemented in hardware. It doesn't take much to pull off the attack either; a handful of residential connections would do the trick. This isn't an IPv6 problem so much as a vendor implementation problem, though. Like most DoS and DDoS attack vectors, vendors will need to take extra steps to harden equipment against these attack vectors as they become aware of them.

Until vendors catch up (and that includes us having the funds to upgrade to new platforms that do a better job with it), we have opt'd to make use of longer prefixes than 64-bit (in fact we mirror the capacity of the IPv4 prefix; so a /24 in IPv4 would be a /120 in IPv6). A good description of this is available in some slides by Jeff Wheeler at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf

While your mileage may vary with longer prefixes, with the same attacks we saw the impact on CPU usage to be less than half when longer prefixes were used, and that's pretty good. You can also keep external attacks from reaching internal routers if you don't do route summarization internally, which sees considerable gains, as more of that logic appears to be in hardware. In that area we also tried to use longer prefixes than /64, but we had difficulties on some devices. There was two kind of problems. Some of devices weren't able properly handle longer prefixes for example in routing protocols. The second group of devices tries to solve processing longer prefixes via software. So we had to gave up of using longer prefixes and now we uses 64-bit prefixes including point to point links (and hope that nothing will happen). But fact is that was 3 years ago, so maybe today the situation is much better. I haven't check for long time.

...

On the deployment side, we make use of DHCPv6 and RA with M and O set, and A unset. Our DHCPv6 servers only hand out IPv6 addresses to registered systems that are in the database and have been flagged as OK for IPv6. This has allowed us to roll out IPv6 on a host-by-host basis, rather than a network-wide basis (as you would need to do with SLAAC).

This does have the consequence of excluding hosts from IPv6, piticurally Windows XP systems, and pre-Lion OS X systems. But since IPv6 isn't "required" yet (there is really no IPv6-only content yet), we take the position that we only provide IPv6 to systems that support DHCPv6 and have an adequate IPv6 host-level firewall as part of their IPv6 implementation. This makes it easy to exclude hosts that might be problematic to deliver IPv6 to, due to lack of security, or even bugs (RHEL 3 can kernel panic when connected to over IPv6, for example). It also keeps the pressure on to upgrade legacy systems. With that we had a little differed attitude. Our idea was preferring native connectivity instead of running unattended tunneled traffic and traffic forwarded by ICS. We also were not certain whether SLAAC or DHCPv6 would be widely used. So we decided to preffer SLAAC because we wanted support as much system as possible. We also tried to develop our system solving data retention with connection to privacy extension (tech report http://www.fit.vutbr.cz/research/view_pub.php?id=9840 and related presentation http://www.cesnet.cz/akce/2011/monitorovani-kampusovych-siti/p/podemanski-mo...) . It runs quite well in our campus, it is maybye interesting research project but frankly said I have doubt whether such system is reliable to use in really large scale.

Now, when apple started supporting DHCPv6 it seems to me that DHCPv6 will be a common way for configuring addresses in a enterprise environment so maybe we will start thinking about it. There is another big issue with DUIDs.

Talking aboud DUIDs how do you solve that problem in your environment ? For v4 we have automatized (home made) system where users register their MAC addresses and based on it the the configuration for DHCP servers is created. In your presentation I saw that something similar is used in your environment as well. Do you use some automatized system for gathering UIDs or do you have to manually maintain a new DUID after every re-installation of OS ?

...

Wireless is an area we would really like to move forward with IPv6, but we still have concerns that need to be addressed before that can happen. In a Cisco environment, like ours, for example. IPv6 requires Ethernet Mode Multicast to be enabled on the WLAN. Unfortunately it doesn't provide tools to filter which multicast traffic is permitted, and at the scale we deploy wireless it just isn't practical. We might be able to re-architect wireless to better handle this, but that's a future project.

I think the big picture here is that IPv6 isn't as "easy" as it should be for large deployments just yet, but that's the case with any new technology. The more people who begin to work through it, the more we will identify problems, and work to resolve them. I agree with you. Deploying IPv6 is really not easy and not cheep as some IPv6 enthusiasts claims. Having practical experience it seems to me that many things in IPv6 that are very differed comparing to IPv4 (and I am not sure whether all this differences are really necessary) and that is the reason why many people and organizations prefer putting off deploying IPv6 instead investing effort and - of course - money.

Tomas

Hi, Op 21 dec 2011, om 20:16 heeft Tomas Podermanski het volgende geschreven:

Hi,

from my perspective the short answer for this never-ending story is:

To be fair, SLAAC was designed as a light weight method to configure addressing on the hosts. Hosts. We don't have hosts on the internet anymore, we stopped using dialup ages ago (or so it seems). We now address routers, and those have very different requirements, like needing routing and firewalling and some way to get subnets routed to them, that is where dhcp6 prefix delegation comes in. SLAAC serves no purpose for routers bar making the configure process awkward and error prone. That wasn't what we needed. I recently had a conversation with a promoter of the SLAAC method. "A 64KB ram device can configure a address and work as a autonomous sensor". I raised the concern that the device might need to connect to a host, since you couldn't find it in a /64 of address space. He honestly suggested that you could just configure to have it connect to a static address. Really, and nobody renumbers networks, at all? That's false. And that is still a host, not a router. And since then we've come a lot farther then 64KB sensor devices. Considering we can buy (wireless) routers at the local mall that have more ram and processing power then we used to have in a computer in the 90s now in a tablet, phone or other embedded device. Having built DHCP6 support in a open source firewall I agree that the (+IPv6) configuration of routers has become overly complicated and error prone, even more so due to possible renumbering. RA will have one thought, and the DHCP6 client another, not even going into multiple (possible differing) feeds of both IPv4 and IPv6 DNS servers. It was intended for hosts, not really minding that, but please, can we stop using it for routers? Regards, Seth

On Wed, 21 Dec 2011 15:18:05 PST, Owen DeLong said:

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.

OK, I'll name names. If you have end users still running WinXP, getting them at least somewhat working under SLAAC/DHCPv4 is a lot less headache than trying to DHCPv6 them. Anybody managed to stamp out WinXP in their end user population yet?

Look at that, for once I agree with Owen on all points made. ;-) On Wed, Dec 21, 2011 at 6:18 PM, Owen DeLong <owen@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/

Sent from my iPad On Dec 23, 2011, at 3:46 AM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

Hi,

On 12/22/11 12:18 AM, Owen DeLong wrote:

...

...

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?

It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system:

1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client

All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario:

1. DHCP options are processed by dhcp-client

Except when they are processed by BIOS, Kernel, or something else. Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way.

...

...

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

I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ...

If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup.

...

...

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

Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be:

If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4.

as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx However, Microsoft does not support SEND in any version of Windows.

I have found only one implementation for Linux (http://amnesiak.org/NDprotector/) that is not ready for production. So we can not think seriously about SEND today. SEND also brings another set of problems like certificate management, etc., but is a little differed story.

Right. Actual security is hard. No surprise there. Moreover, administrators are lazy. Also no surprise. Limited threat, lazy administrators, hard security, no action. This is the same in IPv4, IPv6, and doesn't really change whether you use SLAAC or DHCP or even static addresses.

...

...

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

I have to admit that less overhead is one of benefit of SLAAC. But having experience with DHCP(v4) all devices that we have today (phones, cameras, etc.) do not have a problem to process DHCPv4 packets, so there is no reason why same devices could not do it for DHCPv6. The sensor networks mentioned in one mail before is a very special case of use. I believe SLAAC might be useful there but is not typical case.

How many RFID sensors do you see managed on an IPv4 network? Thought so. The reality is that IPv6 has to support a much much wider range of hardware and applications than were ever considered for IPv4. Just because these may not apply to your environment does not mean that they are not important to other parts of the world.

...

...

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

I can not agree. Access switches usually do not support RA-Guard or IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500, 6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series (all with K software). All this series are not suitable (means too expensive) in a role of access switches. What worse RA-Guard can be easily bypassed (http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-n...). So even if you buy 3 times more expensive switches it does not help you :-(. As I wrote before - SEND is not an option today.

RA-Guard is in most Juniper switches today. Yes, there are improvements needed. However, it's not like DHCP is immune to spoofing attacks, so, I'm not sure why you think this is so much worse than the current state of IPv4 and/or IPv6 if we went with DHCP only.

...

...

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.

How that is getting better. Can you provide an example.

No, because some of what I know is currently NDA. However, it's not like vendors aren't hearing about these concerns and it's not like they aren't working to address them.

...

...

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

Agree. The firs option is the answer but you have to have DHCPv6 only environment.

But you don't need to eliminate SLAAC from everyone else's network to make that work. There's no need to deprecate SLAAC/RA from places where it works just fine to achieve what you want. That's my point.

...

...

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

As I wrote before. I do not think that overhead is an issue today.

And as I wrote before, I think that comes from a narrow view of the implementation spectrum.

...

...

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

It is true today, because not all operating systems supports DHCPv6. In many cases DHCPv6 is not an option.

I have seen environments where even if everything supported DHCPv6, SLAAC would still be a better solution for that environment. That's my point. Administrators should be able to choose the solution that best fits their environment. I'm all for the ability to create a DHCP-only environment, but, I don't want to see SLAAC/RA eliminated from environments where it provides benefit.

...

...

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.

And when we compare it with IPv4

- send DHCP request to DHCP server

Uh, no. DHCP request is never sent by client to DHCP server. Request is sent to broadcast. Then some magic happens (helper address) in most cases to forward it to the DHCP server, then some more magic happens to get the response back to the original client.

- get response - configure accordingly

Assuming that the client understands all the correct options, that all the options fit in a single packet, etc., etc., etc.

No waiting for RA packets, no additional "IFs", no additional conditions and all corner cases are solved. Why it can not work similar in IPv6? I know, there maybe is many reasons :-).

Uh, no, there are many corner cases I have encountered where DHCPv4 is a non-option and administrators have had no other choice in IPv4 but to use static addressing. Some of them would actually work just fine with SLAAC. Owen

Hi, On 12/23/11 4:33 AM, Owen DeLong wrote:

Sent from my iPad

On Dec 23, 2011, at 3:46 AM, Tomas Podermanski <tpoder@cis.vutbr.cz> wrote:

...

Hi,

...

...

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? It makes the client side more difficult to implement (=more expensive). What worse SLAAC and DHCPv6 are differed protocols, so there is bigger

On 12/22/11 12:18 AM, Owen DeLong wrote: probability for attacks (overflow, flood etc.). For example in UNIX-like systems autoconfiguration have to be solved by 3 parts of the system:

1. some SLAAC options are usually processed by a kernel (address selection, MTU) and behavior of that process can be changed via sysctl 2. some SLAAC options are processed by rdnssd daemon (processing DNS options) 3. DHCPv6 options are processed byt dhcpv6-client

All those parts have to cooperate together. At the first sight it is obvious that there is pretty good probability that something can go wrong. Troubleshooting then is really piece of cake. For example in IPv4 environment we have following scenario:

1. DHCP options are processed by dhcp-client Except when they are processed by BIOS, Kernel, or something else.

Sure, in all this parts (you probably meant PXE, network booting) we will have more difficult code. If developers are ok with that and I will have all that code in PXE, grub and a kerel code...

Yeah, the situation there in terms of the number of moving pieces is actually about the same. Even when DHCP options are parsed by dhcp-client, it has to use them to modify the kernel data structures and affect the behavior of other parts of the system, so, there's roughly similar amount of interaction either way.

...

...

...

- 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. I am not thinking about address. It is the easier part - we can use all provided. There are other options like DNS servers, search list, NTP servers, ...

If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others.

You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup.

...

...

...

- 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. Right, very easy to write but pretty difficult (impossible) to use today. None of operating systems supports SEND and some will probably never be: If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4.

I can not agree with that. Many operators having customers into a shared segment and uses security features I mentioned before ( again DHCP snooping, ARP protection, source address validation). In IPv6 is quite difficult to implement it even thou an ISP have a lot of money for new equipment. That is a reason why some operators prefer to block all protocols except IP(v4) and ARP instead of deploying IPv6. So we can not be surprised then that only less than 0.5% users have native IPv6 connectivity. I do not claim that is the only reason but one small piece of a bigger problem.

...

as we can find http://technet.microsoft.com/en-us/library/bb726956.aspx However, Microsoft does not support SEND in any version of Windows.

I have found only one implementation for Linux (http://amnesiak.org/NDprotector/) that is not ready for production. So we can not think seriously about SEND today. SEND also brings another set of problems like certificate management, etc., but is a little differed story.

Right. Actual security is hard. No surprise there. Moreover, administrators are lazy. Also no surprise. Limited threat, lazy administrators, hard security, no action. This is the same in IPv4, IPv6, and doesn't really change whether you use SLAAC or DHCP or even static addresses.

It is also question of money. For implementing more difficult environment the more experienced staff and more money is needed.

...

...

...

- 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. I have to admit that less overhead is one of benefit of SLAAC. But having experience with DHCP(v4) all devices that we have today (phones, cameras, etc.) do not have a problem to process DHCPv4 packets, so there is no reason why same devices could not do it for DHCPv6. The sensor networks mentioned in one mail before is a very special case of use. I believe SLAAC might be useful there but is not typical case. How many RFID sensors do you see managed on an IPv4 network? Thought so. The reality is that IPv6 has to support a much much wider range of hardware and applications than were ever considered for IPv4. Just because these may not apply to your environment does not mean that they are not important to other parts of the world.

I do not think that there is problem with that. SLAAC can be still an option. Today SLAAC is mandatory and DHCPv6 is an option.

...

...

...

- 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. I can not agree. Access switches usually do not support RA-Guard or IPv6-ACLs. For example looking at Cisco portfolio only 4900, 4500, 6500, 3750 series supports RA-Guard. In HP 54xx, 82xx, 66xx, 35xx series (all with K software). All this series are not suitable (means too expensive) in a role of access switches. What worse RA-Guard can be easily bypassed (http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-n...). So even if you buy 3 times more expensive switches it does not help you :-(. As I wrote before - SEND is not an option today.

RA-Guard is in most Juniper switches today. Yes, there are improvements needed. However, it's not like DHCP is immune to spoofing attacks, so, I'm not sure why you think this is so much worse than the current state of IPv4 and/or IPv6 if we went with DHCP only.

...

...

...

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. How that is getting better. Can you provide an example.

No, because some of what I know is currently NDA. However, it's not like vendors aren't hearing about these concerns and it's not like they aren't working to address them.

...

...

...

- 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. Agree. The firs option is the answer but you have to have DHCPv6 only environment.

But you don't need to eliminate SLAAC from everyone else's network to make that work. There's no need to deprecate SLAAC/RA from places where it works just fine to achieve what you want. That's my point.

...

...

...

- 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. As I wrote before. I do not think that overhead is an issue today.

And as I wrote before, I think that comes from a narrow view of the implementation spectrum.

...

...

...

- 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. It is true today, because not all operating systems supports DHCPv6. In many cases DHCPv6 is not an option.

I have seen environments where even if everything supported DHCPv6, SLAAC would still be a better solution for that environment. That's my point. Administrators should be able to choose the solution that best fits their environment. I'm all for the ability to create a DHCP-only environment, but, I don't want to see SLAAC/RA eliminated from environments where it provides benefit.

...

...

...

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. And when we compare it with IPv4

- send DHCP request to DHCP server Uh, no. DHCP request is never sent by client to DHCP server. Request is sent to broadcast. Then some magic happens (helper address) in most cases to forward it to the DHCP server, then some more magic happens to get the response back to the original client.

I deliberately used just the same description of obtaining information from a DHCP server. You have twisted it and trying to show DHCP(v4) in worse light. Just same (as you said) magic happen in DHCPv6. The only difference is that multicast address is used instead. And there is another difference. DHCP(v4) client renews an address (and options) directly from the server where the client get it from. DHCPv6 uses multicast for whole communication.

...

- get response - configure accordingly

Assuming that the client understands all the correct options, that all the options fit in a single packet, etc., etc., etc.

...

No waiting for RA packets, no additional "IFs", no additional conditions and all corner cases are solved. Why it can not work similar in IPv6? I know, there maybe is many reasons :-).

Uh, no, there are many corner cases I have encountered where DHCPv4 is a non-option and administrators have had no other choice in IPv4 but to use static addressing. Some of them would actually work just fine with SLAAC.

Can you be more specific? I can not imagine situation where SLAAC could solves a problem that DHCP would not. So I will be happy to hear that case/cases. Tomas

On Fri, 23 Dec 2011 21:06:26 +0100, Tomas Podermanski said:

On 12/23/11 4:33 AM, Owen DeLong wrote:

...

If there is actual real world demand for it, it will get implemented. Reality is that today, DHCPv4 has been running just as insecure for many years and nobody cares. I don't know why the bar for IPv6 should be so much higher than IPv4.

I can not agree with that. Many operators having customers into a shared segment and uses security features I mentioned before ( again DHCP snooping, ARP protection, source address validation).

Hate to inject some reality here - but Owen is totally correct here. That's all stuff you do *because DHCPv4 is an insecure protocol*. And a *lot* of places don't do all that added security on the IPv4 side because it's not part of their threat model, and probably don't want it on the IPv6 side for the same exact reasons.

On 12/23/11 6:56 AM, Mohacsi Janos wrote:

On Wed, 21 Dec 2011, 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 - 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

Your opinion is very extreme. Another extremity would be to add some extension into SLAAC/RA and remove DHCPv6 completely. BUT both mechanisms have their merits. They have to interporate! Every environment should develop their policy according to their needs!

...

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

They already do. If not they have to be fixed.

It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. 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.

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.

Michael Sinatra wrote:

...

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

You still need ND to provide the link-layer address resolution (i.e. the IPv6 equivalent of ARP), even with DHCPv6.

Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD.

Moreover, how do you come to the conclusion that DHCPv6, which uses multicast for the solicitation, is more reliable over links where multicast is unreliable?

DHCPv6 (and ARP) uses a lot less multicast/broadcast than ND.

FYI, I have been using SLAAC over 802.11 for many years, and have supported large 802.11 installations with SLAAC and have never had a problem related to "unreliable multicast" on that medium. Other problems, yes. But not that one.

That's because your 802.11 is not congested. Masataka Ohta

Karl Auer wrote:

...

Not necessarily. You can use ARP and DHCPv6 and you don't have to waste time and power for DAD.

IPv6 does not do ARP, it does ND.

First of all, ND use is optional and, if ND is used, RA must be used. It means that, if RA is not used, ND can't be used. Then, the only reasonable protocol for address resolution is ARP.

Even if you use DHCv6, you still need ND. DAD is still performed on addresses assigned via DHCPv6.

That is a requirement by SLAAC because SLAAC has distributed states, which can be inconsistent. If RA is not used, there is no such requirement. Masataka Ohta

Joel jaeggli wrote:

...

First of all, ND use is optional and, if ND is used, RA must be used.

It means that, if RA is not used, ND can't be used.

Finding and maintaining the l2 address for a device on a subnet where RA is not used is a pretty common activity so I'm not sure how your would conclude that. 2461/4861/5942 certainly don't preclude that.

RFC6434 has contradictory statements: Neighbor Discovery SHOULD be supported. and Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862]. and a reasonable interpretation is SLAAC MUST be supported if ND is supported. Or, we shouldn't expect IPv6 specifications reasonable, which means reasonable operation is impossible. Masataka Ohta

TJ wrote:

I think perhaps you are confusing "what must be supported by implementations" (and ignoring the text describing the requirements) as stated in 6434, with operational usage.

There is not much difference.

For example - SLAAC must be supported by the implementations, but an environment isn't required to use it.

Still, if ND, which SHOULD be implemented, is not implemented, SLAAC CAN NOT be implemented. And, if RA is obsoleted, which is a point of discussion, there is no reason to keep so bloated ND only for address resolution. Masataka Ohta

2011/12/26 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:

And, if RA is obsoleted, which is a point of discussion, there is no reason to keep so bloated ND only for address resolution.

By who? Sources please. A few people on NANOG complaining about RA is pretty far from deprecation of RA. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On 12/26/11 12:56 PM, Valdis.Kletnieks@vt.edu wrote:

On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said:

...

2011/12/26 Masataka Ohta<mohta@necom830.hpcl.titech.ac.jp>:

...

And, if RA is obsoleted, which is a point of discussion, there is no reason to keep so bloated ND only for address resolution. By who? Sources please. A few people on NANOG complaining about RA is pretty far from deprecation of RA. Especially when some of the biggest IPv6 networks out there are still using it pretty heavily.

(C''mon you guys, *deploy* already. It's pretty sad when people are arguing about stuff like this, and a frikkin' cow college out in the boonies pushing 300-400mbits/sec of IPv6 off-campus is still a "large" deployment. It's embarassing for the industry as a whole)

Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic. A fair number of them still have IPv4 issues. -- Mark Radabaugh Amplex mark@amplex.net 419.837.5015

Op 26 dec 2011, om 20:46 heeft Steven Bellovin het volgende geschreven:

Not quite what you're asking for, but I was very pleasantly surprised to see that some (at least) Brother printers support IPv6. Progress...

Indeed, my Mac has no issues printing or scanning to my MFC-9465DCN I purchased recently. I was pleasantly surprised, only SLAAC though, but it does register through mDNS and bonjour. Cheers, Seth

hi, is there any overview on current technology or method dealing with DDoS attack ? thanks in advance Joe

On Mon, 2011-12-26 at 13:23 -0500, Mark Radabaugh wrote:

Find me some decent consumer CPE and I would be more than happy to deploy IPv6. So far the choices I have found for consumer routers are pathetic. A fair number of them still have IPv4 issues.

You might find Adrian Kennard's blog to be of interest: http://revk.www.me.uk/2011/11/ipv6-for-consumers-on-dsl-at-last.html Pretty inexpensive, even here in rip-off Britain (~£32-35 inc. VAT @20%) to the point where a 'niche' ISP like A&A[1] can actually give them away for free with new lines. Tom [1] http://aa.net.uk

On Wed, 28 Dec 2011 07:49:21 +0900, Masataka Ohta said:

Valdis.Kletnieks@vt.edu wrote:

...

Especially when some of the biggest IPv6 networks out there are still using it pretty heavily.

That's not a valid counter argument against people who found problems in certain environment.

IPv6, as is, might work well under some environment assumed by IPng/IPv6 WG, a committee. The environment may be large.

IPv6 does not work well in many environments.

Feel free to try to deprecate *everything* that doesn't work well in many environments. Heck, SMTP doesn't work well in many environments (it's done in cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc) - but I don't see you leading a charge to deprecate SMTP. Probably because you actually use it, even though it's totally unsuitable for many environments. It's one thing to deprecate something that's obviously a complete failure or has reached historic status - but RA isn't either of those *yet*.

In this case, the following statement in RFC1883:

...

If the minimum time for rebooting the node is known (often more than 6 seconds), is the wrong assumption which made RA annoying.

Oddly enough, a lot of us are running on networks where assuming this about end user gear is perfectly reasonable. We haven't seen many consumer-grade Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds. Yes, I know you can do it with careful tuning and throwing SSDs and other hardware at it - doesn't mean it's common. Most of the time, any gains made in boot speed are immediately wiped out with "since it boots 10% faster, we can start 10% more stuff..."

Your straw man argument (which is what this has become) is just dancing around the real issue.  You're going to have to back up and make your case for us, rather than trying to respond to one-liners made (most of which were sarcastic, by the way). You have yet to identify who (beyond yourself) is calling for RA to be deprecated, though you made it sound like majority of the IETF was. You have yet to identify the problems with the design of RA that support that assertion. Taking the position that a single statement "is not a valid counter argument against a proposal to make RA deprecated" is weak at best; in actuality it wasn't a counter argument at all, but rather a statement exposing that you haven't presented an argument yet. The burden of proof lies with you, as you're the one calling for the deprecation of RA. So let's hear that, please (genuinely interested). 2011/12/28 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:

Valdis.Kletnieks@vt.edu wrote:

...

...

IPv6 does not work well in many environments.

Feel free to try to deprecate *everything* that doesn't work well in many environments.

Why not?

...

Heck, SMTP doesn't work well in many environments (it's done in cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc)

Red herring.

I thought all of us on some mailing list recognize SMTP working well.

But, if you insist you don't, feel free not to use it, which means you leave most, if not all, mailing lists including NANOG ones.

...

It's one thing to deprecate something that's obviously a complete failure or has reached historic status - but RA isn't either of those *yet*.

That is not a valid counter argument against a proposal to make RA deprecated, that is, make RA reach historic status.

...

...

In this case, the following statement in RFC1883:

...

   If the minimum time for rebooting the node is known (often more than    6 seconds), is the wrong assumption which made RA annoying.

Oddly enough, a lot of us are running on networks where assuming this about end user gear is perfectly reasonable.

That is because, as I wrote already in the previous mail,

...

      Network configuration was mostly stationary

For example, IPv6 might work well, if most of your end users are not moving rapidly between small mobile cells.

However, assuming you change the cells every 100m in average and you are moving at 100km/h, you must change the cells every 3.6 seconds in average, which means you must be able to change the cells frequently, which means each cell change take a lot less than 3.6 seconds.

...

We haven't seen many consumer-grade Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds.

IPv6 is wrongly architected, not because it assumes nodes are able to reboot in much under 6 seconds, but because it assumes new configurations necessary only at boot time.

...

Yes, I know you can do it with careful tuning and throwing SSDs and other hardware at it - doesn't mean it's common.

Obviously, the IPv6 committee and you are assuming computers of immobile main frame computers or, at least, immobile workstations.

However, in the real world, commonly available mobile phones are IP capable computers which wake up from dormant state within a second and needs handover often within a second.

                                               Masataka Ohta

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:

No counter argument possible against such abstract nonsense.

Yes. That was my point. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

Ray Soucy wrote:

After reading some of your work on end-to-end multihoming, I think I understand some of what you're trying to say. My problem is that while you seem to have a very strong academic understanding of networking, you seem to be ignoring operational realities in implementation.

To your surprise, my opinion is partially based on my experience about 10 years ago as a CTO of a commercial ISP, which offered secure public WLAN service with IP moblity. Security and mobility stacks were implemented on BSD and Windows. We successfully performed smooth handover experiment at a racing circuit with a car moving at 260km/h. http://www.root-hq.com/newsrelease/news030513.html (in Japanese) which is why I know delay caused by SLAAC is annoying. Though no commercial IPv6 service was offered, we received government funding and implemented end to end multihoming with mobility over IPv6 without ND. Public trial was offered: http://www.root-hq.com/e/newsrelease/pressrels0218.html (in English) Masataka Ohta

2011/12/28 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks@vt.edu wrote:

<SNIP>

...

...

In this case, the following statement in RFC1883:

...

If the minimum time for rebooting the node is known (often more than 6 seconds), is the wrong assumption which made RA annoying.

Oddly enough, a lot of us are running on networks where assuming this about end user gear is perfectly reasonable.

That is because, as I wrote already in the previous mail,

...

Network configuration was mostly stationary

For example, IPv6 might work well, if most of your end users are not moving rapidly between small mobile cells.

However, assuming you change the cells every 100m in average and you are moving at 100km/h, you must change the cells every 3.6 seconds in average, which means you must be able to change the cells frequently, which means each cell change take a lot less than 3.6 seconds.

To me, that sounds like an argument in favor of SLAAC. SLAAC is noticeably faster in my experience than DHCP (v4 or v6). Also, RAs can be sent in the ms range - for environments that expect that type of attachment-point-churn ... Also: Isn't 100m an arbitrarily tight range for a cel tower? And for cellular, isn't the real churn happening more at the Layer2 side ... no L3/IPv6/IPv4 interaction?

...

We haven't seen many consumer-grade Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds.

IPv6 is wrongly architected, not because it assumes nodes are able to reboot in much under 6 seconds, but because it assumes new configurations necessary only at boot time.

Boot time, or anytime a change in network attachment point is detected ... is that not sufficient?

Yes, I know you can do it with careful tuning and throwing SSDs and other

...

hardware at it - doesn't mean it's common.

Obviously, the IPv6 committee and you are assuming computers of immobile main frame computers or, at least, immobile workstations.

However, in the real world, commonly available mobile phones are IP capable computers which wake up from dormant state within a second and needs handover often within a second.

Again, if we are arguing about simple speed of address attainment - SLAAC wins.

Masataka Ohta

/TJ

TJ wrote:

...

However, assuming you change the cells every 100m in average and you are moving at 100km/h, you must change the cells every 3.6 seconds in average, which means you must be able to change the cells frequently, which means each cell change take a lot less than 3.6 seconds.

To me, that sounds like an argument in favor of SLAAC. SLAAC is noticeably faster in my experience than DHCP (v4 or v6).

RA initiated DHCPv6 is slower than RA, of course. Note that RA initiated DHCPv6 is even required to suffer from DAD delay.

Also, RAs can be sent in the ms range

Only when you are using mobile IPv6 and there still remains delay caused by DAD.

Also: Isn't 100m an arbitrarily tight range for a cel tower?

Cell size must shrink as bandwidth requirements of mobile devices increase.

And for cellular, isn't the real churn happening more at the Layer2 side ... no L3/IPv6/IPv4 interaction?

Because of large amount of traffic caused by smart phones, mobile providers, at least those in Japan, are trying to bypass traffic from 3G to WLAN/Internet with IPv4 L3.

Boot time, or anytime a change in network attachment point is detected ... is that not sufficient?

It is wrong to assume intervals between changes 6 seconds. In general, ND is wrong to specify link specific timings assuming infrequent changes. Masataka Ohta

TJ wrote:

...

RA initiated DHCPv6 is slower than RA, of course.

I am not counting the "delay" caused by waiting for the RA against DHCPv6.

Do you count random delay between RA and DHCPv6 solicit? Do you count DAD delay after DHCPv6?

Isn't the stateless operation of a router providing a prefix in a RA always going to be faster than statefully providing an address via DHCPv6 (even with rapid commit enabling 2 messages to suffice; and noting that normally DHCPv6 involves 4 messages and relaying)?

As the stateless operation is actually stateful to keep address assignment states by all the related nodes, DAD is required to confirm the state is consistent, which means delay. With DHCP only, there is no DAD necessary.

...

Only when you are using mobile IPv6 and there still remains delay caused by DAD.

I would say that it is only possible on platforms that support it. You are not required to enable mobile anything in order to set the advertisement interval to be that tight.

Can I? I'm refering to RFC3775: One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. which is applicable only to MIPv6 routers.

In either case, yes, DAD "must" happen ... although Optimistic DAD can help there,

The straight forward solution is to remove DAD along with stateful SLAAC.

or perhaps other link specific solutions.

A link specific solution is DHCPv6 without RA.

...

Cell size must shrink as bandwidth requirements of mobile devices increase.

Understandable, but down to the 100m range?

It is also a typical range for WLAN.

*(Partially tongue in cheek pre-response to your next statement: And why should they bother, if the users can just hop onto WiFi? :) )*

Moving users should be able to keep hopping onto WLANs.

...

In general, ND is wrong to specify link specific timings assuming infrequent changes.

In principle I agree, but assumptions must be made somewhere or nothing can get done. If there is a change required to make it work, do so - the "IPv6 over Foo" RFCs are a good place to specify preferred values for $Foo.

The fundamental problem of ND is that it tries to be the only way to have IPv6 over all the possible link layers. Instead of having "IPv6 uber Alles", the wrong goal of "ND uber Alles" was targeted. So, if we give up the goal to have "IPv6 over Foo", there is no reason to insist on "ND uber Alles". Masataka Ohta

In a message written on Wed, Dec 28, 2011 at 08:33:23PM +0900, Masataka Ohta wrote:

However, assuming you change the cells every 100m in average and you are moving at 100km/h, you must change the cells every 3.6 seconds in average, which means you must be able to change the cells frequently, which means each cell change take a lot less than 3.6 seconds.

Moble networks do not today, and should not in the future expose those handoffs to the IP layer. Even WiFi networks are moving from the per-cell (AP) model you describe to a controller based infrastructure that seeks to avoid exposing L3 changes to the client. You do not want to get a new L3 address every 3.6 seconds. Worse, if in the case of VoIP you need a cell handoff to take < 25ms or so, which could never happen with new L3 addresseing and then renegotating the session to a new L3 address. Moble networks are designed to provide a L1/L2 fast switching path back to a controller infrastructure which then provides the L3 handoff. This properly decouples the layers and allows normal LAN based timing for the L3 system. The short version is, the cell to cell handoff time, or the cell dwell time is irrelevant for any L3 addressing problem. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Dec 24, 2011, at 4:36 PM, Masataka Ohta wrote:

Joel jaeggli wrote:

...

...

First of all, ND use is optional and, if ND is used, RA must be used.

It means that, if RA is not used, ND can't be used.

Finding and maintaining the l2 address for a device on a subnet where RA is not used is a pretty common activity so I'm not sure how your would conclude that. 2461/4861/5942 certainly don't preclude that.

RFC6434 has contradictory statements:

Neighbor Discovery SHOULD be supported.

and

Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862].

These do not conflict.

and a reasonable interpretation is SLAAC MUST be supported if ND is supported.

The implementation of IPv6 in a host MUST support SLAAC. That does not mean that the host must use that support in any particular environment. Owen

On Fri, 23 Dec 2011, Tomas Podermanski wrote:

It sounds good, but according to  RFC 6434 ( IPv6 Node Requirements) SLAAC is required, but DHCPv6 is only optional. So any manufacturer of operating systems or devices do not have to support DHCPv6.

You might propose updating RFC 6434

Administrators are deliberately providing conflicting information?

Not administrators, but attackers then could have more ways for harmful activity.

That is why you are administrator - closely monitor your network.

Some operating system do the SLAAC processing in user space. What is the problem.

As I wrote. Troubleshooting is more difficult.

Both can difficult to troubleshhoot

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

In my opinion client can ask address via DHPv6 without paying attention to RA messages.

Agree, can be another advantage. But in fact it seems that networks with thousand devices will rather prefer dhcpv6 instead.

As other already mentioned: SLAAC for less controlled, more resource concerned environment. DHCPv6 for more tightly controlled ones. Best Regards, Janos Mohacsi

...

...

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

Having done a fair amount of troubleshooting for both SLAAC and DHCPv6 in real world deployments, I think your argument may be more theoretical than anecdotal in this case. In my general experience, it's been relatively easy to troubleshoot either protocol and neither is particularly more difficult than the other. Start by making sure that you are sending and/or receiving correctly formed packets with the right data. If not, then you know that the packet originator is the most likely culprit. Absent misconfiguration of the router, I've never seen an incorrect RA. I've never seen an incorrect RS packet. Malformed DHCPv6 packets have been extremely rare in my experience. Packets with incorrect data are almost always the result of a configuration error. The difference of whether this is processed in kernel or user space has very little impact on the troubleshooting process in most real world scenarios. Owen

I had some trouble parsing what Glen was saying, so, I'll provide some clarification of how things actually work today and what I think would be desirable in future development: 1. In IPv6, it is not uncommon for certain types of routers to be DHCP clients. DHCPv6-PD is relatively useless except when talking to a router. 2. Routers rarely listen to RAs and mostly generate them. There's no reason for router A to listen to RAs from router B on the same link. Router A doesn't care that Router B can be a default gateway. If Router A needs a default gateway, router A shouldn't be advertising himself with RAs and should know about Router B from a static route or some routing protocol. RAs are only useful (as far as routing is concerned) for routers to announce themselves as default gateways. They do not provide any mechanism for advertising more specific routes. 3. As it currently stands, RAs can provide the following information: + Default Router (anything sending an RA should be a valid default router). + Router Priority (High/Medium/Low) + Prefixes (must be /64) for SLAAC * Desired Lifetime * Valid Lifetime + DHCP Server Address + DNS Resolver Address[1] + M-Bit (Network is managed, host should ask DHCP server for some configuration information) + A-Bit (DHCP server is authoritative for addressing, do not use SLAAC to generate unicast addresses from prefixes) [1] Requires recent extensions to SLAAC and RA. Not available in all implementations. 4. As it currently stands, a DHCPv6 server can provide most of the things you're used to a DHCP server providing. It cannot provide any information about routing whatsoever. There is currently no mechanism for a host to ask a DHCPv6 server for configuration information unless and until it receives an RA with at least the M-Bit set. (You currently can't use DHCP without RA). Currently, many clients support only SLAAC and Static for configuring IPv6 information. If you have such clients in your environment, setting the A-bit is generally self-destructive. Short of some form of NAC[2], there is currently no mechanism for preventing a host which uses SLAAC in spite of the A-bit being present (nefariously or erroneously) from making use of the network with that address. (i.e. you can't force a host to use DHCPv6 if it is not well behaved). [2] Network Admission Control -- A process which does not place clients into functional VLANs on the switch until certain policy defined criteria have been met. 5. What I'd like to see: 1. A mechanism for DHCP to be used without requiring RA at all. 2. A mechanism for DHCP to provide zero or more copies of an optional attribute called "Routing Information". Said attribute's value would be a structure containing: Prefix (128 bits) Masklen (8 bits) Next-Hop (128 bits) Metric (16 bits) A default router would be specified as: Prefix 0::0/128 Masklen 0 Next-Hop pfx::gateway A static routing table with specific routes could be built as: Prefix 2001:0db8:0:32:: Masklen 64 Next-Hop 2001:0db8:0:7::1 Prefix 2001:0db8:0:64: Masklen 60 Next-Hop 2001:0db8:0:7::5 Prefix :: Masklen 0 Next-Hop 2001:0db8:0:7:feed:beef:cafe:babe 3. Extensions to SLAAC to provide for NTP, "next-server", "boot-file", and certain other key elements available from DHCP, but, not possible in the current specification for SLAAC. Yes, this will annoy those purists who believe there should be one true way to do each thing. That's OK, they're entitled to their opinion, but, this is mine. DIfferent operators have different preferences and different environments sometimes work better or adapt better to different solutions. Currently, most significant environments have to cobble together a complete solution from remnants of SLAAC and DHCP. This is far from ideal. Far better for organizations to look at 2 complete solutions and pick the solution that works best for them in their environment. Owen On Dec 20, 2011, at 1:58 AM, Glen Kent wrote:

When a router needs to learn information from another router it will *usually* use the RA messages and not DHCPv6, as the latter is *usually* meant for Router - Host communication. However, it is NOT uncommon to see hosts also learning the information using RA messages. Router's afaik dont usually act as DHCP clients and thus information that can only be passed in DHCPv6 may not be available to the routers, and you may need an alternate mechanism.

Glen

On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal <raviduggal2906@gmail.com> 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.