Internet DRAFT - draft-yourtchenko-ra-dhcpv6-comparison
draft-yourtchenko-ra-dhcpv6-comparison
Network Working Group A. Yourtchenko
Internet-Draft cisco
Intended status: Informational November 27, 2013
Expires: May 29, 2014
A comparison between the DHCPv6 and RA based host configuration
draft-yourtchenko-ra-dhcpv6-comparison-00
Abstract
This document attempts to make a balanced comparison between the RA-
based and DHCPv6-based host configuration mechanisms. It compares
the two on different aspects, e.g: underlying media assumptions,
coordination, locality, etc. and highlights the strong and weak
sides of both protocols for each scenario.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 29, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Interworking with different L2 topologies . . . . . . . . 3
Yourtchenko Expires May 29, 2014 [Page 1]
Internet-Draft RA and DHCPv6 comparison November 2013
2.2. Acknowledged vs. Unacknowledged . . . . . . . . . . . . . 3
2.3. Client initiated vs. server initiated . . . . . . . . . . 4
2.4. Centralized coordination vs. distributed coordination . . 4
2.5. Single Source of Truth vs. Multiple sources . . . . . . . 4
2.6. The amount of server-side state . . . . . . . . . . . . . 5
2.7. Involvement or not into routing . . . . . . . . . . . . . 6
2.7.1. Comparison . . . . . . . . . . . . . . . . . . . . . . 6
2.7.2. Discussion 1: On multiple default gateways per segment 6
2.7.3. Discussion 2: Why require an RA if DHCPv6 is more
appropriate ? . . . . . . . . . . . . . . . . . . . . 7
2.8. Server locality . . . . . . . . . . . . . . . . . . . . . 8
2.9. Programming: UDP vs. ICMP . . . . . . . . . . . . . . . . 8
2.10. Separate vs. unified management . . . . . . . . . . . . . 9
2.11. Scope of use / Applicability . . . . . . . . . . . . . . . 9
2.12. IPAM tools impact comparison . . . . . . . . . . . . . . . 10
2.13. Security tools impact comparison . . . . . . . . . . . . . 10
3. Arguments for running only a single protocol . . . . . . . . . 10
3.1. Support and Security Complexity . . . . . . . . . . . . . 10
4. Differences between different types of network operators . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Musings on further protocol directions in IETF . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
IPv4 provided only one way of configuring the addresses and node
parameters: DHCP. Having no choice made the choice simple.
DHCPv6 allows for a similar mode of operation with DHCPv6, but also
introduces the mandatory Router Advertisements, which overlap in some
functionality with DHCPv6. This creates the problem: what is the
best ? How do I know which of the two to use ? Since "the best"
usually means "the best for me", it is an inherently locally-
significant adjective. A lot of arguments are not taking this into
the account, resulting in deadlock situations and mutual frustrations
during the discussion. The goal of this document is dissecting the
technical properties of both address configuration mechanisms. This
should hopefully result in a more objective and technical analysis,
and allow for a better judgement of which mechanism is "better" in
each specific case.
The author of the document does not take any sides nor tries to
promote one approach over the other. If you, the reader, spot any
instance where this is not the case, please inform the author so this
could be corrected.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Yourtchenko Expires May 29, 2014 [Page 2]
Internet-Draft RA and DHCPv6 comparison November 2013
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Comparison
2.1. Interworking with different L2 topologies
RA is "server-initiated, send once, receive many, no confirmation"
abstraction - something that works well on the 10base2-type shared
bus and even the today's wired ethernet, but looks quite miserable on
the WiFi media without the special tricks (802.11 provides reliable
delivery for unicast frames, and does not provide one for multicast
frames, also the physical speeds are different and even the
contention management and the speed/modulation can be different as
well).
DHCPv6 is "client-initiated, send once, receive once, confirmation"
abstraction. This may be wasteful on the low-bandwidth links that
provide bus topology, but maps extremely well onto scenarios like
WiFi - as it allows to maintain somewhat familiar mode of operation
to wired ethernet.
This is where the peer-to-peer, acknowledged nature of DHCPv6 may be
beneficial - on a crowded large-scale WiFi, without special tricks to
ensure the reliable delivery of multicast packets, you simply will
not get the SLAAC working because the multicast RAs will get crunched
by the interference.
Alternatively, in a very mobile environment and the RFC-compliant
router, multicast solicited RAs might make a significant portion of
your traffic - which, due to a difference in modulation, etc. may
eat way more bandwidth than if they were sent unicast.
2.2. Acknowledged vs. Unacknowledged
DHCPv6 needs at least 2 packets. RA is just one packet.
RA strength: it is quicker; RA weakness: you have to take care that
it is legitimate router and not your evil neighbor sending you the
RAs you take the configuration from.
DHCPv6 Plus: works well in the noisy/lossy environments; DHCPv6
minus: takes at least 1 RTT to the server. The necessity for the
multiple packets exchange does not obviate the need for the securing
DHCPv6 in a similar fashion.
There is one additional reason for the DHCPv6 to be slower. RFC3315
states: "A client MUST collect Advertise messages for the first RT
seconds, unless it receives an Advertise message with a preference
Yourtchenko Expires May 29, 2014 [Page 3]
Internet-Draft RA and DHCPv6 comparison November 2013
value of 255.". Since most of the time the preference in DHCPv6
messages is not 255, the compliant nodes will be at least 1 second (+
/- up to 0.1 sec) slower than those using RA - as RT is calculated
based on SOL_TIMEOUT value.
2.3. Client initiated vs. server initiated
Despite the division above, RA can be client-initiated, to some
extent, with RS, and DHCPv6 can be server-initiated, to some extent,
with "Reconfigure" messages.
If we treat these as "nudge" messages, the behavior of the sending
and receiving parties is similar - the "nudge" message causes the
orderly protocol exchange to occur before the due time.
The part that is different, though, is that RA, due to its "send
once, receive many" nature, can aggregate the "nudge" messages, so
intuitively seems best for a scenario with a very large number of the
hosts, as it should have self-stabilizing properties, compared to
DHCPv6.
This "self-stabilizing" property intuitively seems to make RA safer
to use, IFF it is used in purely "multicast" fashion. However, the
L2 media interaction concerns might affect and even cancel out this
property, depending on the environment.
2.4. Centralized coordination vs. distributed coordination
RA, due to its "send once, receive many" nature, in its pure form
necessarily can not dictate a per-client settings, but rather can
only advise the domain the client would pick from (SLAAC).
DHCPv6 on the other hand, due to its p2p nature is by default well
suited for the individual per-client tweaking.
The distributed nature can be a blessing if you do not care about who
gets which address and a curse if you need to account everyone
strictly.
NB: address assignment does not mean that the hosts will always use
those addresses - e.g. it's perfectly possible to statically
configure a different address, but we talk just homogenous standards-
compliant well-behaved hosts for simplicity sake).
That's why the title of this section does not use the word "control"
but rather uses the word "coordination".
2.5. Single Source of Truth vs. Multiple sources
The DHCPv6 model requires the client to choose only one of the
advertise messages that it receives. When using RA, the client can
Yourtchenko Expires May 29, 2014 [Page 4]
Internet-Draft RA and DHCPv6 comparison November 2013
combine information from multiple sources.
This section is quite intertwined with the previous one (distributed/
centralized), and the reasoning for when a particular protocol is
"good" or "bad" will be similar - RA based configuration will be best
in case the networks are not under administration, and the hosts are
given a lot of flexibility.
On the other hand, DHCPv6 will be useful for the case where there is
a need to tightly control the behavior of the hosts and have a highly
predictable configuration of the network as a whole. Of course, as a
tradeoff such predictability brings potentially increased fragility.
An example where this difference might be crucial is a segment with
two servers, aware of each other state. If server A goes down, then
server B, when using RA-based mechanism, can just send a message with
the lifetime of zero. The DHCPv6-based implementation of this
scenario would need to be more involved - if the client trusted the
server A to begin with, it will not listen to notifications from B -
so B will need to spoof A in some way.
However, at the same time this ease with which one device can
instruct the hosts on behalf of the other can be also considered a
weakness in a stricter environment - and require additional security
measures in place so that a malicious host did not impersonate a
router.
2.6. The amount of server-side state
RA in its pure form is inherently stateless - there is no per-client
information stored on the sending router. This eases the things like
redundancy and failover compared to DHCPv6.
DHCPv6 in its stateless incarnation also does not keep the state -
however, in the scenario of the DHCPv6 server sending the RECONFIGURE
message to the client, DHCPv6 server must keep some knowledge of the
client - which means it might need to keep some state.
FIXME: Further experimentation needed to test how it actually works
in real life implementations.
jinmei@wide.ad.jp: If you mean the Delayed Authentication Protocol by
DHCPv6 authentication, the WIDE DHCPv6 supports it: http://
Yourtchenko Expires May 29, 2014 [Page 5]
Internet-Draft RA and DHCPv6 comparison November 2013
sourceforge.net/projects/wide-dhcpv6/ although I myself have only
used it in testing. I heard some other vendors implemented it, too.
(And, for that matter, it also supports the Information Refresh Time
option (RFC4242)).
2.7. Involvement or not into routing
2.7.1. Comparison
An RA-based protocol interaction may influence host's routing. A
DHCPv6-based interaction today can not influence the host's routing -
it was specifically denied any and all involvement into routing.
RAs as a mechanism, due to its "multiple sources of truth" nature,
can allow unsophisticated form of routing resiliency for the hosts.
While architecturally "pure", the reliability and timing of the
routing resiliency provided by the RAs is far below those achieved by
FHRP protocols - which makes the "distributed routing for
unsophisticated hosts" property unusable in the most networks.
With this, the role of the RAs is reduced to just supplying the
default gateway (and maybe some static routes) - something that is
successfully done by DHCPv4 today. This creates an impression that
adding this functionality to DHCPv6 would allow to get rid of the RA
completely for that use case.
However, the "single source of truth" nature of DHCPv6 prevents the
successful operation in case of multiple servers on the segment
supplying different information. RAs in this case may still work.
Some consider the inability to support this scenario crucial, and
some think it is not useful. This creates contention between the
proponents of those who want DHCPv6 deal with routing, and those who
think RA is the single possible candidate for that.
The other aspect is that because RA ties in the routing and
addressing information, one can say "RA shares the fate with
routing". In other words - when you receive an RA, it is always (in
the protocol-compliant case) coming from a router. In the case of
using DHCPv6, it is not the case.
FIXME: This section needs further debates, clarifications, and a
rewrite. Discussion welcome.
2.7.2. Discussion 1: On multiple default gateways per segment
Yourtchenko Expires May 29, 2014 [Page 6]
Internet-Draft RA and DHCPv6 comparison November 2013
The premise that many people in the IETF seem to be working on is
that the typical - or even a common - deployment case of IPv6 will
involve multiple routers per lan segment. I say this because every
time the issue of DHCP providing a default gateway comes up, one of
the main arguments is that it will break the multiple-routers-per-
lan-segment scenario. The operational reality is that multiple
gateways on the same LAN is going to be the rare exception rather
than the rule - outside truly large operations (i.e. 10s of
thousands of users).
Many consciously choose for L2 interfaces (with HSRP/ VRRP) isolation
LANs between service providers precisely because L3 is more complex
to debug and engineer across an administrative boundary. Even
agreeing on an IGP can be tricky, never mind worrying about route
flapping or redistribution loops. Experience has shown that HSRP/
VRRP + static routes in a simple active/standby construction can
deliver extremely robust SLA KPI's. Secondly, practical deployment
of L3 routing protocols on end hosts was a no-go in IPv4.
Service providers will attempt avoid multiple gateways per network
because it makes their deployment scenarios more complicated and
provides no extra value. For server / host farms, service providers
like FHRP with tight timers because it gives control of onward
connectivity.
Regarding RA for routing and DHCP for addressing, what people care
about is connectivity. What I need as an operator is a protocol
(preferably a single protocol because that is simpler) which will
enable my boxes to gain the connectivity they need. Whether you call
this routing or providing a default gateway, I don't much mind.
Look, there's too much ideology going on here. The IETF is being
dazzled by the sight of multiple lan segments and multiple egress
gateways without realising that these are the minority configuration.
All this effort is going into optimising ipv6 address / lan
autoconfiguration for these unusual scenarios without heeding the
sober reality that most people, service providers and enterprises are
only ever going to want to have a single defgw per lan segment, and
that by far the most common deployment scenario will be a single lan
segment per organisation.
Wireless? My smartphone already has two radios and a physical
interface, connected to multiple providers. How exactly do you then
configure a "single defgw per lan segment" (without draft-troan-
homenet-sadr-01)
I'm aware that this viewpoint will be regarded as retrograde, and
that a bunch of people on this list will probably sit there, rolling
their eyes and thinking: "yeah, and 640k was enough for everyone".
Just bear in mind that added complexity is not necessarily a good
thing. The support costs are high and the return on effort is
dubious at best. IOW, the IETF is optimising a corner case.
Yourtchenko Expires May 29, 2014 [Page 7]
Internet-Draft RA and DHCPv6 comparison November 2013
2.7.3. Discussion 2: Why require an RA if DHCPv6 is more appropriate ?
The question is why would someone use RA for multiple gateway
announcement when you'll get much better operational performance from
a FHRP + single gateway address? And why use RA for addressing when
you'll get finer grained operational host control using DHCPv6 ?
You can have client specific RAs that solve that problem. This is
not a missing capability that duplicating RA functionality in DHCPv6
would then provide.
Or when you need to use DHCPv6 anyway in order to make your hosts do
what they need to do? Or on server farms when most of your hosts are
statically addressed and it doesn't make sense to have multiple
gateways with different addresses - and you'll get better uptime by
not using RA? I'm not proposing to take away the option of using RAs
if that's what you want to do. I'm only suggesting that for many
situations, it makes more sense to have a single static gateway
address (optionally with multiple routers using a FHRP if you need
reliability) and that consequently the idea of periodically
announcing a selection of arbitrary gateways via RA is operationally
second rate.
I would really like to know specific details of these many
situations, and what specific benefits switching off RAs would have.
I have been in many situations in many networks, and when I consider
my IPv4 experience (and also compare it to my Novell IPX and
Appletalk experiences), I see a lot of value in having RAs provide
default gateway(s) (VRRP/HSRP or not) information and other layer 3
parameters to directly attached hosts from the directly attached
router(s). This is in comparison with the IPv4 alternative effort of
enabling and configuring a heavier and more resource consuming
stateful DHCP server on either the first hop routers, or enabling
DHCP relays and then having to have a redundant DHCP infrastructure
somewhere else in the network. It could be argued that DHCP could be
enabled and configured by default, but that is also obviously the
case with RAs, and they have been enabled by default since day one.
The ability to automate the configuration of DHCP does not inherently
make DHCP better than RAs.
2.8. Server locality
Both DHCPv6 and RA are inherently link-local mechanisms, however
DHCPv6 has a means to "jump" over multiple hops by use of the relays.
This means RA *has* to be distributed, while DHCPv6 can be both
centralized and distributed. Frequently it is made centralized
because of other benefits that centralized administration brings, but
almost any router today can run a DHCPv6 server itself with very
little problem.
2.9. Programming: UDP vs. ICMP
Yourtchenko Expires May 29, 2014 [Page 8]
Internet-Draft RA and DHCPv6 comparison November 2013
The programming difficulty is a somewhat subjective topic. On one
hand, one can say ICMP is harder than UDP to implement; it often
requires raw sockets or kernel collaboration (e.g., on Linux RDNSS
information can be read using netlink. UDP is much simpler). On the
other hand, stateful DHCPv6 can be arguably a more complicated
protocol to implement than RAs, with more message types and so on.
On the other hand, it could be argued down to a choice of API:
writing programs handling RA options like RDNSS is no harder than
writing DHCPv6 client in terms of socket API. As long as the system
supports RFC3542 you should be able to write a portable RA "client"
pretty easily (meaning as easy/hard as writing some UDP client
program). For example, FreeBSD's rtsold supports RDNSS and (AFAIK)
only relies on the RFC3542 APIs. Also, since DHCP is trickier than
other UDP applications in some points (it's more sensitive to which
interface to use, and in some cases you need to make sure the source
address is link-local, etc), it's quite likely that you'll need
something like unusual APIs like RFC3542 or some non-portable system
dependent interface to write a standard-compliant DHCP(v6) client.
So, overall, I'd say the programming difficulty regarding UDP (DHCP)
vs ICMP (RS/RA) is marginal.
In summary, it is probably fair to say that the "difficulty" in this
context equates to "unfamiliarity" in some respects, and "protocol
complexity" in others.
2.10. Separate vs. unified management
If DHCPv4 and routing is managed by the different groups in the
organization, then conceivably the "server" people will not like to
have their work go away and similarly "router" guys are happy to get
rid of yet another point of coordination and argument.
This is where the "I hate $protocol" could definitely pop up -
because for one side it may be the media interworking that is a
crucial factor, while for the other side it is the amount of state
held on the server - thus the agreement would never be achieved
because they are arguing about different things.
2.11. Scope of use / Applicability
Another, somewhat philosophical question: what information should be
sent by the RA, and what information is appropriate to be sent by
DHCP, and which information should not be sent by either ? (Of
course, this assumes such a division exists.) The currently held
wisdom is as follows:
DHCP SHOULD configure the network resources available for the client
device to use (i.e., things needed to provide network connectivity
and access to that network's services). It should not configure user
specific services (i.e., there was some discussion about email (SMTP,
POP, IMAP server) information as an example of something that would
not be DHCP configured).
Yourtchenko Expires May 29, 2014 [Page 9]
Internet-Draft RA and DHCPv6 comparison November 2013
Another, IETF-specific approach about what can be configured with
DHCP: if the protocol is or was in the Internet area, it's probably
something you can configure with DHCP; if it's not, think carefully
before using DHCP to configure it. This lets out a _lot_ of stuff
that has options in DHCPv4. But I (Ted Lemon) can't think of
anything it excludes that I'd want to keep around. Of course, Mobile
IPv6 is an Internet area protocol, and it's not entirely clear to me
that it's configurable via DHCP, although there exist DHCP options to
configure it.
FIXME: AY: The above section needs more work and discussion to
understand: (1) is there a strict division of functions between the
RA and DHCP (2) should there be a strict division of function ?
2.12. IPAM tools impact comparison
This is an indirect dependency, resulting in the centralized vs.
distributed nature of DHCPv6 vs. RA. IPAM tools integration with
DHCP is fairly well understood from IPv4. When using RA, however, the
IPAM can not track the addresses used. Of course, the larger subnet
addressing space of IPv6 might in some cases transform the work
performed by the IPAM systems from tracking the individual hosts
towards tracking the subnets. However, the host tracking needs to
still be performed, and correlating the addresses with the hosts may
be harder.
This said, until very recently DHCPv6 replaced the MAC address with
DUID - which created its own set of challenges.
2.13. Security tools impact comparison
From Brian Carpenter. For further discussion.
3. Arguments for running only a single protocol
The "Comparison" section aims to highlight the various differences,
and implicitly show the reasoning to have two protocols implemented
in the nodes. This section enumerates the reasons for a network
operator to strongly prefer having only one of these two protocols in
operation on the network at any point in time.
3.1. Support and Security Complexity
The requirement to run two protocols at the same time securely
results in the need to snoop both of them - for effective source
address validation. Some vendors are unable to handle both at once.
This means operators are very exposed to rogue RAs and rogue DHCPv6
packets flying around networks.
FIXME: To discuss further with Nick / other operators. Basic
protection should be doable with just a simple PACL - which should
work at once for both protocols.
Yourtchenko Expires May 29, 2014 [Page 10]
Internet-Draft RA and DHCPv6 comparison November 2013
4. Differences between different types of network operators
Mostly placeholder, to capture the different requirements from
various different network profiles (home-like zeroconf network, rural
type network, university campus, enterprise, bank, ISP, etc.).
5. Conclusion
This document has attempted to show that both DHCPv6 and RA based
configuration mechanisms have their unique strengths and weaknesses,
and each of them may be "the best" depending on the environment for a
particular network.
Therefore, the host stacks which expect to maximize their chances of
connectivity when moving between different networks, will achieve
this best by implementing both mechanisms - else they might end
lacking essential configuration parameters if the network supports
the mechanism of not their choosing.
The networks may adopt a similar approach of attempting to support
both mechanisms at once, to try to accomodate the "single-minded"
hosts - but doing so usually incurs the overhead, which should be
evaluated by the network administrators.
6. Musings on further protocol directions in IETF
FIXME: To discuss: do we define spheres of influence for SLAAC/RA and
DHCPv6, with strictly limited overlap, or do we try to make them
equipotent, with a shared data model for their options ?
7. Acknowledgements
Thanks to Ted Lemon for triggering the creation of this document.
Thanks to the following people who brought in text or ideas into the
document: Bernie Volz, Brian Carpenter, Nick Hilliard, Brian
Haberman, Lorenzo Colitti, Ted Lemon, Ray Hunter.
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149, April 1990.
Yourtchenko Expires May 29, 2014 [Page 11]
Internet-Draft RA and DHCPv6 comparison November 2013
Author's Address
Andrew Yourtchenko
cisco
7a de Kleetlaan
Diegem, 1830
Belgium
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Yourtchenko Expires May 29, 2014 [Page 12]
