dhc                                                        J. Brzozowski
Internet-Draft                              Comcast Cable Communications
Intended status: BCP                                         J. Tremblay
Expires: May 12, 2010                                     Videotron Ltd.
                                                                 J. Chen
                                                       Time Warner Cable
                                                            T. Mrugalski
                                         Gdansk University of Technology
                                                        November 8, 2009


              DHCPv6 Redundancy Deployment Considerations
              draft-jjmb-dhc-dhcpv6-redundancy-consider-00

Abstract

   This document documents some deployment considerations for those who
   wishing to use DHCPv6 to support their deployment of IPv6.
   Specifically, providing semi-redundant DHCPv6 services is discussed
   in this document.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 12, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Brzozowski, et al.        Expires May 12, 2010                  [Page 1]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope and Assumptions  . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Service provider model . . . . . . . . . . . . . . . . . .  4
     2.2.  Enterprise model . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol requirements  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  DHCPv6 Relays  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Deployment models  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Split Prefixes . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Multiple Unique Prefixes . . . . . . . . . . . . . . . . .  8
     4.3.  Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
   5.  Challenges and Issues  . . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15


















Brzozowski, et al.        Expires May 12, 2010                  [Page 2]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


1.  Introduction

   To support the deployment of IPv6 redundancy and high availability
   are required for many if not all components.  This document provides
   information specific to the proposed near term approach for deploying
   semi-redundant DHCPv6 services in advance of DHCPv6 server
   implementations that support a standards based failover or redundancy
   protocol.


2.  Scope and Assumptions

   This document specifies an interim architecture to provide a semi-
   redundant DHCPv6 solution before the availability of vendor or
   standard based solutions.  The proposed architecture may be used in
   wide range of networks, two notable deployment models are discussed:
   service provider and enterprise network environments.  The described
   architecture leverages only existing and implemented DHCPv6
   standards.  This document does not address a standards based solution
   for DHCPv6 redundancy.  In the absence of a standards based DHCPv6
   redundancy protocol and implementation, some analogies are loosely
   drawn with the DHCPv4 failover protocol for reference.  Specific
   discussions related to DHCPv4 failover and redundancy is out of scope
   for this document.

   Although DHCPv6 redundancy may be useful in a wide range of
   scenarios, they may be generalized for illustration purposes in the
   two aforementioned.  The following assumptions were made with regards
   to the existing DHCPv6 infrastructure, regardless of the model used:

   1.  At least two DHCPv6 servers are used to service to the same
       clients, but the number of servers is not restricted.

   2.  Existing DHCPv6 servers will not directly communicate or interact
       with one another in the assignment of IPv6 addresses and
       configuration information to requesting clients.

   3.  DHCPv6 clients are instructed to run stateful DHCPv6 to request
       at least one IPv6 address.  Configuration information and other
       options like a delegated IPv6 prefix may be also requested.

   4.  Clients requesting IPv6 addresses, prefixes, and or options care
       of DHCPv6 must recognize and honor the DHCPv6 preference option.
       Furthermore, the requesting clients must process DHCPv6 ADVERTISE
       messages per [RFC3315] when the preference option is present.

   5.  DHCPv6 server failure does not imply failure of any other network
       service or protocol, e.g.  TFTP servers.  Redundancy of any



Brzozowski, et al.        Expires May 12, 2010                  [Page 3]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


       additional services configured by means of DHCPv6 are outside of
       scope of this document.  For example, a single DHCPv6 server may
       configure multiple TFTP servers, with preference for each TFTP
       server, as specified in [NETBOOT].

