[147922] in North American Network Operators' Group
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed Dec 28 06:14:59 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <4EF14814.2080709@bowenvale.co.nz>
Date: Wed, 28 Dec 2011 12:13:34 +0100
To: Don Gould <don@bowenvale.co.nz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Just to clear up a few misconceptions:
=3D=3D=3D=3D begin explanation current situation =3D=3D=3D=3D
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.
=3D=3D=3D=3D issues and way forward =3D=3D=3D=3D
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=
