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
