| Network Working Group | A. Yourtchenko |
| Internet-Draft | cisco |
| Intended status: Informational | November 27, 2013 |
| Expires: May 31, 2014 |
A comparison between the DHCPv6 and RA based host configuration
draft-yourtchenko-ra-dhcpv6-comparison-00
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.
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 31, 2014.
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.
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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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.
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 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.
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.
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".
The DHCPv6 model requires the client to choose only one of the advertise messages that it receives. When using RA, the client can 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.
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://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)).
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.
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.
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.
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.
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.
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.
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).
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 ?
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.
From Brian Carpenter. For further discussion.
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.
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.
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.).
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.
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 ?
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC1149] | Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990. |