Dynamic Host Configuration (DHC)                           J. Brzozowski
Internet-Draft                              Comcast Cable Communications
Intended status: BCP Informational                               J. Tremblay
Expires: May 3, 2012 March 11, 2013                                   Videotron Ltd.
                                                                 J. Chen
                                                       Time Warner Cable
                                                            T. Mrugalski
                                                                     ISC
                                                        October 31, 2011
                                                       September 7, 2012

              DHCPv6 Redundancy Deployment Considerations
              draft-ietf-dhc-dhcpv6-redundancy-consider-02
              draft-ietf-dhc-dhcpv6-redundancy-consider-03

Abstract

   This document documents some deployment considerations provides information for those who wishing to use DHCPv6 to
   support their deployment of IPv6.
   Specifically, providing  In particular, it discusses the
   provision of semi-redundant DHCPv6 services is discussed
   in this document. services.

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 3, 2012. March 11, 2013.

Copyright Notice

   Copyright (c) 2011 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope and Assumptions  . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Service provider model  Applicability to Prefix Delegation . . . . . . . . . . . .  4
   3.  Service Provider Deployment  . . . . . . . . . . . . . . . . .  4
     2.2.
   4.  Enterprise model . Deployment  . . . . . . . . . . . . . . . . . . . .  5
   3.
   5.  Protocol requirements Requirements  . . . . . . . . . . . . . . . . . . . .  5
     3.1.
     5.1.  DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.
     5.2.  DHCPv6 Relays  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.
     5.3.  DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . .  6
   4.
   6.  Deployment models Models  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.
     6.1.  Split Prefixes . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.
     6.2.  Multiple Unique Prefixes . . . . . . . . . . . . . . . . .  8
     4.3.  9
     6.3.  Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
   5.
   7.  Challenges and Issues  . . . . . . . . . . . . . . . . . . . . 12
   6.
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1. 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2. 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 16

1.  Introduction

   To support the deployment of IPv6 redundancy

   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 components of IPv6
   infrastructure are desirable and, in some deployments, mandatory.
   Unfortunately, for DHCPv6 server
   implementations that support a standards based there is currently no standards-based
   failover or redundancy protocol.

2.  Scope and Assumptions

   This  An interim solution is to provide
   semi-redundant services: this document specifies an interim architecture to provide a semi-
   redundant by
   which this can be achieved.

2.  Scope and Assumptions

   DHCPv6 solution before the availability redundancy may be useful in a wide range of vendor or
   standard based solutions.  The proposed scenarios.
   Although the architecture may suggested in this document is able to be
   used in a wide range of networks, just two notable deployment models environments
   are discussed: discussed here: 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. network.  All
   other scenarios may be generalized to one of these two cases.

   In the absence rest 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.  Reader interested in initial work being done in
   DHCPv6 failover is recommended to read
   [I-D.mrugalski-dhc-dhcpv6-failover-requirements].

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

   1.  At least two DHCPv6 servers are used to provide a service to the same
       clients, but
       clients.  (The architecture does not limit the number of servers is not restricted. servers,
       and more may be provided if required.)

   2.  Existing  The existing DHCPv6 servers will not directly communicate or
       interact with one another in the assignment of IPv6 addresses and
       provision of 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 (such as a delegated IPv6 prefix prefix) may be also requested. be requested
       as part of the stateful DHCPv6 operation.

   4.  Clients requesting IPv6 addresses, prefixes, and or options care
       of participating in DHCPv6 must recognize and honor configuration have to properly
       handle the DHCPv6 preference option.
       Furthermore, option, including the requesting clients must process DHCPv6 processing of
       ADVERTISE
       messages per [RFC3315] when the preference option is present. messages, as required by [RFC3315].

   5.  A DHCPv6 server failure does not imply a failure of any other
       network service or protocol, e.g. protocol (e.g.  TFTP servers.  Redundancy servers).  The redundancy
       of any additional services configured by means of DHCPv6 are
       outside of the scope of this document.  For  (For example, a single
       DHCPv6 server may configure multiple TFTP servers, with
       preference for each TFTP server, as specified in [RFC5970]. [RFC5970].)

   While the techniques described in this document provide some aspects
   of redundancy, it should be noted that complete redundancy will not
   be available until a DHCPv6 failover protocol is standardized.  Initial work toward
   that goal is  The
   requirements for such protocol are described in
   [I-D.mrugalski-dhc-dhcpv6-failover-requirements].
   [I-D.ietf-dhc-dhcpv6-failover-requirements].

2.1.  Service provider  Applicability to Prefix Delegation

   The same approaches discussed in this document can potentially be
   applied to prefix delegation [RFC3633].  One obvious drawback of
   using split prefix model for PD is that use of resources is doubled.
   It should be noted that such applicability remains theoretical and
   was not investigated thoroughly during work on this document.  As
   such, the applicability of presented mechanisms to the prefix
   delegation is outside of scope of this document.

3.  Service Provider Deployment

   The service provider model represents cases, cases where the network and
   end-user devices may be configured directly, without any intermediate devices (like
   home routers used in service provider model). administered by separate entities.

   The DHCPv6 clients include cable modems, customer gateways or home
   routers, and end-user
   devices. devices: these are collectively referred to as
   Customer Premises Equipment (CPE).  In some cases hosts may be
   configured directly using the service provider DHCPv6 infrastructure or infrastructure;
   in others, configuration may be via an intermediate router,
   that router which is in turn
   being configured by the provider DHCPv6 infrastructure.  The  Either way,
   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 semi-redundant.

   In discussing this environment, additional assumptions
   were made, besides the ones made to those
   listed in Section 2: 2 have been made:

   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
       at least one IPv6 address, delegated prefix, and or and/or configuration
       information.  CPE devices may also be instructed to leverage use stateless
       DHCPv6 [RFC3736] to acquire configuration information
       only.  This assumes only, a
       situation that assumes the IPv6 address and prefix information
       has been acquired using other means.

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

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

2.2.

4.  Enterprise model Deployment

   The enterprise model represents deployment environment covers cases where end-user
   devices are most
   often configured directly direct consumers of the configuration without any
   intermediate devices (like (as was the case with home routers used in the
   service provider model).  However environment).  Although enterprise IPv6 environments
   quite often use or require that DHCPv6 relay agents are
   in place to support the use of DHCPv6 for agents, the acquisition of IPv6
   addresses and relays do not
   influence or process the configuration information. in any way and merely act as a
   transport mechanism.

   The additional assumptions here
   extend made for this model beyond those that are defined listed in the beginning of
   Section 2: 2 are:

   1.  DHCPv6 clients are hosts and are considered end nodes. nodes i.e. they
       consume provided configuration and not use it to provision other
       devices.  Examples of such clients include desktop computers,
       laptops, printers, other typical office equipment and possibily some mobile
       devices.

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

3.

5.  Protocol requirements

   The following sections outline Requirements

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

3.1. such devices.

5.1.  DHCPv6 Servers

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

3.2. is used.

5.2.  DHCPv6 Relays

   There are no specific requirements regarding relays.  However, it is
   implied that

   DHCPv6 relay agents must be [RFC3315] compliant and must support the
   ability to relay DHCPv6 messages to more than one
   destination minimally.

3.3. destination.

5.3.  DHCPv6 Clients

   DHCPv6 clients are required to be compliant to with [RFC3315] and
   support the necessary options required to support this the solution
   depending on the mode of operations and desired behavior.  Where behaviour:

   o  If prefix delegation is required required, DHCPv6 clients will be required to must support
      DHCPv6 prefix delegation as defined in [RFC3633].

   o  Clients used with this semi-
   redundant DHCPv6 deployment model must support the acquistion acquisition of at least one IPv6 address
      and configuration information using stateful DHCPv6 as specified
      by [RFC3315].  The use of stateless

   o  Stateless DHCPv6 which
   is also specified in [RFC3315] [RFC3736] may also be supported.

   o  DHCPv6 client clients must recognize and adhere to the processing of the
      advertised DHCPv6 preference options sent by the DHCPv6 servers.

4.

6.  Deployment models Models

   At the time of this writing writing, a standards-based DHCPv6 redundancy protocol and implementations are
   is not available.  As a result  In the interim solution presented here, existing
   DHCPv6 server implementations will be are used as-is to provide best effort,
   semi-redundant DHCPv6 services.  Behavior  The behavior of the DHCPv6 these services will will,
   in part part, be governed by the configuration used by of each of the servers.
   Additionally, various
   Various aspects of the DHCPv6 protocol [RFC3315] will
   be leveraged are used to yield
   the desired behavior.  No behaviour, although there is no inter-server or
   inter-process communications will be used inter-
   process communication to coordinate DHCPv6 events
   and or and/or activities.

   The solution does not impact on DHCPv4, so DHCP services for both
   IPv4 and IPv6 may operate simultaneously on the same physical
   server(s) or may operate on different ones.

4.1.

   This section defines three semi-redundant models.  Although /64
   prefixes are used throughout the following sections as examples,
   other prefix lengths may be used as well.

6.1.  Split Prefixes

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

   Both DHCPv6 server for allocation to clients derived
   from 2001:db8:1:0001::/64 prefix.

   Each DHCP server servers are simultaneously active and operational, and
   each allocates IPv6 addresses from the corresponding
   ranges pools per device
   class.  Each DHCPv6 server will be simultaneously
   active and operational.  Address  The address allocation is governed largely through the use of
   the DHCPv6 preference option, so the server with the higher
   preference value is always prefered. preferred.  Additional proprietary
   mechanisms can be leveraged used to further enforce the favoring favouring of one DHCP
   server over another.  Example  An example of such a scenario is presented in
   Figure 1.

   It is important to note that that, over time, it is possible that bindings
   may
   will be disproportionally unevenly distributed amongst the DHCPv6 servers and not
   any no one
   server will be authoritative for all bindings.

   Per of them.

   As defined in [RFC3315], a DHCPv6 ADVERTISE messages message 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. message
   to the server that sent the ADVERTISE.  Alternatively, a DHCPv6
   ADVERTISE messages message with a no preference option
   of any (or one with a value lesser less
   than 255 or absent preference option 255) is an indicator to the client that it must wait for
   subsequent ADVERTISE messages before proceeding, choosing the server to which is
   responds, as defined described in Section 17.1.2 of [RFC3315].  Additionally, in

   In the event of a DHCPv6 server failure it is desirable (but not
   essential) 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. client's lease.  Given the
   proposed architecture, the remaining active DHCPv6 server will have a
   different range configured address pool configured, making it technically incorrect
   for the same to rebind the client in its current state.  Ultimately, when
   the rebinding fails will fail and the client will acquire a new binding
   from the pool configured range unique to an in the active server.  Furthermore, shorter
   T1, T2, valid, and preferred lifetimes can be used to

   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 data, shorter values used for T1, T2, preferred valid, and valid lifetime preferred
   lifetimes can be used.  The values for the last three can be adjusted
   or configured to minimize service disruption.  Ideally T2,
   preferred and valid lifetimes that are equal or near  Ideally, setting them
   equal (or nealy equal) can be used to trigger a DHCPv6 client to
   reacquire the IPv6 address, prefix, and or configuration information
   almost immediately after the rebinding fails.  It is important to
   note however, that shorter values will most
   certainly create an additional load and processing for on
   the DHCPv6
   server, which must be considered.

   Using servers.

   While using a split prefix configuration model the dynamic updates to
   DNS [RFC2136] can be coordinated to ensure that the DNS is properly
   updated with the current binding information.  Challenges arise with
   regards to the update of the PTR resource record for IPv6 addresses
   since the DNS information 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 used
   to determine lease or binding
   state.  An additional state.

   Finally, a benefit of this scheme is that the use of separate ranges pools
   per DHCPv6 server makes failure conditions more obvious and
   detectable.

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

                 Server 1
                 ========
                 Prefix=2001:db8:1:0:0::/64
                 Range=2001:db8:1:0:0::/65
                 Preference=255
                 Prefix = 2001:db8:1:0:0::/64
                 Pool = 2001:db8:1:0:0::/65
                 Preference = 255

                 Server 2
                 ========
                 Prefix=2001:db8:1:0:0::/64
                 Range=2001:db8:1:0:8000::/65
                 Preference=0
                 Prefix = 2001:db8:1:0:0::/64
                 Pool = 2001:db8:1:0:8000::/65
                 Preference = 0

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

                         Split prefixes approach.

                                 Figure 1

4.2.

6.2.  Multiple Unique Prefixes

   In the multiple prefix model, each DHCPv6 server is configured with a
   unique, non-overlapping prefix.  A /64 range pool equal to the prefix is
   configured on each server.  For example, the range 2001:db8:1:
   0000::/64 2001:db8:1:0000::/64
   pool would be assigned to a single DHCPv6 server for allocation to
   clients equal to its parent prefix 2001:db8:1:0000::/64.
   Subsequently the  The second
   DHCPv6 server could use 2001:db8:1:0001:::/64 as range both pool and
   prefix.  This would be repeated for each active DHCP server.  Example  An
   example of this scenario is presented in Figure 2.

   The major difference between the split prefixes approach and the
   multiple unique prefixes one is that the latter does not require
   prefixes to be adjacent.  In fact, the split prefixes approach can be
   considered a special case of the multiple unique prefixes approach.

   This approach uses a unique prefix and ultimately range pool per DHCPv6
   server with the 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) interface(s) facing the
   DHCPv6 client. clients.  The configuration is similar on all the servers, but
   a different prefix and a different preference is used per for each DHCPv6
   server.

   This approach would drastically increase increases the rate of consumption of IPv6
   prefixes and would also yield yields 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  It also does not
   provide a clean migration path to the desired solution leveraging using a
   standards-based DHCPv6 redundancy or failover protocol, which protocol (which of course
   course, has yet to be specified. specified).

   The use of multiple unique prefixes provides benefits related to
   dynamic updates to DNS similar to those referred to in Section 4.1 related to dynamic updates to DNS. 6.1.
   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 used to
   determine lease or binding state.  The use of separate prefixes and
   ranges
   pools per DHCPv6 server makes failure conditions more obvious and
   detectable.

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

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

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

                 Server 3
                 ========
                 Prefix=2001:db8:1:2000::/64
                 Range=2001:db8:1:2000::/64
                 Preference=(>0 and <255)
                 Prefix = 2001:db8:1:2000::/64
                 Pool = 2001:db8:1:2000::/64
                 Preference = [0..255)

                     Multiple unique prefix approach.

                                 Figure 2

4.3.

6.3.  Identical Prefixes

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

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

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

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

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

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

                 Server 3
                 ========
                 Prefix=2001:db8:1:0000::/64
                 Range=2001:db8:1:0000::/64
                 Preference=(>0 and <255)
                 Prefix = 2001:db8:1:0000::/64
                 Pool = 2001:db8:1:0000::/64
                 Preference = [0..255)

                        Identical prefix approach.

                                 Figure 3

5.

