One document matched: draft-yourtchenko-ra-dhcpv6-comparison-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1149 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1149.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="2"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space: 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc  category="info" docName="draft-yourtchenko-ra-dhcpv6-comparison-00" ipr="trust200902">
  <front>
    <title abbrev="RA and DHCPv6 comparison">A comparison between the DHCPv6  and RA based host configuration</title>
    <author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
      <organization>cisco</organization>
      <address>
        <postal>
      <street>7a de Kleetlaan</street>
      <city>Diegem</city>
<!-- <region/> -->
      <code>1830</code>
      <country>Belgium</country>
        </postal>
      <phone>+32 2 704 5494</phone>
<!-- <facsimile/> -->
      <email>ayourtch@cisco.com</email>
<!-- <uri/> -->
      </address>
    </author>
    <date year="2013" />
<!-- <area/> -->
<!-- <workgroup/> -->
      <keyword>ra, dhcpv6</keyword>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
    <abstract>
      <t>
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.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
IPv4 provided only one way of configuring the addresses and node parameters: DHCP. Having no choice made the choice simple.
      </t>
      <t>
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.
      </t>
      <t>
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.
      </t>
      <t>
        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
        <xref target="RFC2119"/>.
      </t>
    </section>
    <section anchor="Comparison" title="Comparison">
      <section anchor="L2TopologyInterworking" title="Interworking with different L2 topologies">
        <t>
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).
        </t>
        <t>
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.
        </t>
        <t>
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.
        </t>
        <t>
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.
        </t>
      </section>
      <section anchor="AckNoAck" title="Acknowledged vs. Unacknowledged">
        <t>
DHCPv6 needs at least 2 packets. RA is just one packet.
	</t>
	<t>
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.
	</t>
	<t>
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. 
        </t>
	<t>
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.
        </t>
      </section>
      <section anchor="ClientOrServerInitiated" title="Client initiated vs. server initiated">
        <t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
        </t>
      </section>
      <section anchor="CentralCoordVsDistrib" title="Centralized coordination vs. distributed coordination">
        <t>
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).
	</t>
	<t>
DHCPv6 on the other hand, due to its p2p nature is by default well suited 
for the individual per-client tweaking.
	</t>
	<t>
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.
	</t>
	<t>
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).
	</t>
	<t>
That's why the title of this section does not use the word "control" but rather uses the word "coordination".
        </t>
      </section>
      <section anchor="SingleSourceOfTruth" title="Single Source of Truth vs. Multiple sources">
	<t>
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.
	</t>
	<t>
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. 
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
      </section>
      <section anchor="ServerSideState" title="The amount of server-side state">
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
FIXME: Further experimentation needed to test how it actually works in real life implementations.
        </t>
	<t>
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)).

	</t>
      </section>
      <section anchor="Routing" title="Involvement or not into routing">
          <section anchor="Routing1" title="Comparison">
	<t>
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.
	</t>
        <t>
RAs as a mechanism, due to its "multiple sources of truth" nature, 
can allow unsophisticated form of routing resiliency for the hosts.
	</t>
	<t>
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. 
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
FIXME: This section needs further debates, clarifications, and a rewrite. Discussion welcome.
	</t>
	  </section>
          <section anchor="RoutingDiscussion1" title="Discussion 1: On multiple default gateways per segment">
	<t>
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).
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
 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.

	</t>
	<t>
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)
	</t>
	<t>
 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. 
	</t>

	  </section>
          <section anchor="RoutingDiscussion2" title="Discussion 2: Why require an RA if DHCPv6 is more appropriate ?">
	<t>
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 ?  
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	<t>
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.
	</t>
	  </section> <!-- Discussion about routing -->
      </section>
      <section anchor="ServerLocality" title="Server locality">
        <t>
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.
        </t>
      </section>
      <section anchor="Programming" title="Programming: UDP vs. ICMP">
        <t>
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.
        </t>
        <t>
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.
        </t>
	<t>
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.
	</t>
      </section>
      <section anchor="Management" title="Separate vs. unified management">
        <t>
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. 
	</t>
	<t>
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.
        </t>
      </section>
      <section anchor="ScopeOfUse" title="Scope of use / Applicability">
	<t>
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:
	</t>
	<t>
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).
	</t>
	<t>
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.
	</t>
	<t>
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 ? 
	</t>
      </section>
      <section anchor="AddrManagement" title="IPAM tools impact comparison">
	<t>
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.
	</t>
	<t>
This said, until very recently DHCPv6 replaced the MAC address with DUID - which created its own set of challenges.
	</t>
      </section>
      <section anchor="SecurityTools" title="Security tools impact comparison">
	<t>
From Brian Carpenter. For further discussion.
	</t>
      </section>
    </section>
    <section anchor="SingleProtocolArguments" title="Arguments for running only a single protocol">
      <t>
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.
      </t>
      <section anchor="Complexity" title="Support and Security Complexity">
	<t>
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.
	</t>
	<t>
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.
	</t>
      </section>
    </section>
    <section anchor="NetworkManagerDifferences" title="Differences between different types of network operators">
      <t>
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.).
      </t>
    </section>
    <section anchor="Conclusion" title="Conclusion">
	<t>
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.
        </t>
	<t>
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.
        </t>
	<t>
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.
	</t>

    </section>
    <section anchor="FurtherProtocolDevelopment" title="Musings on further protocol directions in IETF">
	<t>
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 ?
	</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
        <t>
Thanks to Ted Lemon for triggering the creation of this document.
        </t>
        <t>
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.
        </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
        <t>
        </t>
        <t>
        </t>
    </section>
    <section anchor="Security" title="Security Considerations">
        <t>
        </t>
        <t>
        </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;
    </references>
    <references title="Informative References">
      &RFC1149;
    </references>
  </back>
</rfc>