draft-ietf-dhc-dhcpv6-redundancy-consider-01.txt   draft-ietf-dhc-dhcpv6-redundancy-consider-02.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: BCP J. Tremblay
Expires: February 13, 2012 Videotron Ltd. Expires: May 3, 2012 Videotron Ltd.
J. Chen J. Chen
Time Warner Cable Time Warner Cable
T. Mrugalski T. Mrugalski
ISC ISC
August 12, 2011 October 31, 2011
DHCPv6 Redundancy Deployment Considerations DHCPv6 Redundancy Deployment Considerations
draft-ietf-dhc-dhcpv6-redundancy-consider-01 draft-ietf-dhc-dhcpv6-redundancy-consider-02
Abstract Abstract
This document documents some deployment considerations for those who This document documents some deployment considerations for those who
wishing to use DHCPv6 to support their deployment of IPv6. wishing to use DHCPv6 to support their deployment of IPv6.
Specifically, providing semi-redundant DHCPv6 services is discussed Specifically, providing semi-redundant DHCPv6 services is discussed
in this document. in this document.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 February 13, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2.2. Enterprise model . . . . . . . . . . . . . . . . . . . . . 5 2.2. Enterprise model . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol requirements . . . . . . . . . . . . . . . . . . . . 5 3. Protocol requirements . . . . . . . . . . . . . . . . . . . . 5
3.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5 3.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5 3.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5
3.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 6 3.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment models . . . . . . . . . . . . . . . . . . . . . . 6 4. Deployment models . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8 4.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8
4.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10 4.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
5. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12 5. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
To support the deployment of IPv6 redundancy and high availability To support the deployment of IPv6 redundancy and high availability
are required for many if not all components. This document provides are required for many if not all components. This document provides
skipping to change at page 4, line 38 skipping to change at page 4, line 38
semi-redundant in either case. Cable modems, customer gateways or semi-redundant in either case. Cable modems, customer gateways or
home routers, and end-user devices are commonly referred to as CPE home routers, and end-user devices are commonly referred to as CPE
(Customer Premises Equipment). The following additional assumptions (Customer Premises Equipment). The following additional assumptions
were made, besides the ones made in Section 2: were made, besides the ones made in Section 2:
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
atleast 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 leverage
stateless DHCPv6 [RFC3736] to acquire configuration information stateless DHCPv6 [RFC3736] to acquire configuration information
only. This assumes that IPv6 address and prefix information has only. This assumes that IPv6 address and prefix information has
been acquired using other means. been acquired using other means.
3. The primary application of this BCP is for native IPv6 services. 3. The primary application of this BCP is for native IPv6 services.
Use and applicability to transition mechanisms is out of scope Use and applicability to transition mechanisms is out of scope
for this document. for this document.
4. CPE devices must implement a stateful DHCPv6 client [RFC3315], 4. CPE devices must implement a stateful DHCPv6 client [RFC3315],
support for DHCPv6 prefix delegation [RFC3633] or stateless support for DHCPv6 prefix delegation [RFC3633] or stateless
DHCPv6 [RFC3736] may also be implemented. DHCPv6 [RFC3736] may also be implemented.
2.2. Enterprise model 2.2. Enterprise model
The enterprise model represents cases, where end-user devices are The enterprise model represents cases where end-user devices are most
most often configured directly, without any intermediate devices often configured directly without any intermediate devices (like home
(like home routers used in service provider model). However, routers used in service provider model). However enterprise IPv6
enterprise IPv6 environments quite often use or require that DHCPv6 environments quite often use or require that DHCPv6 relay agents are
relay agents are in place to support the use of DHCPv6 for the in place to support the use of DHCPv6 for the acquisition of IPv6
acquisition of IPv6 addresses and or configuration information. The addresses and or configuration information. The assumptions here
assumptions here extend those that are defined in the beginning of extend those that are defined in the beginning of Section 2:
Section 2:
1. DHCPv6 clients are hosts and are considered end nodes. Examples 1. DHCPv6 clients are hosts and are considered end nodes. Examples
of such clients include computers, laptops, and possibily mobile of such clients include computers, laptops, and possibily mobile
devices. devices.
2. DHCPv6 clients generally do not require the assignment of an IPv6 2. DHCPv6 clients generally do not require the assignment of an IPv6
prefix delegation and as such do not support DHCPv6 prefix prefix delegation and as such do not support DHCPv6 prefix
delegation [RFC3633]. delegation [RFC3633].
3. Protocol requirements 3. Protocol requirements
skipping to change at page 7, line 7 skipping to change at page 7, line 7
ranges per device class. Each DHCPv6 server will be simultaneously ranges per device class. Each DHCPv6 server will be simultaneously
active and operational. Address allocation is governed largely active and operational. Address allocation is governed largely
through the use of the DHCPv6 preference option, so server with through the use of the DHCPv6 preference option, so server with
higher preference value is always prefered. Additional proprietary higher preference value is always prefered. Additional proprietary
mechanisms can be leveraged to further enforce the favoring of one mechanisms can be leveraged to further enforce the favoring of one
DHCP server over another. Example of such scenario is presented in DHCP server over another. Example of such 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 may be disproportionally distributed amongst DHCPv6 servers and not
any one server will be authoritative for all bindings. Per any one server will be authoritative for all bindings.
[RFC3315], a DHCPv6 ADVERTISE messages with a preference option of
255 is an indicator to a DHCPv6 client to immediately begin a client- Per [RFC3315], a DHCPv6 ADVERTISE messages with a preference option
initiated message exchange by transmitting a REQUEST message. 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 Alternatively, a DHCPv6 ADVERTISE messages with a preference option
of any value lesser than 255 or is absent is an indicator to the of any value lesser than 255 or absent preference option is an
client that it must wait for subsequent ADVERTISE messages (for a indicator to the client that it must wait for subsequent ADVERTISE
specified period of time) before proceeding. Additionally, in the messages before proceeding, as defined in Section 17.1.2 of
event of a DHCPv6 server failure it is desirable for a server other [RFC3315]. Additionally, in the event of a DHCPv6 server failure it
than the server that originally responded to be able to rebind the is desirable for a server other than the server that originally
client. It is not critical, that the DHCPv6 server be able to rebind responded to be able to rebind the client. It is not critical, that
the client in this scenario, however, this is generally desirable the DHCPv6 server be able to rebind the client in this scenario,
behavior. Given the proposed architecture, the remaining active however, this is generally desirable behavior. Given the proposed
DHCPv6 server will have a different range configured making it architecture, the remaining active DHCPv6 server will have a
technically incorrect for the same to rebind the client in its different range configured making it technically incorrect for the
current state. Ultimately, when rebinding fails the client will same to rebind the client in its current state. Ultimately, when
acquire a new binding from the configured range unique to an active rebinding fails the client will acquire a new binding from the
server. Furthermore, shorter T1, T2, valid, and preferred lifetimes configured range unique to an active server. Furthermore, shorter
can be used to reduce the possibility that a client or some other T1, T2, valid, and preferred lifetimes can be used to reduce the
element on the network will experience a disruption in service or possibility that a client or some other element on the network will
access to relevant binding data. The values used for T2, preferred experience a disruption in service or access to relevant binding
and valid lifetime can be adjusted or configured to minimize service data. The values used for T2, preferred and valid lifetime can be
disruption. Ideally T2, preferred and valid lifetimes that are equal adjusted or configured to minimize service disruption. Ideally T2,
or near equal can be used to trigger a DHCPv6 client to reacquire preferred and valid lifetimes that are equal or near equal can be
IPv6 address, prefix, and or configuration information almost used to trigger a DHCPv6 client to reacquire IPv6 address, prefix,
immediately after rebinding fails. It is important to note that and or configuration information almost immediately after rebinding
shorter values will most certainly create additional load and fails. It is important to note that shorter values will most
processing for the DHCPv6 server, which must be considered. 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 Using a split prefix configuration model dynamic updates to DNS can
be coordinated to ensure that the DNS is properly updated with be coordinated to ensure that the DNS is properly updated with
current binding information. Challenges arise with regards to the current binding information. Challenges arise with regards to the
update of PTR for IPv6 addresses since the DNS may need to be update of PTR for IPv6 addresses since the DNS may need to be
overwritten in a failure condition. The use of a split prefixes overwritten in a failure condition. The use of a split prefixes
enables the differentiation of bindings and binding timing to enables the differentiation of bindings and binding timing to
determine which represents the current state. This becomes determine which represents the current state. This becomes
particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6
Bulk Leasequery [RFC5460] are leveraged to determine lease or binding Bulk Leasequery [RFC5460] are leveraged to determine lease or binding
skipping to change at page 8, line 44 skipping to change at page 8, line 44
========== ==========
Prefix, range, and preference would Prefix, range, and preference would
vary based on range definition vary based on range definition
Split prefixes approach. Split prefixes approach.
Figure 1 Figure 1
4.2. Multiple Unique Prefixes 4.2. Multiple Unique Prefixes
In 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 range derived from multiple unique prefixes unique, non-overlapping prefix. A /64 range equal to the prefix is
deployed for use within an IPv6 network. Distribution between two configured on each server. For example, the range 2001:db8:1:
servers, for example, would require that a /64 range be configured 0000::/64 would be assigned to a single DHCPv6 server for allocation
from an allocated from unique /64 prefixes. For example, the range to clients equal to its parent prefix 2001:db8:1:0000::/64.
2001:db8:1:0001::/64 would be assigned to a single DHCPv6 server for Subsequently the second DHCPv6 server could use 2001:db8:1:0001:::/64
allocation to clients derived from 2001:db8:1:0001::/64 prefix, as range and prefix. This would be repeated for each active DHCP
subsequently the 2001:db8:1:0001:1000::/64 from the prefix 2001:db8: server. Example of this scenario is presented in Figure 2.
1:0001:1000::/64 could be used by a second DHCP server. This would
be repeated for each active DHCP server. Example of this scenario is
presented in Figure 2.
This approach uses a unique prefix and ultimately range per DHCPv6 This approach uses a unique prefix and ultimately range per DHCPv6
server with corresponding prefixes configured for use in the network. server with corresponding prefixes configured for use in the network.
The corresponding network infrastructure must in turn be configured The corresponding network infrastructure must in turn be configured
to use multiple prefixes on the inteface(s) facing the DHCPv6 client. to use multiple prefixes on the inteface(s) facing the DHCPv6 client.
The configuration is similar on all the servers, but a different The configuration is similar on all the servers, but a different
prefix and a different preference is used per DHCPv6 server. prefix and a different preference is used per DHCPv6 server.
This approach would drastically increase the rate of consumption of This approach would drastically increase the rate of consumption of
IPv6 prefixes and would also yield operational and management IPv6 prefixes and would also yield operational and management
skipping to change at page 12, line 49 skipping to change at page 12, line 49
Identical prefix approach. Identical prefix approach.
Figure 3 Figure 3
5. Challenges and Issues 5. 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 in a production
environment. The following areas are of particular concern: environment. The following areas are of particular concern:
o In indentical 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.
o Interactions with DNS server(s) to support the dynamic update of o Interactions with DNS server(s) to support the dynamic update of
the same address when one or more DHCPv6 servers have become the same address when one or more DHCPv6 servers have become
unavailable. This specifically becomes a challenge when or if unavailable. This specifically becomes a challenge when or if
nodes that were initially granted a lease: nodes that were 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 DHCID Resource Record, defined in [RFC4701], allows identification
skipping to change at page 14, line 17 skipping to change at page 14, line 25
considerations related to DNS, specifically the dynamic updating of considerations related to DNS, specifically the dynamic updating of
DNS, when such models are employed. Potential opportunities are DNS, when such models are employed. Potential opportunities are
created to overwrite valid DNS resource records when provisions have created to overwrite valid DNS resource records when provisions have
been made accommodate some of the models cited in this document. In 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 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 when using one or more of these models, however, abuse of the same
could result in undesirable behavior. could result in undesirable behavior.
8. Acknowledgements 8. Acknowledgements
Many thanks to Bernie Volz, Kim Kinnear, Ralph Droms, Bernie Volz and Many thanks to Bernie Volz, Kim Kinnear, Ralph Droms, David Hankins
David Hankins for their input and review. and Chuck Anderson for their input and review.
This work has been partially supported by Gdansk University of This work has been partially supported by Department of Computer
Technology. 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. References 9. References
9.1. Normative References 9.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.,
skipping to change at page 15, line 37 skipping to change at page 16, line 4
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
Email: john_brzozowski@cable.comcast.com Email: john_brzozowski@cable.comcast.com
Jean-Francois Tremblay Jean-Francois Tremblay
Videotron Ltd. Videotron Ltd.
612 Saint-Jacques 612 Saint-Jacques
Montreal, Quebec H3C 4M8i Montreal, Quebec H3C 4M8
Canada Canada
Email: Jean-Francois.TremblayING@videotron.com Email: jf@jftremblay.com
Jack Chen Jack Chen
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
USA USA
Email: jack.chen@twcable.com Email: jack.chen@twcable.com
Tomasz Mrugalski Tomasz Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
 End of changes. 16 change blocks. 
61 lines changed or deleted 68 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/