2.1.  Service provider model

   The service provider model represents cases, where end-user devices
   may be configured directly, without any intermediate devices (like
   home routers used in service provider model).  DHCPv6 clients include
   cable modems, customer gateways or home routers, and end-user
   devices.  In some cases hosts may be configured directly using the
   service provider DHCPv6 infrastructure or via intermediate router,
   that is in turn being configured by the provider DHCPv6
   infrastructure.  The service provider DHCPv6 infrastructure may be
   semi-redundant in either case.  Cable modems, customer gateways or
   home routers, and end-user devices are commonly referred to as CPE
   (Customer Premises Equipment).  The following additional assumptions
   were made, besides the ones made in Section 2:

   1.  The service provider edge routers and access routers (CMTS for
       cable or DSLAM/BRAS for DSL for example) are IPv6 enabled when
       required.

   2.  CPE devices are instructed to perform stateful DHCPv6 to request
       atleast one IPv6 address, delegated prefix, and or configuration
       information.  CPE devices may also be instructed to leverage
       stateless DHCPv6 [RFC3736] to acquire configuration information
       only.  This assumes that IPv6 address and prefix information has
       been acquired using other means.

   3.  The primary application of this BCP is for native IPv6 services.
       Use and applicability to transition mechanisms is out of scope
       for this document.

   4.  CPE devices must implement a stateful DHCPv6 client [RFC3315],
       support for DHCPv6 prefix delegation [RFC3633] or stateless
       DHCPv6 [RFC3736] may also be implemented.

2.2.  Enterprise model

   The enterprise model represents cases, where end-user devices are
   most often configured directly, without any intermediate devices
   (like home routers used in service provider model).  However,
   enterprise IPv6 environments quite often use or require that DHCPv6
   relay agents are in place to support the use of DHCPv6 for the
   acquisition of IPv6 addresses and or configuration information.  The
   assumptions here extend those that are defined in the beginning of



Brzozowski, et al.        Expires May 12, 2010                  [Page 4]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   Section 2:

   1.  DHCPv6 clients are hosts and are considered end nodes.  Examples
       of such clients include computers, laptops, and possibily mobile
       devices.

   2.  DHCPv6 clients generally do not require the assignment of an IPv6
       prefix delegation and as such do not support DHCPv6 prefix
       delegation[RFC3633].


3.  Protocol requirements

   The following sections outline the requirements that must be
   satisfied by DHCPv6 clients, relays, and servers to ensure the
   desired behavior is provided using pre-existing DHCPv6 server
   implementations as is.  The objective is to provide a semi-redundant
   DHCPv6 service to support the deployment of IPv6 where DHCPv6 is
   required for the assignment of IPv6 addresses, prefixes, and or
   configuration information.

3.1.  DHCPv6 Servers

   This interim architecture requires DHCPv6 servers that are RFC 3315
   [RFC3315] compliant and support the necessary options required to
   support this solution.  Essential to the the use of the interim
   architecture is support for stateful DHCPv6 and the DHCPv6 preference
   option both which are specified in RFC 3315 [RFC3315].  For
   deployment scenarios where IPv6 prefix delegation is employed DHCPv6
   servers must support DHCPv6 prefix delegation as defined by
   [RFC3633].  Further, where stateless DHCPv6 is used support for
   [RFC3736] is required by DHCPv6 servers.

3.2.  DHCPv6 Relays

   There are no specific requirements regarding relays.  However, it is
   implied that DHCPv6 relay agents must be RFC 3315 [RFC3315] compliant
   and must support the ability to relay DHCPv6 messages to more than
   one destination minimally.

3.3.  DHCPv6 Clients

   DHCPv6 clients are required to be compliant to RFC 3315 [RFC3315] and
   support the necessary options required to support this solution
   depending on the mode of operations and desired behavior.  Where
   prefix delegation is required DHCPv6 clients will be required to
   support DHCPv6 prefix delegation as defined in [RFC3633].  Clients
   used with this semi-redundant DHCPv6 deployment model must support



Brzozowski, et al.        Expires May 12, 2010                  [Page 5]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   the acquistion of at least one IPv6 address and configuration
   information using stateful DHCPv6 as specified by RFC 3315 [RFC3315].
   The use of stateless DHCPv6 which is also specified in RFC 3315
   [RFC3315] may also be supported.  DHCPv6 client must recognize and
   adhere to the processing of the advertised DHCPv6 preference options
   sent by the DHCPv6 servers.


