draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt   draft-ietf-dhc-dhcpv6-redundancy-consider-03.txt 
Dynamic Host Configuration (DHC) J. Brzozowski Dynamic Host Configuration (DHC) J. Brzozowski
Internet-Draft Comcast Cable Communications Internet-Draft Comcast Cable Communications
Intended status: BCP J. Tremblay Intended status: Informational J. Tremblay
Expires: May 3, 2012 Videotron Ltd. Expires: March 11, 2013 Videotron Ltd.
J. Chen J. Chen
Time Warner Cable Time Warner Cable
T. Mrugalski T. Mrugalski
ISC ISC
October 31, 2011 September 7, 2012
DHCPv6 Redundancy Deployment Considerations DHCPv6 Redundancy Deployment Considerations
draft-ietf-dhc-dhcpv6-redundancy-consider-02 draft-ietf-dhc-dhcpv6-redundancy-consider-03
Abstract Abstract
This document documents some deployment considerations for those who This document provides information for those wishing to use DHCPv6 to
wishing to use DHCPv6 to support their deployment of IPv6. support their deployment of IPv6. In particular, it discusses the
Specifically, providing semi-redundant DHCPv6 services is discussed provision of semi-redundant DHCPv6 services.
in this document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on March 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 3 2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 3
2.1. Service provider model . . . . . . . . . . . . . . . . . . 4 2.1. Applicability to Prefix Delegation . . . . . . . . . . . . 4
2.2. Enterprise model . . . . . . . . . . . . . . . . . . . . . 5 3. Service Provider Deployment . . . . . . . . . . . . . . . . . 4
3. Protocol requirements . . . . . . . . . . . . . . . . . . . . 5 4. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . 5
3.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5 5.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 6 5.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment models . . . . . . . . . . . . . . . . . . . . . . 6 5.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6 6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8 6.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10 6.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 9
5. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12 6.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
To support the deployment of IPv6 redundancy and high availability Redundancy and high availability for many components of IPv6
are required for many if not all components. This document provides infrastructure are desirable and, in some deployments, mandatory.
information specific to the proposed near term approach for deploying Unfortunately, for DHCPv6 there is currently no standards-based
semi-redundant DHCPv6 services in advance of DHCPv6 server failover or redundancy protocol. An interim solution is to provide
implementations that support a standards based failover or redundancy semi-redundant services: this document specifies an architecture by
protocol. which this can be achieved.
2. Scope and Assumptions 2. Scope and Assumptions
This document specifies an interim architecture to provide a semi- DHCPv6 redundancy may be useful in a wide range of scenarios.
redundant DHCPv6 solution before the availability of vendor or Although the architecture suggested in this document is able to be
standard based solutions. The proposed architecture may be used in used in a wide range of networks, just two deployment environments
wide range of networks, two notable deployment models are discussed: are discussed here: service provider and enterprise network. All
service provider and enterprise network environments. The described other scenarios may be generalized to one of these two cases.
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. 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 In the rest of the document, the following assumptions are made with
scenarios, they may be generalized for illustration purposes in the regards to the existing DHCPv6 infrastructure, regardless of the
two aforementioned. The following assumptions were made with regards environment being considered:
to the existing DHCPv6 infrastructure, regardless of the model used:
1. At least two DHCPv6 servers are used to service to the same 1. At least two DHCPv6 servers provide a service to the same
clients, but the number of servers is not restricted. clients. (The architecture does not limit the number of servers,
and more may be provided if required.)
2. Existing DHCPv6 servers will not directly communicate or interact 2. The existing DHCPv6 servers will not directly communicate or
with one another in the assignment of IPv6 addresses and interact with one another in the assignment of IPv6 addresses and
configuration information to requesting clients. provision of configuration information to requesting clients.
3. DHCPv6 clients are instructed to run stateful DHCPv6 to request 3. DHCPv6 clients are instructed to run stateful DHCPv6 to request
at least one IPv6 address. Configuration information and other at least one IPv6 address. Configuration information and other
options like a delegated IPv6 prefix may be also requested. options (such as a delegated IPv6 prefix) may also be requested
as part of the stateful DHCPv6 operation.
4. Clients requesting IPv6 addresses, prefixes, and or options care 4. Clients participating in DHCPv6 configuration have to properly
of DHCPv6 must recognize and honor the DHCPv6 preference option. handle the preference option, including the processing of
Furthermore, the requesting clients must process DHCPv6 ADVERTISE ADVERTISE messages, as required by [RFC3315].
messages per [RFC3315] when the preference option is present.
5. DHCPv6 server failure does not imply failure of any other network 5. A DHCPv6 server failure does not imply a failure of any other
service or protocol, e.g. TFTP servers. Redundancy of any network service or protocol (e.g. TFTP servers). The redundancy
additional services configured by means of DHCPv6 are outside of of any additional services configured by means of DHCPv6 are
scope of this document. For example, a single DHCPv6 server may outside the scope of this document. (For example, a single
configure multiple TFTP servers, with preference for each TFTP DHCPv6 server may configure multiple TFTP servers, with
server, as specified in [RFC5970]. preference for each TFTP server, as specified in [RFC5970].)
While techniques described in this document provide some aspects of While the techniques described in this document provide some aspects
redundancy, it should be noted that complete redundancy will not be of redundancy, it should be noted that complete redundancy will not
available until DHCPv6 protocol is standardized. Initial work toward be available until a DHCPv6 failover protocol is standardized. The
that goal is described in 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 model 2.1. Applicability to Prefix Delegation
The service provider model represents cases, where end-user devices The same approaches discussed in this document can potentially be
may be configured directly, without any intermediate devices (like applied to prefix delegation [RFC3633]. One obvious drawback of
home routers used in service provider model). DHCPv6 clients include using split prefix model for PD is that use of resources is doubled.
cable modems, customer gateways or home routers, and end-user It should be noted that such applicability remains theoretical and
devices. In some cases hosts may be configured directly using the was not investigated thoroughly during work on this document. As
service provider DHCPv6 infrastructure or via intermediate router, such, the applicability of presented mechanisms to the prefix
that is in turn being configured by the provider DHCPv6 delegation is outside of scope of this document.
infrastructure. The service provider DHCPv6 infrastructure may be
semi-redundant in either case. Cable modems, customer gateways or 3. Service Provider Deployment
home routers, and end-user devices are commonly referred to as CPE
(Customer Premises Equipment). The following additional assumptions The service provider model represents cases where the network and
were made, besides the ones made in Section 2: end-user devices may be administered by separate entities.
The DHCPv6 clients include cable modems, customer gateways or home
routers, and end-user 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;
in others, configuration may be via an intermediate router which is
being configured by the provider DHCPv6 infrastructure. Either way,
the service provider DHCPv6 infrastructure may be semi-redundant.
In discussing this environment, additional assumptions to those
listed in Section 2 have been made:
1. The service provider edge routers and access routers (CMTS for 1. The service provider edge routers and access routers (CMTS for
cable or DSLAM/BRAS for DSL for example) are IPv6 enabled when cable or DSLAM/BRAS for DSL for example) are IPv6 enabled when
required. required.
2. CPE devices are instructed to perform stateful DHCPv6 to request 2. CPE devices are instructed to perform stateful DHCPv6 to request
at least one IPv6 address, delegated prefix, and or configuration at least one IPv6 address, delegated prefix, and/or configuration
information. CPE devices may also be instructed to leverage information. CPE devices may also be instructed to use stateless
stateless DHCPv6 [RFC3736] to acquire configuration information DHCPv6 [RFC3736] to acquire configuration information only, a
only. This assumes that IPv6 address and prefix information has situation that assumes the IPv6 address and prefix information
been acquired using other means. has been acquired using other means.
3. The primary application of this BCP is for native IPv6 services. 3. The primary application of this architecture is for native IPv6
Use and applicability to transition mechanisms is out of scope services. (Use and applicability to transition mechanisms is out
for this document. of scope for this document.)
4. CPE devices must implement a stateful DHCPv6 client [RFC3315], 4. The CPE devices must implement a stateful DHCPv6 client
support for DHCPv6 prefix delegation [RFC3633] or stateless [RFC3315]. Support for DHCPv6 prefix delegation [RFC3633] or
DHCPv6 [RFC3736] may also be implemented. stateless DHCPv6 [RFC3736] may also be implemented.
2.2. Enterprise model 4. Enterprise Deployment
The enterprise model represents cases where end-user devices are most The enterprise deployment environment covers cases where end-user
often configured directly without any intermediate devices (like home devices are direct consumers of the configuration without any
routers used in service provider model). However enterprise IPv6 intermediate devices (as was the case with home routers used in the
environments quite often use or require that DHCPv6 relay agents are service provider environment). Although enterprise IPv6 environments
in place to support the use of DHCPv6 for the acquisition of IPv6 quite often use or require DHCPv6 relay agents, the relays do not
addresses and or configuration information. The assumptions here influence or process the configuration in any way and merely act as a
extend those that are defined in the beginning of Section 2: transport mechanism.
1. DHCPv6 clients are hosts and are considered end nodes. Examples The additional assumptions made for this model beyond those listed in
of such clients include computers, laptops, and possibily mobile Section 2 are:
1. DHCPv6 clients are hosts and are considered end 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 some mobile
devices. devices.
2. DHCPv6 clients generally do not require the assignment of an IPv6 2. The DHCPv6 clients generally do not require the assignment of an
prefix delegation and as such do not support DHCPv6 prefix IPv6 prefix delegation and as such they typically do not support
delegation [RFC3633]. DHCPv6 prefix delegation [RFC3633].
3. Protocol requirements 5. Protocol Requirements
The following sections outline the requirements that must be Implementation of the architecture for semi-redundant DHCPv6 services
satisfied by DHCPv6 clients, relays, and servers to ensure the using existing protocols places require the component DHCPv6 clients,
desired behavior is provided using pre-existing DHCPv6 server relays, and servers to have certain capabilities. The following
implementations as is. The objective is to provide a semi-redundant sections describe the requirements of such devices.
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 5.1. DHCPv6 Servers
This interim architecture requires DHCPv6 servers that are [RFC3315] This interim architecture requires the DHCPv6 servers that are
compliant and support the necessary options required to support this [RFC3315] compliant and support the necessary options. Essential to
solution. Essential to the the use of the interim architecture is the architecture is support for stateful DHCPv6 and the DHCPv6
support for stateful DHCPv6 and the DHCPv6 preference option both preference option [RFC3315]. For deployment scenarios where IPv6
which are specified in [RFC3315]. For deployment scenarios where prefix delegation is needed, DHCPv6 servers must support DHCPv6
IPv6 prefix delegation is employed DHCPv6 servers must support DHCPv6 prefix delegation as defined by [RFC3633]. Furthermore, the DHCPv6
prefix delegation as defined by [RFC3633]. Further, where stateless servers must support [RFC3736] if stateless DHCPv6 is used.
DHCPv6 is used support for [RFC3736] is required by DHCPv6 servers.
3.2. DHCPv6 Relays 5.2. DHCPv6 Relays
There are no specific requirements regarding relays. However, it is DHCPv6 relay agents must be [RFC3315] compliant and must support the
implied that DHCPv6 relay agents must be [RFC3315] compliant and must ability to relay DHCPv6 messages to more than one destination.
support the ability to relay DHCPv6 messages to more than one
destination minimally.
3.3. DHCPv6 Clients 5.3. DHCPv6 Clients
DHCPv6 clients are required to be compliant to [RFC3315] and support DHCPv6 clients are required to be compliant with [RFC3315] and
the necessary options required to support this solution depending on support the necessary options required to support the solution
the mode of operations and desired behavior. Where prefix delegation depending on the mode of operations and desired behaviour:
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 the acquistion of at
least one IPv6 address and configuration information using stateful
DHCPv6 as specified by [RFC3315]. The use of stateless DHCPv6 which
is also specified in [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 o If prefix delegation is required, DHCPv6 clients must support
DHCPv6 prefix delegation as defined in [RFC3633].
At the time of this writing a standards-based DHCPv6 redundancy o Clients must support the acquisition of at least one IPv6 address
protocol and implementations are not available. As a result DHCPv6 and configuration information using stateful DHCPv6 as specified
server implementations will be used as-is to provide best effort, by [RFC3315].
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 o Stateless DHCPv6 [RFC3736] may also be supported.
o DHCPv6 clients must recognize and adhere to the processing of the
advertised DHCPv6 preference options sent by the DHCPv6 servers.
6. Deployment Models
At the time of writing, a standards-based DHCPv6 redundancy protocol
is not available. In the interim solution presented here, existing
DHCPv6 server implementations are used as-is to provide best effort,
semi-redundant DHCPv6 services. The behavior of these services will,
in part, be governed by the configuration of each of the servers.
Various aspects of the DHCPv6 protocol [RFC3315] are used to yield
the desired behaviour, although there is no inter-server or inter-
process communication to coordinate DHCPv6 events 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.
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 In the split prefixes model, each DHCPv6 server is configured with a
unique, non-overlapping range derived from the /64 prefix deployed unique, non-overlapping pool derived from the /64 prefix deployed for
for use within an IPv6 network. Distribution between two servers, use within an IPv6 network. For example, distributing an allocated
for example, would require that an allocated /64 be split in two /65 /64 such as 2001:db8:1:0001::/64 between two servers would require
ranges. 2001:db8:1:0001:0000::/65 and 2001:db8:1:0001:8000::/65 would that it be split into two /65 pools, 2001:db8:1:0001:0000::/65 and
be assigned to each DHCPv6 server for allocation to clients derived 2001:db8:1:0001:8000::/65.
from 2001:db8:1:0001::/64 prefix.
Each DHCP server allocates IPv6 addresses from the corresponding Both DHCPv6 servers are simultaneously active and operational, and
ranges per device class. Each DHCPv6 server will be simultaneously each allocates IPv6 addresses from the corresponding pools per device
active and operational. Address allocation is governed largely class. The address allocation is governed largely through the use of
through the use of the DHCPv6 preference option, so server with the DHCPv6 preference option, so the server with the higher
higher preference value is always prefered. Additional proprietary preference value is always preferred. Additional proprietary
mechanisms can be leveraged to further enforce the favoring of one mechanisms can be used to further enforce the favouring of one DHCP
DHCP server over another. Example of such scenario is presented in server over another. An example of such a scenario is presented in
Figure 1. Figure 1.
It is important to note that over time, it is possible that bindings It is important to note that, over time, it is possible that bindings
may be disproportionally distributed amongst DHCPv6 servers and not will be unevenly distributed amongst the DHCPv6 servers and no one
any one server will be authoritative for all bindings. server will be authoritative for all of them.
Per [RFC3315], a DHCPv6 ADVERTISE messages with a preference option As defined in [RFC3315], a DHCPv6 ADVERTISE message with a preference
of 255 is an indicator to a DHCPv6 client to immediately begin a option of 255 is an indicator to a DHCPv6 client to immediately begin
client-initiated message exchange by transmitting a REQUEST message. a client-initiated message exchange by transmitting a REQUEST message
Alternatively, a DHCPv6 ADVERTISE messages with a preference option to the server that sent the ADVERTISE. Alternatively, a DHCPv6
of any value lesser than 255 or absent preference option is an ADVERTISE message with no preference option (or one with a value less
indicator to the client that it must wait for subsequent ADVERTISE than 255) is an indicator to the client that it must wait for
messages before proceeding, as defined in Section 17.1.2 of subsequent ADVERTISE messages before choosing the server to which is
[RFC3315]. Additionally, in the event of a DHCPv6 server failure it responds, as described in Section 17.1.2 of [RFC3315].
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 In the event of a DHCPv6 server failure it is desirable (but not
be coordinated to ensure that the DNS is properly updated with essential) for a server other than the server that originally
current binding information. Challenges arise with regards to the responded to be able to rebind the client's lease. Given the
update of PTR for IPv6 addresses since the DNS may need to be proposed architecture, the remaining active DHCPv6 server will have a
overwritten in a failure condition. The use of a split prefixes different address pool configured, making it technically incorrect
enables the differentiation of bindings and binding timing to for the same to rebind the client in its current state. Ultimately,
determine which represents the current state. This becomes the rebinding will fail and the client will acquire a new binding
particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 from the pool configured in the active server.
Bulk Leasequery [RFC5460] are leveraged to determine lease or binding
state. An additional benefit is that the use of separate ranges per To reduce the possibility that a client or some other element on the
DHCPv6 server makes failure conditions more obvious and detectable. network will experience a disruption in service or access to relevant
binding data, shorter values for T1, T2, valid, and preferred
lifetimes can be used. The values for the last three can be adjusted
or configured to minimize service disruption. 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 create an additional load on
the DHCPv6 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 used
to determine lease or binding state.
Finally, a benefit of this scheme is that the use of separate pools
per DHCPv6 server makes failure conditions more obvious and
detectable.
+----------+ +-----------+ +----------+ +-----------+
| Client 1 +-\ +--+ Server 1 | | Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
\ | \ |
\ | \ |
\ | \ |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 | | Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+ +----------+ / | +-----------+
. / . . / .
. / . . / .
. / . . / .
+----------+ / . +-----------+ +----------+ / . +-----------+
| Client N +-/ .--| n+1 Server| | Client N +-/ .--| n+1 Server|
+----------+ +-----------+ +----------+ +-----------+
Server 1 Server 1
======== ========
Prefix=2001:db8:1:0:0::/64 Prefix = 2001:db8:1:0:0::/64
Range=2001:db8:1:0:0::/65 Pool = 2001:db8:1:0:0::/65
Preference=255 Preference = 255
Server 2 Server 2
======== ========
Prefix=2001:db8:1:0:0::/64 Prefix = 2001:db8:1:0:0::/64
Range=2001:db8:1:0:8000::/65 Pool = 2001:db8:1:0:8000::/65
Preference=0 Preference = 0
Server n+1 Server n+1
========== ==========
Prefix, range, and preference would Prefix, pool, and preference would
vary based on range definition vary based on prefix definition
Split prefixes approach. Split prefixes approach.
Figure 1 Figure 1
4.2. Multiple Unique Prefixes 6.2. Multiple Unique Prefixes
In the multiple prefix model, each DHCPv6 server is configured with a In the multiple prefix model, each DHCPv6 server is configured with a
unique, non-overlapping prefix. A /64 range equal to the prefix is unique, non-overlapping prefix. A /64 pool equal to the prefix is
configured on each server. For example, the range 2001:db8:1: configured on each server. For example, the 2001:db8:1:0000::/64
0000::/64 would be assigned to a single DHCPv6 server for allocation pool would be assigned to a single DHCPv6 server for allocation to
to clients equal to its parent prefix 2001:db8:1:0000::/64. clients equal to its parent prefix 2001:db8:1:0000::/64. The second
Subsequently the second DHCPv6 server could use 2001:db8:1:0001:::/64 DHCPv6 server could use 2001:db8:1:0001:::/64 as both pool and
as range and prefix. This would be repeated for each active DHCP prefix. This would be repeated for each active DHCP server. An
server. Example of this scenario is presented in Figure 2. example of this scenario is presented in Figure 2.
This approach uses a unique prefix and ultimately range per DHCPv6 The major difference between the split prefixes approach and the
server with corresponding prefixes configured for use in the network. multiple unique prefixes one is that the latter does not require
The corresponding network infrastructure must in turn be configured prefixes to be adjacent. In fact, the split prefixes approach can be
to use multiple prefixes on the inteface(s) facing the DHCPv6 client. considered a special case of the multiple unique prefixes approach.
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 This approach uses a unique prefix and ultimately pool per DHCPv6
IPv6 prefixes and would also yield operational and management server with the corresponding prefixes configured for use in the
challenges related to the underlying network since a significantly network. The corresponding network infrastructure must in turn be
higher number of prefixes would need to be configured and routed. configured to use multiple prefixes on the interface(s) facing the
This approach also does not provide a clean migration path to the DHCPv6 clients. The configuration is similar on all the servers, but
desired solution leveraging a standards-based DHCPv6 redundancy or a different prefix and a different preference is used for each DHCPv6
failover protocol, which of course has yet to be specified. server.
The use of multiple unique prefixes provides benefits similar to This approach drastically increases the rate of consumption of IPv6
those referred to in Section 4.1 related to dynamic updates to DNS. prefixes and also yields operational and management challenges
related to the underlying network since a significantly higher number
of prefixes need to be configured and routed. It also does not
provide a clean migration path to the desired solution using a
standards-based DHCPv6 redundancy or failover protocol (which of
course, has yet to be specified).
The use of multiple unique prefixes provides benefits related to
dynamic updates to DNS similar to those referred to in Section 6.1.
The use of multiple unique prefixes enables the differentiation of The use of multiple unique prefixes enables the differentiation of
bindings and binding timing to determine which represents the current bindings and binding timing to determine which represents the current
state. This becomes particularly important when DHCPv6 Leasequery state. This becomes particularly important when DHCPv6 Leasequery
[RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are leveraged to [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to
determine lease or binding state. The use of separate prefixes and determine lease or binding state. The use of separate prefixes and
ranges per DHCPv6 server makes failure conditions more obvious and pools per DHCPv6 server makes failure conditions more obvious and
detectable. detectable.
+----------+ +-----------+ +----------+ +-----------+
| Client 1 +-\ +--+ Server 1 | | Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
\ | \ |
\ | \ |
\ | \ |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 | | Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+ +----------+ / | +-----------+
. / . . / .
. / . . / .
. / . . / .
+----------+ / . +-----------+ +----------+ / . +-----------+
| Client N +-/ .--| n+1 Server| | Client N +-/ .--| n+1 Server|
+----------+ +-----------+ +----------+ +-----------+
Server 1 Server 1
======== ========
Prefix=2001:db8:1:0000::/64 Prefix = 2001:db8:1:0000::/64
Range=2001:db8:1:0000::/64 Pool = 2001:db8:1:0000::/64
Preference=255 Preference = 255
Server 2 Server 2
======== ========
Prefix=2001:db8:1:1000::/64 Prefix = 2001:db8:1:1000::/64
Range=2001:db8:1:1000::/64 Pool = 2001:db8:1:1000::/64
Preference=0 Preference = 0
Server 3 Server 3
======== ========
Prefix=2001:db8:1:2000::/64 Prefix = 2001:db8:1:2000::/64
Range=2001:db8:1:2000::/64 Pool = 2001:db8:1:2000::/64
Preference=(>0 and <255) Preference = [0..255)
Multiple unique prefix approach. Multiple unique prefix approach.
Figure 2 Figure 2
4.3. Identical Prefixes 6.3. Identical Prefixes
In the identical prefix model, each DHCPv6 server is configured with In the identical prefix model, each DHCPv6 server is configured with
the same overlapping prefix and range deployed for use within an IPv6 the same overlapping prefix and pool deployed for use within an IPv6
network. Distribution between two or more servers, for example, network. Distribution between two or more servers, for example,
would require that the same /64 prefix and range be configured on all would require that the same /64 prefix and pool be configured on all
DHCP servers. For example, the range 2001:db8:1:0001:0000::/64 would DHCP servers. For example, the 2001:db8:1:0001:0000::/64 pool would
be assigned to all DHCPv6 server for allocation to clients derived be assigned to all the DHCPv6 servers for allocation to clients
from 2001:db8:1:0001::/64 prefix. This would be repeated for each derived from the 2001:db8:1:0001::/64 pool. This would be repeated
active DHCP server. Example of such scenario is presented in for each active DHCP server. An example of such a scenario is
Figure 3. presented in Figure 3.
This approach uses the same prefix, length, and range definition This approach uses the same prefix, length, and pool definition
across multiple DHCPv6 servers. All other configuration remaining across multiple DHCPv6 servers: all other configuration parameters
the same the only other attribute of configuration option configured remain the same, with the exception of the DHCPv6 preference. Such
differently per DHCPv6 server would be DHCPv6 preference. This an approach conceivably eases the migration of DHCPv6 services to
approach conceivably eases the migration of DHCPv6 services to fully fully support a standards based redundancy or failover protocol, once
support a standards based redundancy or failover protocol. Similar such solution becomes available. Similar to the split prefix
to the split prefix architecture described above this approach does architecture described above this approach does not place any
not place any additional addressing requirements on network additional addressing requirements on the network infrastructure.
infrastructure.
The use of identical prefixes provides no benefit or advantage The use of identical prefixes provides no benefit or advantage
related to dynamic DNS updates, support of DHCPv6 Leasequery related to dynamic DNS updates, support of DHCPv6 Leasequery
[RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case all DHCP [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case all DHCP
servers will use the same prefix and range configurations making it servers will use the same prefix and pool configurations making it
less obvious that a failure condition or event has occurred. less obvious that a failure condition or event has occurred.
+----------+ +-----------+ +----------+ +-----------+
| Client 1 +-\ +--+ Server 1 | | Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
\ | \ |
\ | \ |
\ | \ |
+----------+ \ | +-----------+ +----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 | | Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+ +----------+ / | +-----------+
. / . . / .
. / . . / .
. / . . / .
+----------+ / . +-----------+ +----------+ / . +-----------+
| Client N +-/ .--| n+1 Server| | Client N +-/ .--| n+1 Server|
+----------+ +-----------+ +----------+ +-----------+
Server 1 Server 1
======== ========
Prefix=2001:db8:1:0000::/64 Prefix = 2001:db8:1:0000::/64
Range=2001:db8:1:0000::/64 Pool = 2001:db8:1:0000::/64
Preference=255 Preference = 255
Server 2 Server 2
======== ========
Prefix=2001:db8:1:0000::/64 Prefix = 2001:db8:1:0000::/64
Range=2001:db8:1:0000::/64 Pool = 2001:db8:1:0000::/64
Preference=0 Preference = 0
Server 3 Server 3
======== ========
Prefix=2001:db8:1:0000::/64 Prefix = 2001:db8:1:0000::/64
Range=2001:db8:1:0000::/64 Pool = 2001:db8:1:0000::/64
Preference=(>0 and <255) Preference = [0..255)
Identical prefix approach. Identical prefix approach.
Figure 3 Figure 3
5. Challenges and Issues 7. Challenges and Issues
The lack of interaction between DHCPv6 servers introduces a number of The lack of interaction between DHCPv6 servers introduces a number of
challenges related to the operations of the same in a production challenges related to the operations of the same service instances in
environment. The following areas are of particular concern: a production environment. The following areas are of particular
concern:
o In indentical prefixes scenario, both servers must follow the same o In the identical prefixes scenario, both servers must follow the
address allocation procedure, i.e. they both must use the same same address allocation procedure, i.e. they both must use the
algorithm and the same policy to determine which address is going same algorithm and the same policy to determine which address is
to be assigned to a specific client. Otherwise there is a going to be assigned to a specific client. Otherwise there is a
distinct chance that each server will assign the same address to distinct chance that each server will assign the same address to
two different clients. 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 dynamic update of o Interactions with DNS server(s) using dynamic update for the same
the same address when one or more DHCPv6 servers have become address when one or more DHCPv6 servers have become unavailable.
unavailable. This specifically becomes a challenge when or if This specifically becomes a challenge when (or if) nodes that were
nodes that were initially granted a lease: initially granted a lease:
1. Attempt to renew or rebind the lease originally granted, or 1. Attempt to renew or rebind the lease originally granted, or
2. Attempt to obtain a new lease 2. Attempt to obtain a new lease
DHCID Resource Record, defined in [RFC4701], allows identification The DHCID resource record [RFC4701] allows identification of the
of the current owner for specific DNS data that can be used during current owner of the specific DNS data that is the target of an
DNS Update procedure [RFC2136]. [RFC4704] specifies how DHCPv6 update [RFC2136]. [RFC4704] specifies how DHCPv6 servers and/or
servers and/or client may perform updates. [RFC4703] provides a client may perform updates. [RFC4703] provides a way to solve
way how to solve conflicts between clients. Although it deals conflicts between clients. Although the [RFC4703] deals with most
with most cases, it is still possible to leave abandoned RR cases, it is still possible to leave abandoned resource records.
records. Consider following scenario. There are two independent Consider the following scenario: there are two independent
servers. Server A assigns a lease to a client and updates DNS servers, A and B. Server A assigns a lease to a client and updates
with AAAA record for assigned address and name. When the client the DNS with an AAAA record for the assigned address. When the
renews, server A is not available and server B assigns a different client renews, server A is not available and server B assigns a
lease. DNS is again updated (now two AAAA RRs are in the DNS for different lease. The DNS is again updated, so now two AAAA
the client). Anyone trying to use the DNS information doesn't resource records are present for the client: there is no
know which of the two leases is active. And, if server A never indication as which of the two leases is active. If server A
recovers, its information may never be removed. never recovers, its information may never be 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 o Interactions with DHCPv6 servers to facilitate the acquisition of
IPv6 lease data care of the DHCPv6 Leasequery [RFC5007] or DHCPv6 IPv6 lease data by way of the DHCPv6 Leasequery [RFC5007] or
Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 DHCPv6 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6
servers have become unavailable and have granted leases to DHCPv6 servers have granted leases to DHCPv6 clients and later became
clients. If IPv6 lease data is required and the granting server unavailable. If the lease data is required and the granting
is unavailable it will not be possible to obtain any information server is unavailable, it will not be possible to obtain any
about leases granted until one of the following has taken place. information about leases granted until one of the following has
taken place:
1. The granting DHCPv6 server becomes available with all lease 1. The granting DHCPv6 server becomes available with all lease
information restored information restored.
2. The client has renewed or rebound its lease against a 2. The client has renewed or rebound its lease against a
different DHCPv6 server different DHCPv6 server.
It is important to note that with DHCPv6 until such time that a It is important to note that any exchange of available leases and
redundancy or failover protocol is available binding updates and synchronization between DHCPv6 servers is not possible until a
synchronization will not occur between DHCPv6 servers. redundancy or failover protocol is standardized or proprietary
solutions become available.
6. IANA Considerations 8. IANA Considerations
IANA is not requested to assign any numbers at this time. This document does not require any actions from IANA.
7. Security Considerations 9. Security Considerations
Security considerations specific to the operation of the DHCPv6 Additional security considerations are created through the use of
protocol are created through the use of this interim architecture for this interim architecture beyond what has been cited in Section 23 of
DHCPv6 redundancy beyond what has been cited for Dynamic Host [RFC3315]. In particular, Dynamic DNS update using the models
Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. There are defined in this document allows for the possibility of not removing
considerations related to DNS, specifically the dynamic updating of abandoned DNS records, even when using conflict resolution mechanism
DNS, when such models are employed. Potential opportunities are defined in [RFC4703]. However, this is no worse than a case where a
created to overwrite valid DNS resource records when provisions have single deployed server crashes and its lease database cannot be
been made accommodate some of the models cited in this document. In recovered.
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 When using identical prefixes model, care must be taken to ensure
that 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 assignment of the same lease to two separate
clients. In some cases that situation can be recovered by using
Duplicate Address Detection (Neighbor Discovery) and DECLINE
mechanism (DHCPv6).
Many thanks to Bernie Volz, Kim Kinnear, Ralph Droms, David Hankins 10. Acknowledgements
and Chuck Anderson for their input and review.
Authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms,
David Hankins, Chuck 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 This work has been partially supported by Department of Computer
Communications (a division of Gdansk University of Technology) and Communications (a division of Gdansk University of Technology) and
the Polish Ministry of Science and Higher Education under the the Polish Ministry of Science and Higher Education under the
European Regional Development Fund, Grant No. POIG.01.01.02-00-045/ European Regional Development Fund, Grant No. POIG.01.01.02-00-045/
09-00 (Future Internet Engineering Project). 09-00 (Future Internet Engineering Project).
9. References 11. References
9.1. Normative References 11.1. Normative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
skipping to change at page 15, line 31 skipping to change at page 16, line 8
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
February 2009. February 2009.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010. Options for Network Boot", RFC 5970, September 2010.
9.2. Informative References 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 Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", Requirements",
draft-mrugalski-dhc-dhcpv6-failover-requirements-00 (work draft-ietf-dhc-dhcpv6-failover-requirements-01 (work in
in progress), June 2011. progress), July 2012.
Authors' Addresses Authors' Addresses
John Jason Brzozowski John Jason Brzozowski
Comcast Cable Communications Comcast Cable Communications
1306 Goshen Parkway 1306 Goshen Parkway
West Chester, PA 19380 West Chester, PA 19380
USA USA
Phone: +1-609-377-6594 Phone: +1-609-377-6594
 End of changes. 83 change blocks. 
341 lines changed or deleted 383 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/