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]