4.  Deployment models

   At the time of this writing a standards-based DHCPv6 redundancy
   protocol and implementations are not available.  As a result DHCPv6
   server implementations will be used as-is to provide best effort,
   semi-redundant DHCPv6 services.  Behavior of the DHCPv6 services will
   in part be governed by the configuration used by each of the servers.
   Additionally, various aspects of the DHCPv6 protocol [RFC3315] will
   be leveraged to yield the desired behavior.  No inter-server or
   inter-process communications will be used to coordinate DHCPv6 events
   and or activities.  DHCP services for both IPv4 and IPv6 may operate
   simultaneously on the same physical server(s) or may operate on
   different ones.

4.1.  Split Prefixes

   In the split prefixes model, each DHCPv6 server is configured with a
   unique, non-overlapping range derived from the /64 prefix deployed
   for use within an IPv6 network.  Distribution between two servers,
   for example, would require that an allocated /64 be split in two /65
   ranges. 2001:db8:1:0001:0000::/65 and 2001:db8:1:0001:8000::/65 would
   be assigned to each DHCPv6 server for allocation to clients derived
   from 2001:db8:1:0001::/64 prefix.

   Each DHCP server allocates IPv6 addresses from the corresponding
   ranges per device class.  Each DHCPv6 server will be simultaneously
   active and operational.  Address allocation is governed largely
   through the use of the DHCPv6 preference option, so server with
   higher preference value is always prefered.  Additional proprietary
   mechanisms can be leveraged to further enforce the favoring of one
   DHCP server over another.

   It is important to note that over time, it is possible that bindings
   may be disproportionally distributed amongst DHCPv6 servers and not
   any one server will be authoritative for all bindings.  Per
   [RFC3315], a DHCPv6 ADVERTISE messages with a preference option of
   255 is an indicator to a DHCPv6 client to immediately begin a client-
   initiated message exchange by transmitting a REQUEST message.
   Alternatively, a DHCPv6 ADVERTISE messages with a preference option
   of any value lesser than 255 or is absent is an indicator to the



Brzozowski, et al.        Expires May 12, 2010                  [Page 6]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   client that it must wait for subsequent ADVERTISE messages (for a
   specified period of time) before proceeding.  Additionally, in the
   event of a DHCPv6 server failure it is desirable for a server other
   than the server that originally responded to be able to rebind the
   client.  It is not critical, that the DHCPv6 server be able to rebind
   the client in this scenario, however, this is generally desirable
   behavior.  Given the proposed architecture, the remaining active
   DHCPv6 server will have a different range configured making it
   technically incorrect for the same to rebind the client in its
   current state.  Ultimately, when rebinding fails the client will
   acquire a new binding from the configured range unique to an active
   server.  Furthermore, shorter T1, T2, valid, and preferred lifetimes
   can be used to reduce the possibility that a client or some other
   element on the network will experience a disruption in service or
   access to relevant binding data.  The values used for T2, preferred
   and valid lifetime can be adjusted or configured to minimize service
   disruption.  Ideally T2, preferred and valid lifetimes that are equal
   or near equal can be used to trigger a DHCPv6 client to reacquire
   IPv6 address, prefix, and or configuration information almost
   immediately after rebinding fails.  It is important to note that
   shorter values will most certainly create additional load and
   processing for the DHCPv6 server, which must be considered.

   Using a split prefix configuration model dynamic updates to DNS can
   be coordinated to ensure that the DNS is properly updated with
   current binding information.  Challenges arise with regards to the
   update of PTR for IPv6 addresses since the DNS may need to be
   overwritten in a failure condition.  The use of a split prefixes
   enables the differentiation of bindings and binding timing to
   determine which represents the current state.  This becomes
   particularly important when DHCPv6 Leasequery [RFC5007] and or DHCPv6
   Bulk Leasequery [RFC5460] are leveraged to determine lease or binding
   state.  An additional benefit is that the use of separate ranges per
   DHCPv6 server makes failure conditions more obvious and detectable.

















