[147705] in North American Network Operators' Group
Re: IPv6 RA vs DHCPv6 - The chosen one?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Dec 20 10:04:28 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPLq3UMXkUfv1tyYcRYJ_qM+5Z8SYR2KiY3iV0NY8VUWLO2aFg@mail.gmail.com>
Date: Tue, 20 Dec 2011 06:58:24 -0800
To: Glen Kent <glen.kent@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> Glen
>=20
> On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal =
<raviduggal2906@gmail.com> wrote:
>> Hi,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> 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.
>>=20
>> Regards,
>> Ravi D.
>>=20