7.  Challenges and Issues

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

   o  In indentical the identical prefixes scenario, both servers must follow the
      same address allocation procedure, i.e. they both must use the
      same algorithm and the same policy to determine which address is
      going to be assigned to a specific client.  Otherwise there is a
      distinct chance that each server will assign the same address to
      two different clients.  It is expected that both servers will
      receive each incoming REQUEST message.  Usually no special action
      is required to achieve this as REQUEST messages are sent to
      multicast address by directly connected clients.  Relays are
      expected to forward incoming client messages to all servers.  The
      client indicates chosen server by including its DUID in Server-ID
      option.  The chosen server assigns the address and other
      configuration options, while the other server discards the
      incoming request.  In case of a failure of one server, the other
      server will assign the same address by following the same
      algorithm and the same policy.

   o  Interactions with DNS server(s) to support the using dynamic update of for the same
      address when one or more DHCPv6 servers have become unavailable.
      This specifically becomes a challenge when or if (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

      The DHCID Resource Record, defined in [RFC4701], resource record [RFC4701] allows identification of the
      current owner for of the specific DNS data that can be used during
      DNS Update procedure is the target of an
      update [RFC2136].  [RFC4704] specifies how DHCPv6 servers and/or
      client may perform updates.  [RFC4703] provides a way how to solve
      conflicts between clients.  Although it the [RFC4703] deals with most
      cases, it is still possible to leave abandoned RR resource records.
      Consider the following scenario.  There scenario: there are two independent
      servers.
      servers, A and B. Server A assigns a lease to a client and updates
      the DNS with an AAAA record for the assigned address and name. address.  When the
      client renews, server A is not available and server B assigns a
      different lease.  The DNS is again updated (now updated, so now two AAAA RRs
      resource records are in the DNS present for the client).  Anyone trying to use the DNS information doesn't
      know client: there is no
      indication as which of the two leases is active.  And, if  If server A
      never recovers, its information may never be removed. removed (although it
      should be noted that this case is somewhat similar to that of a
      single server crashing and leaving abandoned resource records).

   o  Interactions with DHCPv6 servers to facilitate the acquisition of
      IPv6 lease data care by way 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. clients and later became
      unavailable.  If IPv6 the lease data is required and the granting
      server is unavailable unavailable, it will not be possible to obtain any
      information about leases granted until one of the following has
      taken place. place:

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

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

      It is important to note that with any exchange of available leases and
      synchronization between DHCPv6 servers is not possible until such time that a
      redundancy or failover protocol is available binding updates and
      synchronization will not occur between DHCPv6 servers.

6. standardized or proprietary
      solutions become available.

8.  IANA Considerations

   IANA is

   This document does not requested to assign require any numbers at this time.

7. actions from IANA.

9.  Security Considerations

   Security

   Additional 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 in Section 23 of
   [RFC3315].  In particular, Dynamic Host
   Configuration Protocol DNS update using the models
   defined in this document allows for IPv6 (DHCPv6) [RFC3315].  There are
   considerations related to DNS, specifically the dynamic updating possibility of
   DNS, when such models are employed.  Potential opportunities are
   created to overwrite valid not removing
   abandoned DNS resource records records, even when provisions have
   been made accommodate some of the models cited using conflict resolution mechanism
   defined in this document.  In
   some cases [RFC4703].  However, this is desirable no worse than a case where a
   single deployed server crashes and its lease database cannot be
   recovered.

   When using identical prefixes model, care must be taken to ensure
   that DNS remains up to date
   when using one or more all servers use the same lease allocation procedure and are
   configured with the same policy.  If this guidance is not followed,
   there is a risk of these models, however, abuse assignment of the same
   could result in undesirable behavior.

8. lease to two separate
   clients.  In some cases that situation can be recovered by using
   Duplicate Address Detection (Neighbor Discovery) and DECLINE
   mechanism (DHCPv6).

10.  Acknowledgements

   Many thanks

   Authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms,
   David Hankins
   and Hankins, Chuck Anderson Anderson, Ted Lemon, Stephen Farrel, Pete
   McCann, Robert Sparks, Martin Stiemerling, Brian Haberman and Barry
   Leiba for their input and review.

   Special thanks to Stephen Morris for his numerous spelling, grammar
   corrections and proof-reading.

   This work has been partially supported by Department of Computer
   Communications (a division of Gdansk University of Technology) and
   the Polish Ministry of Science and Higher Education under the
   European Regional Development Fund, Grant No.  POIG.01.01.02-00-045/
   09-00 (Future Internet Engineering Project).

9.

11.  References

9.1.

11.1.  Normative References

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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

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

   [RFC4701]  Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
              Record (RR) for Encoding Dynamic Host Configuration
              Protocol (DHCP) Information (DHCID RR)", RFC 4701,
              October 2006.

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

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, October 2006.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              February 2009.

   [RFC5970]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
              Options for Network Boot", RFC 5970, September 2010.

9.2.

11.2.  Informative References

   [I-D.mrugalski-dhc-dhcpv6-failover-requirements]

   [I-D.ietf-dhc-dhcpv6-failover-requirements]
              Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
              Requirements",
              draft-mrugalski-dhc-dhcpv6-failover-requirements-00
              draft-ietf-dhc-dhcpv6-failover-requirements-01 (work in
              progress), June 2011. July 2012.

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 4M8
   Canada

   Email: jf@jftremblay.com

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

   Email: jack.chen@twcable.com
   Tomasz Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter St.
   Redwood City, CA  94063
   USA

   Phone: +1 650 423 1345
   Email: tomasz.mrugalski@gmail.com