Brzozowski, et al.        Expires May 12, 2010                  [Page 7]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


     +----------+                 +-----------+
     | Client 1 +-\            +--+ Server 1  |
     +----------+  \           |  +-----------+
                    \          |
                     \         |
                      \        |
     +----------+      \       |  +-----------+
     | Client 2 +--------------+--| Server 2  |
     +----------+      /       |  +-----------+
           .          /        .
           .         /         .
           .        /          .
     +----------+  /           .  +-----------+
     | Client N +-/            .--| n+1 Server|
     +----------+                 +-----------+

     Server 1
     ========
     Prefix=2001:db8:abcd:0000::/64
     Range=2001:db8:abcd:5678:0000:/65
     Preference=255

     Server 2
     ========
     Prefix=2001:db8:abcd:0000::/64
     Range=2001:db8:abcd:5678:8000:/65
     Preference=0

     Server n+1
     ==========
     Prefix, range, and preference would vary based on range definition


                           Split prefix approach

                                 Figure 1

4.2.  Multiple Unique Prefixes

   In multiple prefix model, each DHCPv6 server is configured with a
   unique, non-overlapping range derived from multiple unique prefixes
   deployed for use within an IPv6 network.  Distribution between two
   servers, for example, would require that a /64 range be configured
   from an allocated from unique /64 prefixes.  For example, the range
   2001:db8:1:0001:0000::/64 would be assigned to a single DHCPv6 server
   for allocation to clients derived from 2001:db8:1:0001::/64 prefix,
   subsequently the 2001:db8:1:0001:1000::/64 from the prefix 2001:db8:
   1:0001:1000::/64 could be used by a second DHCP server.  This would



Brzozowski, et al.        Expires May 12, 2010                  [Page 8]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   be repeated for each active DHCP server.

   This approach uses a unique prefix and ultimately range per DHCPv6
   server with corresponding prefixes configured for use in the network.
   The corresponding network infrastructure must in turn be configured
   to use multiple prefixes on the inteface(s) facing the DHCPv6 client.
   The configuration is similar on all the servers, but a different
   prefix and a different preference is used per DHCPv6 server.

   This approach would drastically increase the rate of consumption of
   IPv6 prefixes and would also yield operational and management
   challenges related to the underlying network since a significantly
   higher number of prefixes would need to be configured and routed.
   This approach also does not provide a clean migration path to the
   desired solution leveraging a standards-based DHCPv6 redundancy or
   failover protocol, which of course has yet to be specified.

   The use of multiple unique prefixes provides benefits similar to
   those referred to in Section 4.1 related to dynamic updates to DNS.
   The use of multiple unique prefixes enables the differentiation of
   bindings and binding timing to determine which represents the current
   state.  This becomes particularly important when DHCPv6 Leasequery
   [RFC5007] and or DHCPv6 Bulk Leasequery [RFC5460] are leveraged to
   determine lease or binding state.  The use of separate prefixes and
   ranges per DHCPv6 server makes failure conditions more obvious and
   detectable.

























Brzozowski, et al.        Expires May 12, 2010                  [Page 9]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


                 +----------+                 +-----------+
                 | Client 1 +-\            +--+ Server 1  |
                 +----------+  \           |  +-----------+
                                \          |
                                 \         |
                                  \        |
                 +----------+      \       |  +-----------+
                 | Client 2 +--------------+--| Server 2  |
                 +----------+      /       |  +-----------+
                       .          /        .
                       .         /         .
                       .        /          .
                 +----------+  /           .  +-----------+
                 | Client N +-/            .--| n+1 Server|
                 +----------+                 +-----------+

                 Server 1
                 ========
                 Prefix=2001:db8:abcd:0000::/64
                 Range=2001:db8:abcd:0000::/64
                 Preference=255

                 Server 2
                 ========
                 Prefix=2001:db8:abcd:1000::/64
                 Range=2001:db8:abcd:1000::/64
                 Preference=0

                 Server 3
                 ========
                 Prefix=2001:db8:abcd:2000::/64
                 Range=2001:db8:abcd:2000::/64
                 Preference=(>0 and <255)


                      Multiple unique prefix approach

                                 Figure 2

