precautions prior to changing to the use of the new prefix to
minimize the chance of broken connections. For example, utilities
such as netstat and network analyzers can be used to determine if any
existing connections to the host are still using the address from the
old prefix for that host.
Link prefixes from the old prefix in router advertisements and
addresses from the old prefix provided through DHCP should have their
preferred lifetimes set to zero at this point, so that hosts will not
use the old prefixes for new communications.
2.7. Removing the Old Prefix
Once all sessions are deemed to have completed, there will be no
dependence on the old prefix. It may be removed from the
configuration of the routing system and from any static
configurations that depend on it. If any configuration has been
created based on DNS information, the configuration should be
refreshed after the old prefixes have been removed from the DNS.
During this phase, the old prefix may be reclaimed by the provider or
Regional Internet Registry that granted it, and addresses within that
prefix are removed from the DNS.
In addition, DNS reverse maps for the old prefix may be removed from
the primary name server and the zone delegation may be removed from
the parent zone. Any DNS, DHCP, or SLAC timers that were changed
should be reset to their original values (most notably the DNS
forward map TTL).
2.8. Final Condition: Stable Using the New Prefix
This is equivalent to the first state, but using the new prefix.
3. How to Avoid Shooting Yourself in the Foot
The difficult operational issues in Section 2.3, Section 2.6, and
Section 2.7 are in dealing with the configurations of routers and
hosts that are not under the control of the network administrator or
are manually configured. Examples of such devices include Voice over
IP (VoIP) telephones with static configuration of boot or name
servers, dedicated devices used in manufacturing that are configured
with the IP addresses for specific services, the boot servers of
routers and switches, etc.
3.1. Applications Affected by Renumbering
Applications may inadvertently ignore DNS caching semantics
associated with IP addresses obtained through DNS resolution. The
result is that a long-lived application may continue to use a stale
IP address beyond the time at which the TTL for that address has
expired, even if the DNS is updated with new addresses during a
renumbering event.
For example, many existing applications make use of standard POSIX
functions such as getaddrinfo(), which do not preserve DNS caching
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 that also
conveys the TTL of the record (e.g., getrrsetbyname()).
Application designers, equipment vendors, and the Open Source
community should take note. There is an opportunity to serve their
customers well in this area, and network operators should either
develop or purchase appropriate tools.
3.2. Renumbering Switch and Router Interfaces
The configuration and operation of switches and routers are often
designed to use static configuration with IP addresses or to resolve
domain names only once and use the resulting IP addresses until the
element is restarted. These static configurations complicate the
process of renumbering, requiring administration of all of the static
information and manual configuration during a renumbering event.
Because switches and routers are usually single-purpose devices, the
user interface and operating functions (software and hardware) are
often better integrated than independent services running on a server
platform. Thus, it is likely that switch vendors and router vendors
can design and implement consistent support for renumbering across
all of the functions of switches and routers.
To better support renumbering, switches and routers should use domain
names for configuration wherever appropriate, and they should resolve
those names using the DNS when the lifetime on the name expires.
3.3. Ingress Filtering
An important consideration in Section 2.3, in the case where the
network being renumbered is connected to an external provider, is the
network’s ingress filtering policy and its provider’s ingress
filtering policy. Both the network firewall’s ingress filter and the
provider’s ingress filter on the access link to the network should be
configured to prevent attacks that use source address spoofing.
Ingress filtering is considered in detail in "Ingress Filtering for
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), it may result in route flaps throughout the
network.
o If the two systems choose differently (one uses the old address
and one uses the new address), a stable routing outage occurs.
This is not addressed by proposals such as [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
The more automated one can make the renumbering process, the better
for everyone. Sadly, there are several mechanisms that either have
not been automated or have not been automated consistently across
platforms.
4.1. Dynamic Updates to DNS Across Administrative Domains
The configuration files for a DNS server (such as named.conf) will
contain addresses that must be reconfigured manually during a
renumbering event. There is currently no easy way to automate the
update of these addresses, as the updates require both complex trust
relationships and automation to verify them. For instance, a reverse
zone is delegated by an upstream ISP, but there is currently no
mechanism to note additional delegations.
4.2. Management of the Reverse Zone
In networks where hosts obtain IPv6 addresses through SLAC, updates
of reverse zone are problematic because of lack of trust relationship
between administrative domain owning the prefix and the host
assigning the low 64 bits using SLAC. For example, suppose a host,
H, from organization A is connected to a network owned by
organization B. When H obtains a new address during a renumbering
event through SLAC, H will need to update its reverse entry in the
DNS through a DNS server from B that owns the reverse zone for the
new address. For H to update its reverse entry, the DNS server from
B must accept a DDNS request from H, requiring that an inter-
administrative domain trust relationship exist between H and B. The
IETF should develop a BCP recommendation for addressing this problem.
5. Security Considerations
The process of renumbering is straightforward in theory but can be
difficult and dangerous in practice. The threats fall into two broad
categories: those arising from misconfiguration and those that are
actual attacks.
Misconfigurations can easily arise if any system in the network
"knows" the old prefix, or an address in it, a priori and is not
configured with the new prefix, or if the new prefix is configured in
a manner that replaces the old instead of being co-equal to it for a
period of time. Simplistic examples include the following:
Neglecting to reconfigure a system that is using the old prefix in
some static configuration: in this case, when the old prefix is
removed from the network, whatever feature was so configured
becomes inoperative - it is not configured for the new prefix, and
the old prefix is irrelevant.
Configuring a system via an IPv6 address, and replacing that old
address with a new address: because the TCP connection is using
the old and now invalid IPv6 address, the SSH session will be
terminated and you will have to use SSH through the new address
for additional configuration changes.
Removing the old configuration before supplying the new: in this
case, it may be necessary to obtain on-site support or travel to
the system and access it via its console.
Clearly, taking the extra time to add the new prefix to the
configuration, allowing the network to settle, and then removing the
old obviates this class of issue. A special consideration applies
when some devices are only occasionally used; the administration must
allow a sufficient length of time in Section 2.6 or apply other
verification procedures to ensure that their likelihood of detection
is sufficiently high.
A subtle case of this type can result when the DNS is used to
populate access control lists and similar security or QoS
configurations. DNS names used to translate between system or
service names and corresponding addresses are treated in this
procedure as providing the address in the preferred prefix, which is
either the old or new prefix but not both. Such DNS names provide a
means, as described in Section 2.6, to cause systems in the network
to stop using the old prefix to access servers or peers and cause
them to start using the new prefix. DNS names used for access
control lists, however, need to go through the same three-step
procedure used for other access control lists, having the new prefix
added to them as discussed in Section 2.3 and the old prefix removed
as discussed in Section 2.7.
It should be noted that the use of DNS names in this way is not
universally accepted as a solution to this problem; [RFC3871]
especially notes cases where static IP addresses are preferred over
DNS names, in order to avoid a name lookup when the naming system is
inaccessible or when the result of the lookup may be one of several
interfaces or systems. In such cases, extra care must be taken to
manage renumbering properly.
Attacks are also possible. Suppose, for example, that the new prefix
has been presented by a service provider, and the service provider
starts advertising the prefix before the customer network is ready.
The new prefix might be targeted in a distributed denial of service
attack, or a system might be broken into using an application that
would not cross the firewall using the old prefix, before the
network’s defenses have been configured. Clearly, one wants to
configure the defenses first and only then accessibility and routing,
as described in Section 2.3 and Section 3.3.
The SLAC procedure described in [RFC2462] renumbers hosts. Dynamic
DNS provides a capability for updating DNS accordingly. Managing
configuration items apart from those procedures is most obviously
straightforward if all such configurations are generated from a
central configuration repository or database, or if they can all be
read into a temporary database, changed using appropriate scripts,
and applied to the appropriate systems. Any place where scripted
configuration management is not possible or is not used must be
tracked and managed manually. Here, there be dragons.
In ingress filtering of a multihomed network, an easy solution to the
issues raised in Section 3.3 might recommend 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
security. A sufficient level of ingress filtering is needed to
prevent attacks using spoofed source addresses. Another problem
comes from the fact that if ingress filtering is made too difficult
(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
relaxing ingress filtering checks should be dealt with with extreme
care.
6. Acknowledgements
This document grew out of a discussion on the IETF list. Commentary
on the document came from Bill Fenner, Christian Huitema, Craig
Huegen, Dan Wing, Fred Templin, Hans Kruse, Harald Tveit Alvestrand,
Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas,
Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford,
Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain.
Some took it on themselves to convince the authors that the concept
of network renumbering as a normal or frequent procedure is daft.
Their comments, if they result in improved address management
practices in networks, may be the best contribution this note has to
offer.
Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described
the ingress filtering issues. These made their way separately into
[RFC3704], which should be read and understood by anyone who will
temporarily or permanently create a multihomed network by renumbering
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 its own "lessons learned".
7. References
7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
7.2. Informative References
[Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D.
Brodie, "On War, Chapter VII, ’Friction in War’", June
1989.
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress, October 2004.
[IDR-RESTART] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and
E. Chen, "Graceful Restart Mechanism for BGP", Work in
Progress, June 2004.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
[RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Appendix A. Managing Latency in the DNS
The procedure in this section can be used to determine and manage the
latency in updates to information a DNS resource record (RR).
There are several kinds of possible delays that are ignored in these
calculations:
o the time it takes for the administrators to make the changes;
o the time it may take to wait for the DNS update, if the
secondaries are only updated at regular intervals, and not
immediately; and
o the time the updating to all the secondaries takes.
Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer
updated information from the primary DNS server to any secondary
servers; this is a very quick update process, and the actual time to
update of information is not considered significant.
There is a target time, TC, at which we want to change the contents
of a DNS RR. The RR is currently configured with TTL == TTLOLD. Any
cached references to the RR will expire no more than TTLOLD in the
future.
At time TC - (TTLOLD + TTLNEW), the RR in the primary is configured
with TTLNEW (TTLNEW < TTLOLD). The update process is initiated to
push the RR to the secondaries. After the update, responses to
queries for the RR are returned with TTLNEW. There are still some
cached references with TTLOLD.
At time TC - TTLNEW, the RR in the primary is configured with the new
address. The update process is initiated to push the RR to the
secondaries. After the update, responses to queries for the RR
return the new address. All the cached references have TTLNEW.
Between this time and TC, responses to queries for the RR may be
returned with either the old address or the new address. This
ambiguity is acceptable, assuming the host is configured to respond
to both addresses.
At time TC, all the cached references with the old address have
expired, and all subsequent queries will return the new address.
After TC (corresponding to the final state described in Section 2.8),
the TTL on the RR can be set to the initial value TTLOLD.
The network administrator can choose TTLOLD and TTLNEW to meet local
requirements.
As a concrete example, consider a case where TTLOLD is a week (168
hours) and TTLNEW is an hour. The preparation for the change of
addresses begins 169 hours before the address change. After 168
hours have passed and only one hour is left, the TTLNEW has
propagated everywhere, and one can change the address record(s).
These are propagated within the hour, after which one can restore TTL
value to a larger value. This approach minimizes time where it is
uncertain what kind of (address) information is returned from the
DNS.
Authors’ Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: 408-526-4257
Fax: 413-473-2403
EMail: fred@cisco.com
Eliot Lear
Cisco Systems GmbH
Glatt-com 2nd Floor
CH-8301 Glattzentrum
Switzerland
Phone: +41 1 878 9200
EMail: lear@cisco.com
Ralph Droms
Cisco Systems
200 Beaver Brook Road
Boxborough, MA 01719
US
Phone: +1 978 936-1674
EMail: rdroms@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement