draft-ietf-dhc-dhcpv6-redundancy-consider-00.txt   draft-ietf-dhc-dhcpv6-redundancy-consider-01.txt 
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: October 11, 2011 Videotron Ltd. Expires: February 13, 2012 Videotron Ltd.
J. Chen J. Chen
Time Warner Cable Time Warner Cable
T. Mrugalski T. Mrugalski
ISC ISC
April 09, 2011 August 12, 2011
DHCPv6 Redundancy Deployment Considerations DHCPv6 Redundancy Deployment Considerations
draft-ietf-dhc-dhcpv6-redundancy-consider-00 draft-ietf-dhc-dhcpv6-redundancy-consider-01
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 October 11, 2011. This Internet-Draft will expire on February 13, 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 14 skipping to change at page 2, line 14
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. Service provider model . . . . . . . . . . . . . . . . . . 4
2.2. Enterprise model . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
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
information specific to the proposed near term approach for deploying information specific to the proposed near term approach for deploying
semi-redundant DHCPv6 services in advance of DHCPv6 server semi-redundant DHCPv6 services in advance of DHCPv6 server
implementations that support a standards based failover or redundancy implementations that support a standards based failover or redundancy
protocol. protocol.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
redundant DHCPv6 solution before the availability of vendor or redundant DHCPv6 solution before the availability of vendor or
standard based solutions. The proposed architecture may be used in standard based solutions. The proposed architecture may be used in
wide range of networks, two notable deployment models are discussed: wide range of networks, two notable deployment models are discussed:
service provider and enterprise network environments. The described service provider and enterprise network environments. The described
architecture leverages only existing and implemented DHCPv6 architecture leverages only existing and implemented DHCPv6
standards. This document does not address a standards based solution standards. This document does not address a standards based solution
for DHCPv6 redundancy. In the absence of a standards based DHCPv6 for DHCPv6 redundancy. In the absence of a standards based DHCPv6
redundancy protocol and implementation, some analogies are loosely redundancy protocol and implementation, some analogies are loosely
drawn with the DHCPv4 failover protocol for reference. Specific drawn with the DHCPv4 failover protocol for reference. Specific
discussions related to DHCPv4 failover and redundancy is out of scope discussions related to DHCPv4 failover and redundancy is out of scope
for this document. 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 Although DHCPv6 redundancy may be useful in a wide range of
scenarios, they may be generalized for illustration purposes in the scenarios, they may be generalized for illustration purposes in the
two aforementioned. The following assumptions were made with regards two aforementioned. The following assumptions were made with regards
to the existing DHCPv6 infrastructure, regardless of the model used: 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 are used to service to the same
clients, but the number of servers is not restricted. clients, but the number of servers is not restricted.
2. Existing DHCPv6 servers will not directly communicate or interact 2. Existing DHCPv6 servers will not directly communicate or interact
skipping to change at page 4, line 9 skipping to change at page 4, line 12
Furthermore, the requesting clients must process DHCPv6 ADVERTISE Furthermore, the requesting clients must process DHCPv6 ADVERTISE
messages per [RFC3315] when the preference option is present. messages per [RFC3315] when the preference option is present.
5. DHCPv6 server failure does not imply failure of any other network 5. DHCPv6 server failure does not imply failure of any other network
service or protocol, e.g. TFTP servers. Redundancy of any service or protocol, e.g. TFTP servers. Redundancy of any
additional services configured by means of DHCPv6 are outside of additional services configured by means of DHCPv6 are outside of
scope of this document. For example, a single DHCPv6 server may scope of this document. For example, a single DHCPv6 server may
configure multiple TFTP servers, with preference for each TFTP configure multiple TFTP servers, with preference for each TFTP
server, as specified in [RFC5970]. server, as specified in [RFC5970].
While techniques described in this document provide some aspects of
redundancy, it should be noted that complete redundancy will not be
available until DHCPv6 protocol is standardized. Initial work toward
that goal is described in
[I-D.mrugalski-dhc-dhcpv6-failover-requirements].
2.1. Service provider model 2.1. Service provider model
The service provider model represents cases, where end-user devices The service provider model represents cases, where end-user devices
may be configured directly, without any intermediate devices (like may be configured directly, without any intermediate devices (like
home routers used in service provider model). DHCPv6 clients include home routers used in service provider model). DHCPv6 clients include
cable modems, customer gateways or home routers, and end-user cable modems, customer gateways or home routers, and end-user
devices. In some cases hosts may be configured directly using the devices. In some cases hosts may be configured directly using the
service provider DHCPv6 infrastructure or via intermediate router, service provider DHCPv6 infrastructure or via intermediate router,
that is in turn being configured by the provider DHCPv6 that is in turn being configured by the provider DHCPv6
infrastructure. The service provider DHCPv6 infrastructure may be infrastructure. The service provider DHCPv6 infrastructure may be
skipping to change at page 5, line 26 skipping to change at page 5, line 36
The following sections outline the requirements that must be The following sections outline the requirements that must be
satisfied by DHCPv6 clients, relays, and servers to ensure the satisfied by DHCPv6 clients, relays, and servers to ensure the
desired behavior is provided using pre-existing DHCPv6 server desired behavior is provided using pre-existing DHCPv6 server
implementations as is. The objective is to provide a semi-redundant implementations as is. The objective is to provide a semi-redundant
DHCPv6 service to support the deployment of IPv6 where DHCPv6 is DHCPv6 service to support the deployment of IPv6 where DHCPv6 is
required for the assignment of IPv6 addresses, prefixes, and or required for the assignment of IPv6 addresses, prefixes, and or
configuration information. configuration information.
3.1. DHCPv6 Servers 3.1. DHCPv6 Servers
This interim architecture requires DHCPv6 servers that are RFC 3315 This interim architecture requires DHCPv6 servers that are [RFC3315]
[RFC3315] compliant and support the necessary options required to compliant and support the necessary options required to support this
support this solution. Essential to the the use of the interim solution. Essential to the the use of the interim architecture is
architecture is support for stateful DHCPv6 and the DHCPv6 preference support for stateful DHCPv6 and the DHCPv6 preference option both
option both which are specified in [RFC3315]. For deployment which are specified in [RFC3315]. For deployment scenarios where
scenarios where IPv6 prefix delegation is employed DHCPv6 servers IPv6 prefix delegation is employed DHCPv6 servers must support DHCPv6
must support DHCPv6 prefix delegation as defined by [RFC3633]. prefix delegation as defined by [RFC3633]. Further, where stateless
Further, where stateless DHCPv6 is used support for [RFC3736] is DHCPv6 is used support for [RFC3736] is required by DHCPv6 servers.
required by DHCPv6 servers.
3.2. DHCPv6 Relays 3.2. DHCPv6 Relays
There are no specific requirements regarding relays. However, it is There are no specific requirements regarding relays. However, it is
implied that DHCPv6 relay agents must be [RFC3315] compliant and must implied that DHCPv6 relay agents must be [RFC3315] compliant and must
support the ability to relay DHCPv6 messages to more than one support the ability to relay DHCPv6 messages to more than one
destination minimally. destination minimally.
3.3. DHCPv6 Clients 3.3. DHCPv6 Clients
skipping to change at page 7, line 39 skipping to change at page 8, line 5
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
state. An additional benefit is that the use of separate ranges per state. An additional benefit is that the use of separate ranges per
DHCPv6 server makes failure conditions more obvious and detectable. DHCPv6 server makes failure conditions more obvious and detectable.
(@todo - add more useful illustration)
+----------+ +-----------+ +----------+ +-----------+
| 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:abcd:0000::/64 Prefix=2001:db8:1:0:0::/64
Range=2001:db8:abcd:5678:0000:/65 Range=2001:db8:1:0:0::/65
Preference=255 Preference=255
Server 2 Server 2
======== ========
Prefix=2001:db8:abcd:0000::/64 Prefix=2001:db8:1:0:0::/64
Range=2001:db8:abcd:5678:8000:/65 Range=2001:db8:1:0:8000::/65
Preference=0 Preference=0
Server n+1 Server n+1
========== ==========
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 multiple prefix model, each DHCPv6 server is configured with a
unique, non-overlapping range derived from multiple unique prefixes unique, non-overlapping range derived from multiple unique prefixes
deployed for use within an IPv6 network. Distribution between two deployed for use within an IPv6 network. Distribution between two
servers, for example, would require that a /64 range be configured servers, for example, would require that a /64 range be configured
from an allocated from unique /64 prefixes. For example, the range from an allocated from unique /64 prefixes. For example, the range
2001:db8:1:0001:0000::/64 would be assigned to a single DHCPv6 server 2001:db8:1:0001::/64 would be assigned to a single DHCPv6 server for
for allocation to clients derived from 2001:db8:1:0001::/64 prefix, allocation to clients derived from 2001:db8:1:0001::/64 prefix,
subsequently the 2001:db8:1:0001:1000::/64 from the prefix 2001:db8: subsequently the 2001:db8:1:0001:1000::/64 from the prefix 2001:db8:
1:0001:1000::/64 could be used by a second DHCP server. This would 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 be repeated for each active DHCP server. Example of this scenario is
presented in Figure 2. 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.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
+----------+ / | +-----------+ +----------+ / | +-----------+
. / . . / .
. / . . / .
. / . . / .
+----------+ / . +-----------+ +----------+ / . +-----------+
| Client N +-/ .--| n+1 Server| | Client N +-/ .--| n+1 Server|
+----------+ +-----------+ +----------+ +-----------+
Server 1 Server 1
======== ========
Prefix=2001:db8:abcd:0000::/64 Prefix=2001:db8:1:0000::/64
Range=2001:db8:abcd:0000::/64 Range=2001:db8:1:0000::/64
Preference=255 Preference=255
Server 2 Server 2
======== ========
Prefix=2001:db8:abcd:1000::/64 Prefix=2001:db8:1:1000::/64
Range=2001:db8:abcd:1000::/64 Range=2001:db8:1:1000::/64
Preference=0 Preference=0
Server 3 Server 3
======== ========
Prefix=2001:db8:abcd:2000::/64 Prefix=2001:db8:1:2000::/64
Range=2001:db8:abcd:2000::/64 Range=2001:db8:1:2000::/64
Preference=(>0 and <255) Preference=(>0 and <255)
Multiple unique prefix approach. Multiple unique prefix approach.
Figure 2 Figure 2
4.3. Identical Prefixes 4.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 range deployed for use within an IPv6
skipping to change at page 12, line 23 skipping to change at page 12, line 23
+----------+ / | +-----------+ +----------+ / | +-----------+
. / . . / .
. / . . / .
. / . . / .
+----------+ / . +-----------+ +----------+ / . +-----------+
| Client N +-/ .--| n+1 Server| | Client N +-/ .--| n+1 Server|
+----------+ +-----------+ +----------+ +-----------+
Server 1 Server 1
======== ========
Prefix=2001:db8:abcd:0000::/64 Prefix=2001:db8:1:0000::/64
Range=2001:db8:abcd:0000::/64 Range=2001:db8:1:0000::/64
Preference=255 Preference=255
Server 2 Server 2
======== ========
Prefix=2001:db8:abcd:0000::/64 Prefix=2001:db8:1:0000::/64
Range=2001:db8:abcd:0000::/64 Range=2001:db8:1:0000::/64
Preference=0 Preference=0
Server 3 Server 3
======== ========
Prefix=2001:db8:abcd:0000::/64 Prefix=2001:db8:1:0000::/64
Range=2001:db8:abcd:0000::/64 Range=2001:db8:1:0000::/64
Preference=(>0 and <255) Preference=(>0 and <255)
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 of are particular concern. environment. The following areas are of particular concern:
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 adress and prefix when one or more DHCPv6 servers have the same address when one or more DHCPv6 servers have become
become unavailable. This specifically becomes a challenge when or unavailable. This specifically becomes a challenge when or if
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
In either of the cases cited above, safeguards leveraged to DHCID Resource Record, defined in [RFC4701], allows identification
prevent the deliberate or inadvertent overwriting of DNS data will of the current owner for specific DNS data that can be used during
likely prevent the responding DHCPv6 server from properly updating DNS Update procedure [RFC2136]. [RFC4704] specifies how DHCPv6
DNS with the client's new information and or may result in stale servers and/or client may perform updates. [RFC4703] provides a
data in DNS. Possible solutions include the following: way how to solve conflicts between clients. Although it deals
with most cases, it is still possible to leave abandoned RR
* The ability to configure the override and or disabling of the records. Consider following scenario. There are two independent
safeguards that prevent the over-writing of DNS data care of servers. Server A assigns a lease to a client and updates DNS
RFC2136, specifically, related to [RFC4701] and [RFC4703]. with AAAA record for assigned address and name. When the client
This behavior must specifically be supported by the DHCPv6 renews, server A is not available and server B assigns a different
server. This will allow for the overwriting of existing RRs in lease. DNS is again updated (now two AAAA RRs are in the DNS for
DNS that represent the former binding for the client. As a the client). Anyone trying to use the DNS information doesn't
result clients will not have multiple RRs in DNS for a client's know which of the two leases is active. And, if server A never
FQDN-to-IPv6 address mapping. Conversely, RR's for a client's recovers, its information may never be removed.
IPv6 address-to-FQDN mapping will not be actively overwritten
or deleted. Stale reverse zone data will be purged using well
known DNS constructs, including but not limited to leveraging
TTLs. Access control on the DNS server must be leveraged to
restrict which DHCP servers may update DNS.
o Interactions with DHCPv6 servers to facilitate the acquisition of o Interactions with DHCPv6 servers to facilitate the acquisition of
IPv6 lease data care of the DHCPv6 Leasequery [RFC5007] or DHCPv6 IPv6 lease data care of the DHCPv6 Leasequery [RFC5007] or DHCPv6
Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6
servers have become unavailable and have granted leases to DHCPv6 servers have become unavailable and have granted leases to DHCPv6
clients. If IPv6 lease data is required and the granting server clients. If IPv6 lease data is required and the granting server
is unavailable it will not be possible to obtain any information is unavailable it will not be possible to obtain any information
about leases granted until one of the following has taken place. about leases granted until one of the following has taken place.
It is important to note that with DHCPv6 until such time that a
redundancy or failover protocol is available binding updates and
synchronization will not occur between DHCPv6 servers.
1. The granting DHCPv6 server becomes available with all lease 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
redundancy or failover protocol is available binding updates and
synchronization will not occur between DHCPv6 servers.
6. IANA Considerations 6. IANA Considerations
IANA is not requested to assign any numbers at this time. IANA is not requested to assign any numbers at this time.
7. Security Considerations 7. Security Considerations
Security considerations specific to the operation of the DHCPv6 Security considerations specific to the operation of the DHCPv6
protocol are created through the use of this interim architecture for protocol are created through the use of this interim architecture for
DHCPv6 redundancy beyond what has been cited for Dynamic Host DHCPv6 redundancy beyond what has been cited for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. There are Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. There are
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, and Ralph Droms for their Many thanks to Bernie Volz, Kim Kinnear, Ralph Droms, Bernie Volz and
input and review. David Hankins for their input and review.
9. Normative References This work has been partially supported by Gdansk University of
Technology.
9. References
9.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., [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
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
skipping to change at page 14, line 47 skipping to change at page 15, line 6
[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
Record (RR) for Encoding Dynamic Host Configuration Record (RR) for Encoding Dynamic Host Configuration
Protocol (DHCP) Information (DHCID RR)", RFC 4701, Protocol (DHCP) Information (DHCID RR)", RFC 4701,
October 2006. October 2006.
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified
Domain Name (FQDN) Conflicts among Dynamic Host Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients", RFC 4703, Configuration Protocol (DHCP) Clients", RFC 4703,
October 2006. 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, [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
[I-D.mrugalski-dhc-dhcpv6-failover-requirements]
Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements",
draft-mrugalski-dhc-dhcpv6-failover-requirements-00 (work
in progress), June 2011.
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
 End of changes. 31 change blocks. 
67 lines changed or deleted 92 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/