4.3.  Identical Prefixes

   In the identical prefix model, each DHCPv6 server is configured with
   the same overlapping prefix and range deployed for use within an IPv6
   network.  Distribution between two or more servers, for example,
   would require that the same /64 prefix and range be configured on all
   DHCP servers.  For example, the range 2001:db8:1:0001:0000::/64 would
   be assigned to all DHCPv6 server for allocation to clients derived
   from 2001:db8:1:0001::/64 prefix.  This would be repeated for each



Brzozowski, et al.        Expires May 12, 2010                 [Page 10]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   active DHCP server.

   This approach uses the same prefix, length, and range definition
   across multiple DHCPv6 servers.  All other configuration remaining
   the same the only other attribute of configuration option configured
   differently per DHCPv6 server would be DHCPv6 preference.  This
   approach conceivably eases the migration of DHCPv6 services to fully
   support a standards based redundancy or failover protocol.  Similar
   to the split prefix architecture described above this approach does
   not place any additional addressing requirements on network
   infrastructure.

   The use of identical prefixes provides no benefit or advantage
   related to dynamic DNS updates, support of DHCPv6 Leasequery
   [RFC5007] and or DHCPv6 Bulk Leasequery [RFC5460].  In this case all
   DHCP servers will use the same prefix and range configurations making
   it less obvious that a failure condition or event has occurred.


































Brzozowski, et al.        Expires May 12, 2010                 [Page 11]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


                 +----------+                 +-----------+
                 | Client 1 +-\            +--+ Server 1  |
                 +----------+  \           |  +-----------+
                                \          |
                                 \         |
                                  \        |
                 +----------+      \       |  +-----------+
                 | Client 2 +--------------+--| Server 2  |
                 +----------+      /       |  +-----------+
                       .          /        .
                       .         /         .
                       .        /          .
                 +----------+  /           .  +-----------+
                 | Client N +-/            .--| n+1 Server|
                 +----------+                 +-----------+

                 Server 1
                 ========
                 Prefix=2001:db8:abcd:0000::/64
                 Range=2001:db8:abcd:0000::/64
                 Preference=255

                 Server 2
                 ========
                 Prefix=2001:db8:abcd:0000::/64
                 Range=2001:db8:abcd:0000::/64
                 Preference=0

                 Server 3
                 ========
                 Prefix=2001:db8:abcd:0000::/64
                 Range=2001:db8:abcd:0000::/64
                 Preference=(>0 and <255)


                         Identical prefix approach

                                 Figure 3


5.  Challenges and Issues

   The lack of interaction between DHCPv6 servers introduces a number of
   challenges related to the operations of the same in a production
   environment.  The following areas of are particular concern.






Brzozowski, et al.        Expires May 12, 2010                 [Page 12]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   o  Interactions with DNS server(s) to support the dynamic update of
      the same adress and prefix when one or more DHCPv6 servers have
      become unavailable.  This specifically becomes a challenge when or
      if nodes that were initially granted a lease:

      1.  Attempt to renew or rebind the lease originally granted, or

      2.  Attempt to obtain a new lease

      In either of the cases cited above, safeguards leveraged to
      prevent the deliberate or inadvertent overwriting of DNS data will
      likely prevent the responding DHCPv6 server from properly updating
      DNS with the client's new information and or may result in stale
      data in DNS.  Possible solutions include the following:

      *  The ability to configure the override and or disabling of the
         safeguards that prevent the over-writing of DNS data care of
         RFC2136, specifically, related to RFC4701 [RFC4701] and RFC4703
         [RFC4703].  This behavior must specifically be supported by the
         DHCPv6 server.  This will allow for the overwriting of existing
         RRs in DNS that represent the former binding for the client.
         As a result clients will not have multiple RRs in DNS for a
         client's FQDN-to-IPv6 address mapping.  Conversely, RR's for a
         client's IPv6 address-to-FQDN mapping will not be actively
         overwritten or deleted.  Stale reverse zone data will be purged
         using well known DNS constructs, including but not limited to
         leveraging TTLs.  Access control on the DNS server must be
         leveraged to restrict which DHCP servers may update DNS.

   o  Interactions with DHCPv6 servers to facilitate the acquisition of
      IPv6 lease data care of the DHCPv6 Leasequery [RFC5007] or DHCPv6
      Bulk Leasequery [RFC5460] protocols when one or more DHCPv6
      servers have become unavailable and have granted leases to DHCPv6
      clients.  If IPv6 lease data is required and the granting server
      is unavailable it will not be possible to obtain any information
      about leases granted until one of the following has taken place.
      It is important to note that with DHCPv6 until such time that a
      redundancy or failover protocol is available binding updates and
      synchronization will not occur between DHCPv6 servers.

      1.  The granting DHCPv6 server becomes available with all lease
          information restored

      2.  The client has renewed or rebound its lease against a
          different DHCPv6 server






