draft-ietf-v6ops-renumbering-procedure-03.txt   draft-ietf-v6ops-renumbering-procedure-04.txt 
IPv6 Operations Working Group F. Baker IPv6 Operations Working Group F. Baker
Internet-Draft E. Lear Internet-Draft E. Lear
Expires: May 23, 2005 R. Droms Expires: August 12, 2005 R. Droms
Cisco Systems Cisco Systems
November 22, 2004 February 8, 2005
Procedures for Renumbering an IPv6 Network without a Flag Day Procedures for Renumbering an IPv6 Network without a Flag Day
draft-ietf-v6ops-renumbering-procedure-03 draft-ietf-v6ops-renumbering-procedure-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 23, 2005. This Internet-Draft will expire on August 12, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a procedure that can be used to renumber a This document describes a procedure that can be used to renumber a
network from one prefix to another. It uses IPv6's intrinsic ability network from one prefix to another. It uses IPv6's intrinsic ability
to assign multiple addresses to a network interface to provide to assign multiple addresses to a network interface to provide
continuity of network service through a "make-before-break" continuity of network service through a "make-before-break"
transition, as well as addressing naming and configuration management transition, as well as addressing naming and configuration management
issues. It also uses other IPv6 features to minimize the effort and issues. It also uses other IPv6 features to minimize the effort and
time required to complete the transition from the old prefix to the time required to complete the transition from the old prefix to the
new prefix. new prefix.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Summary of the renumbering procedure . . . . . . . . . . . 3 1.1 Summary of the renumbering procedure . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Summary of what must be changed . . . . . . . . . . . . . 4 1.3 Summary of what must be changed . . . . . . . . . . . . . 5
1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 5 1.4 Multihoming Issues . . . . . . . . . . . . . . . . . . . . 6
2. Detailed review of procedure . . . . . . . . . . . . . . . . . 6
2.1 Initial condition: stable using the old prefix . . . . . . 6
2.2 Preparation for the renumbering process . . . . . . . . . 6
2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 7
2.2.2 Mechanisms for address assignment to interfaces . . . 8
2.3 Configuring switches and routers for the new prefix . . . 8
2.4 Adding new host addresses . . . . . . . . . . . . . . . . 9
2.5 Stable use of either prefix . . . . . . . . . . . . . . . 10
2.6 Transition from use of the old prefix to the new prefix . 10
2.6.1 Transition of DNS service to the new prefix . . . . . 10
2.6.2 Transition to the use of new addresses . . . . . . . . 10
2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11
2.8 Final condition: stable using the new prefix . . . . . . . 12
3. How to avoid shooting yourself in the foot . . . . . . . . . . 13 2. Detailed review of procedure . . . . . . . . . . . . . . . . . 7
3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13 2.1 Initial condition: stable using the old prefix . . . . . . 7
3.2 Renumbering switch and router interfaces . . . . . . . . . 13 2.2 Preparation for the renumbering process . . . . . . . . . 7
3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Domain Name Service . . . . . . . . . . . . . . . . . 8
2.2.2 Mechanisms for address assignment to interfaces . . . 9
2.3 Configuring switches and routers for the new prefix . . . 9
2.4 Adding new host addresses . . . . . . . . . . . . . . . . 10
2.5 Stable use of either prefix . . . . . . . . . . . . . . . 11
2.6 Transition from use of the old prefix to the new prefix . 11
2.6.1 Transition of DNS service to the new prefix . . . . . 11
2.6.2 Transition to the use of new addresses . . . . . . . . 11
2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 12
2.8 Final condition: stable using the new prefix . . . . . . . 13
4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15 3. How to avoid shooting yourself in the foot . . . . . . . . . . 14
4.1 Dynamic updates to DNS across administrative domains . . . 15 3.1 Applications affected by renumbering . . . . . . . . . . . 14
4.2 Management of the reverse zone . . . . . . . . . . . . . . 15 3.2 Renumbering switch and router interfaces . . . . . . . . . 14
3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 15
3.4 Link Flaps in BGP Routing . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 16
4.1 Dynamic updates to DNS across administrative domains . . . 16
4.2 Management of the reverse zone . . . . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 Normative References . . . . . . . . . . . . . . . . . . . 20
7.2 Informative References . . . . . . . . . . . . . . . . . . 20
A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24 A. Managing Latency in the DNS . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
The Prussian military theorist Carl von Clausewitz [Clausewitz] The Prussian military theorist Carl von Clausewitz [Clausewitz]
wrote, "Everything is very simple in war, but the simplest thing is wrote, "Everything is very simple in war, but the simplest thing is
difficult. These difficulties accumulate and produce a friction, difficult. These difficulties accumulate and produce a friction,
which no man can imagine exactly who has not seen war. ... So in which no man can imagine exactly who has not seen war... So in war,
war, through the influence of an "infinity of petty circumstances" through the influence of an "infinity of petty circumstances" which
which cannot properly be described on paper, things disappoint us and cannot properly be described on paper, things disappoint us and we
we fall short of the mark." Operating a network is aptly compared to fall short of the mark." Operating a network is aptly compared to
conducting a war. The difference is that the opponent has the futile conducting a war. The difference is that the opponent has the futile
expectation that homo ignoramus will behave intelligently. expectation that homo ignoramus will behave intelligently.
A "flag day" is a procedure in which the network, or a part of it, is A "flag day" is a procedure in which the network, or a part of it, is
changed during a planned outage, or suddenly, causing an outage while changed during a planned outage, or suddenly, causing an outage while
the network recovers. Avoiding outages requires the network to be the network recovers. Avoiding outages requires the network to be
modified using what in mobility might be called a "make before break" modified using what in mobility might be called a "make before break"
procedure: the network is enabled to use a new prefix while the old procedure: the network is enabled to use a new prefix while the old
one is still operational, operation is switched to that prefix, and one is still operational, operation is switched to that prefix, and
then the old one is taken down. then the old one is taken down.
This document addresses the key procedural issues in renumbering an This document addresses the key procedural issues in renumbering an
IPv6 [RFC2460] network without a "flag day". The procedure is IPv6 [RFC2460] network without a "flag day". The procedure is
straightforward to describe, but operationally can be difficult to straightforward to describe, but operationally can be difficult to
automate or execute due to issues of statically configured network automate or execute due to issues of statically configured network
state, which one might aptly describe as "an infinity of petty state, which one might aptly describe as "an infinity of petty
circumstances". As a result, in certain areas, this procedure is circumstances". As a result, in certain areas, this procedure is
necessarily incomplete, as network environments vary widely and no necessarily incomplete, as network environments vary widely and no
one solution fits all. It points out a few of many areas where there one solution fits all. It points out a few of many areas where there
are multiple approaches. It may be considered an update to RFC 2072 are multiple approaches. It may be considered an update to
[RFC2072]. This document also contains recommendations for [RFC2072]. This document also contains recommendations for
application design and network management which, if taken seriously, application design and network management which, if taken seriously,
may avoid or minimize the impact of the issues. may avoid or minimize the impact of the issues.
1.1 Summary of the renumbering procedure 1.1 Summary of the renumbering procedure
By "renumbering a network" we mean replacing the use of an existing By "renumbering a network" we mean replacing the use of an existing
(or "old") prefix throughout a network with a new prefix. Usually, (or "old") prefix throughout a network with a new prefix. Usually,
both prefixes will be the same length. The procedures described in both prefixes will be the same length. The procedures described in
this document are, for the most part, equally applicable if the two this document are, for the most part, equally applicable if the two
skipping to change at page 9, line 18 skipping to change at page 10, line 18
Once the new prefix has been added to the network infrastructure, Once the new prefix has been added to the network infrastructure,
access-lists, route-maps and other network configuration options that access-lists, route-maps and other network configuration options that
use IP addresses should be checked to ensure that hosts and services use IP addresses should be checked to ensure that hosts and services
that use the new prefix will behave as they did with the old one. that use the new prefix will behave as they did with the old one.
Name services other than DNS and other services that provide Name services other than DNS and other services that provide
information that will be affected by renumbering must be updated in information that will be affected by renumbering must be updated in
such a way as to avoid responding with stale information. There are such a way as to avoid responding with stale information. There are
several useful approaches to identify and augment configurations: several useful approaches to identify and augment configurations:
Develop a mapping from each network and address derived from the o Develop a mapping from each network and address derived from the
old prefix to each network and address derived from the new old prefix to each network and address derived from the new
prefix. Tools such as the UNIX "sed" or "perl" utilities are prefix. Tools such as the UNIX "sed" or "perl" utilities are
useful to then find and augment access-lists, route-maps, and the useful to then find and augment access-lists, route-maps, and the
like. like.
A similar approach involves the use of such mechanisms as DHCP o A similar approach involves the use of such mechanisms as DHCP
prefix delegation to abstract networks and addresses. prefix delegation to abstract networks and addresses.
Switches and routers or manually configured hosts that have IPv6 Switches and routers or manually configured hosts that have IPv6
addresses assigned from the new prefix may be used at this point to addresses assigned from the new prefix may be used at this point to
test the network infrastructure. test the network infrastructure.
Advertisement of the prefix outside its network is the last thing to Advertisement of the prefix outside its network is the last thing to
be configured during this phase. One wants to have all of one's be configured during this phase. One wants to have all of one's
defenses in place before advertising the prefix, if only because the defenses in place before advertising the prefix, if only because the
prefix may come under immediate attack. prefix may come under immediate attack.
skipping to change at page 13, line 16 skipping to change at page 14, line 16
The difficult operational issues in Section 2.3, Section 2.6, and The difficult operational issues in Section 2.3, Section 2.6, and
Section 2.7 are in dealing with the configurations of routers and Section 2.7 are in dealing with the configurations of routers and
hosts which are not under the control of the network administrator or hosts which are not under the control of the network administrator or
are manually configured. Examples of such devices include voice over are manually configured. Examples of such devices include voice over
IP (VoIP) telephones with static configuration of boot or name IP (VoIP) telephones with static configuration of boot or name
servers, dedicated devices used in manufacturing that are configured servers, dedicated devices used in manufacturing that are configured
with the IP addresses for specific services, the boot servers of with the IP addresses for specific services, the boot servers of
routers and switches, etc. routers and switches, etc.
3.1 "Find all the places..." 3.1 Applications affected by renumbering
Long-lived communications present a problem to any application,
regardless of whether a network is renumbered. However, such events
test the resilience of the code used to survive disruptions. Many
existing applications make use of standard POSIX functions such as
gethostbyname() and getipnodebyname(), both of which use the common
"hostent" structure. If the application caches the response or for
whatever reason actually records the response on disk, recovery from
such events may prove difficult. It should be pointed out that the
above basic functions do not preserve DNS caching semantics. Any
application that requires repeated use of an IP address should either
not cache the result or make use of an appropriate function such as
the POSIX res_query().
In some cases, applications make use of manually configured IP Applications may inadvertently ignore DNS caching semantics
addresses. For instance, database servers and web servers are often associated with IP addresses obtained through DNS resolution. The
configured to LISTEN to a specific TCP port on a specific interface. result is that a long-lived application may continue to use a stale
Applications should be configured with names that are translated at IP address beyond the time at which the TTL for that address has
startup, and then again when the interface address itself is changed. expired, even if the DNS is updated with new addresses during a
renumbering event.
In the case of infrastructure applications such as name servers and For example, many existing applications make use of standard POSIX
route processes, a convenient programmatic method that abstracts functions such as getaddrinfo(), which do not preserve DNS caching
prefixes to a single point would be ideal. semantics. If the application caches the response or for whatever
reason actually records the response on disk, the application will
have no way to know when the TTL for the response has expired. Any
application that requires repeated use of an IP address should either
not cache the result or make use of an appropriate function which
also conveys the TTL of the record (e.g., getrrsetbyname()).
Application designers, equipment vendors, and the Open Source Application designers, equipment vendors, and the Open Source
community should take note. There is an opportunity to serve their community should take note. There is an opportunity to serve their
customers well in this area, and network operators should take note customers well in this area, and network operators should take note
to either develop or purchase appropriate tools. to either develop or purchase appropriate tools.
3.2 Renumbering switch and router interfaces 3.2 Renumbering switch and router interfaces
The configuration and operation of switches and routers are often The configuration and operation of switches and routers are often
designed to use static configuration with IP addresses or to resolve designed to use static configuration with IP addresses or to resolve
skipping to change at page 15, line 5 skipping to change at page 15, line 21
An important consideration in Section 2.3, in the case where the An important consideration in Section 2.3, in the case where the
network being renumbered is connected to an external provider, the network being renumbered is connected to an external provider, the
network's ingress filtering policy and its provider's ingress network's ingress filtering policy and its provider's ingress
filtering policy. Both the network firewall's ingress filter and the filtering policy. Both the network firewall's ingress filter and the
provider's ingress filter on the access link to the network should be provider's ingress filter on the access link to the network should be
configured to prevent attacks that use source address spoofing. configured to prevent attacks that use source address spoofing.
Ingress filtering is considered in detail in "Ingress Filtering for Ingress filtering is considered in detail in "Ingress Filtering for
Multihomed Networks" [RFC3704]. Multihomed Networks" [RFC3704].
3.4 Link Flaps in BGP Routing
A subtle case arises during step 2 in BGP routing when renumbering
the address(es) used to name the BGP routers. Two practices are
common: one is to identify a BGP router by a stable address such as a
loopback address; another is to use the interface address facing the
BGP peer. In each case, when adding a new prefix, a certain
ambiguity is added: the systems must choose between the addresses,
and depending on how they choose different events can happen.
o If the existing address remains in use until removed, then this is
minimized to a routing flap on that event.
o If both systems decide to use the address in the new prefix
simultaneously, the link flap may occur earlier in the process,
and if this is being done automatically (such as via the router
renumbering protocol) may result in route flaps throughout the
network.
o If the two systems choose differently (one uses the old and one
the new address), a stable routing outage occurs.
This is not addressed by proposales such as [I-D.ietf-idr-restart],
as it changes the "name" of the system, making the matter not one of
a flap in an existing relationship but (from BGP's perspective) the
replacement of one routing neighbor with another. Ideally, one
should bring up the new BGP connection for the new address while the
old remains stable and in use, and only then take down the old. In
this manner, while there is a TCP connection flap, routing remains
stable.
4. Call to Action for the IETF 4. Call to Action for the IETF
The more automated one can make the renumbering process, the better The more automated one can make the renumbering process, the better
for everyone. Sadly, there are several mechanisms that either have for everyone. Sadly, there are several mechanisms that either have
not been automated, or have not been automated consistently across not been automated, or have not been automated consistently across
platforms. platforms.
4.1 Dynamic updates to DNS across administrative domains 4.1 Dynamic updates to DNS across administrative domains
The configuration files for a DNS server (such as named.conf) will The configuration files for a DNS server (such as named.conf) will
skipping to change at page 17, line 40 skipping to change at page 18, line 40
configuration management is not possible or is not used must be configuration management is not possible or is not used must be
tracked and managed manually. Here, there be dragons. tracked and managed manually. Here, there be dragons.
In ingress filtering of a multihomed network, an easy solution to the In ingress filtering of a multihomed network, an easy solution to the
issues raised in Section 3.3 might recommend that ingress filtering issues raised in Section 3.3 might recommend that ingress filtering
should not be done for multihomed customers or that ingress filtering should not be done for multihomed customers or that ingress filtering
should be special-cased. However, this has an impact on Internet should be special-cased. However, this has an impact on Internet
security. A sufficient level of ingress filtering is needed to security. A sufficient level of ingress filtering is needed to
prevent attacks using spoofed source addresses. Another problem prevent attacks using spoofed source addresses. Another problem
becomes from the fact that if ingress filtering is made too difficult becomes from the fact that if ingress filtering is made too difficult
(e.g. by requiring special casing in every ISP doing it), it might (e.g., by requiring special casing in every ISP doing it), it might
not be done at an ISP at all. Therefore, any mechanism depending on not be done at an ISP at all. Therefore, any mechanism depending on
relaxing ingress filtering checks should be dealt with an extreme relaxing ingress filtering checks should be dealt with an extreme
care. care.
6. Acknowledgments 6. Acknowledgments
This document grew out of a discussion on the IETF list. Commentary This document grew out of a discussion on the IETF list. Commentary
on the document came from Bill Fenner, Christian Huitema, Craig on the document came from Bill Fenner, Christian Huitema, Craig
Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand, Huegen, Dan Wing. Fred Templin, Hans Kruse, Harald Tveit Alvestrand,
Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas,
skipping to change at page 19, line 5 skipping to change at page 19, line 26
Their comments, if they result in improved address management Their comments, if they result in improved address management
practices in networks, may be the best contribution this note has to practices in networks, may be the best contribution this note has to
offer. offer.
Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described
the ingress filtering issues. These made their way separately into the ingress filtering issues. These made their way separately into
[RFC3704], which should be read and understood by anyone that will [RFC3704], which should be read and understood by anyone that will
temporarily or permanently create a multihomed network by renumbering temporarily or permanently create a multihomed network by renumbering
from one provider to another. from one provider to another.
In addition, the 6NET consortium, notably Alan Ford, Bernard Tuy,
Christian Schild, Graham Holmes, Gunter Van de Velde, Mark Thompson,
Nick Lamb, Stig Venaas, Tim Chown, and Tina Strauf, took it upon
themselves to test the procedure. Some outcomes of that testing have
been documented here, as they seemed of immediate significance to the
procedure; 6NET will also be documenting their own "lessons learned".
7. References 7. References
7.1 Normative References 7.1 Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 19, line 44 skipping to change at page 20, line 44
7.2 Informative References 7.2 Informative References
[Clausewitz] [Clausewitz]
von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, von Clausewitz, C., Howard, M., Paret, P. and D. Brodie,
"On War, Chapter VII, 'Friction in War'", June 1989. "On War, Chapter VII, 'Friction in War'", June 1989.
[I-D.ietf-dnsop-ipv6-dns-issues] [I-D.ietf-dnsop-ipv6-dns-issues]
Durand, A., Ihren, J. and P. Savola, "Operational Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress), Internet-Draft draft-ietf-dnsop-ipv6-dns-issues-10,
October 2004. October 2004.
[I-D.ietf-idr-restart]
Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E.
Chen, "Graceful Restart Mechanism for BGP",
Internet-Draft draft-ietf-idr-restart-10, June 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
skipping to change at page 20, line 50 skipping to change at page 22, line 15
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, CA 93117 Santa Barbara, CA 93117
US US
Phone: 408-526-4257 Phone: 408-526-4257
Fax: 413-473-2403 Fax: 413-473-2403
EMail: fred@cisco.com Email: fred@cisco.com
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 527 4020 Phone: +1 408 527 4020
EMail: lear@cisco.com Email: lear@cisco.com
Ralph Droms Ralph Droms
Cisco Systems Cisco Systems
200 Beaver Brook Road 200 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
US US
Phone: +1 978 936-1674 Phone: +1 978 936-1674
EMail: rdroms@cisco.com Email: rdroms@cisco.com
Appendix A. Managing Latency in the DNS Appendix A. Managing Latency in the DNS
The procedure in this section can be used to determine and manage the The procedure in this section can be used to determine and manage the
latency in updates to information a DNS resource record (RR). latency in updates to information a DNS resource record (RR).
There are several kinds of possible delays which are ignored in these There are several kinds of possible delays which are ignored in these
calculations: calculations:
o the time it takes for the administrators to make the changes, o the time it takes for the administrators to make the changes,
skipping to change at page 24, line 41 skipping to change at page 25, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/