Brzozowski, et al.        Expires May 12, 2010                 [Page 13]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


6.  IANA Considerations

   IANA is not requested to assign any numbers at this time.


7.  Security Considerations

   Security considerations specific to the operation of the DHCPv6
   protocol are created through the use of this interim architecture for
   DHCPv6 redundancy beyond what has been cited for Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) [RFC3315].  There are
   considerations related to DNS, specifically the dynamic updating of
   DNS, when such models are employed.  Potential opportunities are
   created to overwrite valid DNS resource records when provisions have
   been made accommodate some of the models cited in this document.  In
   some cases this is desirable to ensure that DNS remains up to date
   when using one or more of these models, however, abuse of the same
   could result in undesirable behavior.


8.  Acknowledgements

   Many thanks to Bernie Volz, Kim Kinnear, and Ralph Droms for their
   input and review.


9.  References

9.1.  Normative References

   [NETBOOT]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
              option for network boot", August 2009.

   [RFC2462]  Thompson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", December 1998.

   [RFC3315]  Droms, R., Ed., "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6",
              December 2003.

   [RFC3736]  "Stateless Dynamic Host Configuration Protocol (DHCP)
              Service for IPv6", April 2004.

   [RFC4701]  Stapp, M. and R. Droms, "Resolution of Fully Qualified
              Domain Name (FQDN) Conflicts among Dynamic Host



Brzozowski, et al.        Expires May 12, 2010                 [Page 14]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


              Configuration Protocol (DHCP) Clients", October 2006.

   [RFC4703]  Stapp, M. and R. Droms, "Resolution of Fully Qualified
              Domain Name (FQDN) Conflicts among Dynamic Host
              Configuration Protocol (DHCP) Clients", October 2006.

   [RFC5007]  "DHCPv6 Leasequery", April 2004.

   [RFC5460]  "DHCPv6 Bulk Leasequery", April 2004.

9.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.


Authors' Addresses

   John Jason Brzozowski
   Comcast Cable Communications
   1306 Goshen Parkway
   West Chester, PA  19380
   USA

   Phone: +1-609-377-6594
   Email: john_brzozowski@cable.comcast.com


   Jean-Francois Tremblay
   Videotron Ltd.
   612 Saint-Jacques
   Montreal, Quebec  H3C 4M8i
   Canada

   Phone:
   Email: Jean-Francois.TremblayING@videotron.com











Brzozowski, et al.        Expires May 12, 2010                 [Page 15]


Internet-Draft      DHCPv6 Redundancy Considerations       November 2009


   Jack Chen
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   USA

   Phone:
   Email: jack.chen@twcable.com


   Tomasz Mrugalski
   Gdansk University of Technology
   Storczykowa 22B/12
   Gdansk,
   Poland

   Phone: +48 698 088 272
   Email: tomasz.mrugalski@eti.pg.gda.pl

































Brzozowski, et al.        Expires May 12, 2010                 [Page 16]