RFC4192 日本語訳
4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F.Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110 bytes) (Updates RFC2072) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Baker
Request for Comments: 4192 Cisco Systems
Updates: 2072 E. Lear
Category: Informational Cisco Systems GmbH
R. Droms
Cisco Systems
September 2005
Network Working Group F. Baker Request for Comments: 4192 Cisco Systems Updates: 2072 E. Lear Category: Informational Cisco Systems GmbH R. Droms Cisco Systems September 2005
Procedures for Renumbering an IPv6 Network without a Flag Day
Procedures for Renumbering an IPv6 Network without a Flag Day
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.
Baker, et al. Informational [Page 1] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 1] RFC 4192 Renumbering IPv6 Networks September 2005
Table of Contents
Table of Contents
1. Introduction ....................................................2
1.1. Summary of the Renumbering Procedure .......................3
1.2. Terminology ................................................4
1.3. Summary of What Must Be Changed ............................4
1.4. Multihoming Issues .........................................5
2. Detailed Review of Procedure ....................................5
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 .....7
2.3. Configuring Network Elements 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 Use of New Addresses .................10
2.7. Removing the Old Prefix ...................................11
2.8. Final Condition: Stable Using the New Prefix ..............11
3. How to Avoid Shooting Yourself in the Foot .....................12
3.1. Applications Affected by Renumbering ......................12
3.2. Renumbering Switch and Router Interfaces ..................12
3.3. Ingress Filtering .........................................13
3.4. Link Flaps in BGP Routing .................................13
4. Call to Action for the IETF ....................................14
4.1. Dynamic Updates to DNS Across Administrative Domains ......14
4.2. Management of the Reverse Zone ............................14
5. Security Considerations ........................................14
6. Acknowledgements ...............................................16
7. References .....................................................17
7.1. Normative References ......................................17
7.2. Informative References ....................................17
Appendix A. Managing Latency in the DNS ..........................20
1. Introduction ....................................................2 1.1. Summary of the Renumbering Procedure .......................3 1.2. Terminology ................................................4 1.3. Summary of What Must Be Changed ............................4 1.4. Multihoming Issues .........................................5 2. Detailed Review of Procedure ....................................5 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 .....7 2.3. Configuring Network Elements 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 Use of New Addresses .................10 2.7. Removing the Old Prefix ...................................11 2.8. Final Condition: Stable Using the New Prefix ..............11 3. How to Avoid Shooting Yourself in the Foot .....................12 3.1. Applications Affected by Renumbering ......................12 3.2. Renumbering Switch and Router Interfaces ..................12 3.3. Ingress Filtering .........................................13 3.4. Link Flaps in BGP Routing .................................13 4. Call to Action for the IETF ....................................14 4.1. Dynamic Updates to DNS Across Administrative Domains ......14 4.2. Management of the Reverse Zone ............................14 5. Security Considerations ........................................14 6. Acknowledgements ...............................................16 7. References .....................................................17 7.1. Normative References ......................................17 7.2. Informative References ....................................17 Appendix A. Managing Latency in the DNS ..........................20
1. Introduction
1. Introduction
The Prussian military theorist Carl von Clausewitz [Clausewitz] wrote, "Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.... So in war, through the influence of an 'infinity of petty circumstances' which cannot properly be described on paper, things disappoint us and we fall short of the mark". Operating a network is aptly compared to conducting a war. The difference is that the opponent has the futile expectation that homo ignoramus will behave intelligently.
The Prussian military theorist Carl von Clausewitz [Clausewitz] wrote, "Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.... So in war, through the influence of an 'infinity of petty circumstances' which cannot properly be described on paper, things disappoint us and we fall short of the mark". Operating a network is aptly compared to conducting a war. The difference is that the opponent has the futile expectation that homo ignoramus will behave intelligently.
Baker, et al. Informational [Page 2] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 2] RFC 4192 Renumbering IPv6 Networks September 2005
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 the network recovers. Avoiding outages requires the network to be 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 one is still operational, operation is switched to that prefix, and then the old one is taken down.
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 the network recovers. Avoiding outages requires the network to be 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 one is still operational, operation is switched to that prefix, and then the old one is taken down.
This document addresses the key procedural issues in renumbering an IPv6 [RFC2460] network without a "flag day". The procedure is straightforward to describe, but operationally can be difficult to automate or execute due to issues of statically configured network state, which one might aptly describe as "an infinity of petty circumstances". As a result, in certain areas, this procedure is necessarily incomplete, as network environments vary widely and no one solution fits all. It points out a few of many areas where there are multiple approaches. This document updates [RFC2072]. This document also contains recommendations for application design and network management, which, if taken seriously, may avoid or minimize the impact of the issues.
This document addresses the key procedural issues in renumbering an IPv6 [RFC2460] network without a "flag day". The procedure is straightforward to describe, but operationally can be difficult to automate or execute due to issues of statically configured network state, which one might aptly describe as "an infinity of petty circumstances". As a result, in certain areas, this procedure is necessarily incomplete, as network environments vary widely and no one solution fits all. It points out a few of many areas where there are multiple approaches. This document updates [RFC2072]. This document also contains recommendations for application design and network management, which, if taken seriously, 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 (or "old") prefix throughout a network with a new prefix. Usually, both prefixes will be the same length. The procedures described in this document are, for the most part, equally applicable if the two prefixes are not the same length. During renumbering, sub-prefixes (or "link prefixes") from the old prefix, which have been assigned to links throughout the network, will be replaced by link prefixes from the new prefix. Interfaces on systems throughout the network will be configured with IPv6 addresses from the link prefixes of the new prefix, and any addresses from the old prefix in services like DNS [RFC1034][RFC1035] or configured into switches and routers and applications will be replaced by the appropriate addresses from the new prefix.
By "renumbering a network", we mean replacing the use of an existing (or "old") prefix throughout a network with a new prefix. Usually, both prefixes will be the same length. The procedures described in this document are, for the most part, equally applicable if the two prefixes are not the same length. During renumbering, sub-prefixes (or "link prefixes") from the old prefix, which have been assigned to links throughout the network, will be replaced by link prefixes from the new prefix. Interfaces on systems throughout the network will be configured with IPv6 addresses from the link prefixes of the new prefix, and any addresses from the old prefix in services like DNS [RFC1034][RFC1035] or configured into switches and routers and applications will be replaced by the appropriate addresses from the new prefix.
The renumbering procedure described in this document can be applied to part of a network as well as to an organization's entire network. In the case of a large organization, it may be advantageous to treat the network as a collection of smaller networks. Renumbering each of the smaller networks separately will make the process more manageable. The process described in this document is generally applicable to any network, whether it is an entire organization network or part of a larger network.
The renumbering procedure described in this document can be applied to part of a network as well as to an organization's entire network. In the case of a large organization, it may be advantageous to treat the network as a collection of smaller networks. Renumbering each of the smaller networks separately will make the process more manageable. The process described in this document is generally applicable to any network, whether it is an entire organization network or part of a larger network.
Baker, et al. Informational [Page 3] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 3] RFC 4192 Renumbering IPv6 Networks September 2005
1.2. Terminology
1.2. Terminology
DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through
the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG
[RFC2845].
DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG [RFC2845].
DHCP prefix delegation: An extension to DHCP [RFC3315] to automate
the assignment of a prefix, for example, from an ISP to a customer
[RFC3633].
DHCP prefix delegation: An extension to DHCP [RFC3315] to automate the assignment of a prefix, for example, from an ISP to a customer [RFC3633].
flag day: A transition that involves a planned service outage.
flag day: A transition that involves a planned service outage.
ingress/egress filters: Filters applied to a router interface
connected to an external organization, such as an ISP, to exclude
traffic with inappropriate IPv6 addresses.
ingress/egress filters: Filters applied to a router interface connected to an external organization, such as an ISP, to exclude traffic with inappropriate IPv6 addresses.
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
SLAC: StateLess Address AutoConfiguration [RFC2462].
SLAC: StateLess Address AutoConfiguration [RFC2462].
1.3. Summary of What Must Be Changed
1.3. Summary of What Must Be Changed
Addresses from the old prefix that are affected by renumbering will appear in a wide variety of places in the components in the renumbered network. The following list gives some of the places that may include prefixes or addresses that are affected by renumbering, and gives some guidance about how the work required during renumbering might be minimized:
Addresses from the old prefix that are affected by renumbering will appear in a wide variety of places in the components in the renumbered network. The following list gives some of the places that may include prefixes or addresses that are affected by renumbering, and gives some guidance about how the work required during renumbering might be minimized:
o Link prefixes assigned to links. Each link in the network must be
assigned a link prefix from the new prefix.
o Link prefixes assigned to links. Each link in the network must be assigned a link prefix from the new prefix.
o IPv6 addresses assigned to interfaces on switches and routers.
These addresses are typically assigned manually, as part of
configuring switches and routers.
o IPv6 addresses assigned to interfaces on switches and routers. These addresses are typically assigned manually, as part of configuring switches and routers.
o Routing information propagated by switches and routers.
o Routing information propagated by switches and routers.
o Link prefixes advertised by switches and routers [RFC2461].
o Link prefixes advertised by switches and routers [RFC2461].
o Ingress/egress filters.
o Ingress/egress filters.
o ACLs and other embedded addresses on switches and routers.
o ACLs and other embedded addresses on switches and routers.
o IPv6 addresses assigned to interfaces on hosts. Use of StateLess
Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can
mitigate the impact of renumbering the interfaces on hosts.
o IPv6 addresses assigned to interfaces on hosts. Use of StateLess Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can mitigate the impact of renumbering the interfaces on hosts.
Baker, et al. Informational [Page 4] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 4] RFC 4192 Renumbering IPv6 Networks September 2005
o DNS entries. New AAAA and PTR records are added and old ones
removed in several phases to reflect the change of prefix.
Caching times are adjusted accordingly during these phases.
o DNS entries. New AAAA and PTR records are added and old ones removed in several phases to reflect the change of prefix. Caching times are adjusted accordingly during these phases.
o IPv6 addresses and other configuration information provided by
DHCP.
o IPv6 addresses and other configuration information provided by DHCP.
o IPv6 addresses embedded in configuration files, applications, and
elsewhere. Finding everything that must be updated and automating
the process may require significant effort, which is discussed in
more detail in Section 3. This process must be tailored to the
needs of each network.
o IPv6 addresses embedded in configuration files, applications, and elsewhere. Finding everything that must be updated and automating the process may require significant effort, which is discussed in more detail in Section 3. This process must be tailored to the needs of each network.
1.4. Multihoming Issues
1.4. Multihoming Issues
In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common.
In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common.
When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the company is multihomed during such a period. Although this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document also needs to be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704].
When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the company is multihomed during such a period. Although this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document also needs to be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704].
2. Detailed Review of Procedure
2. Detailed Review of Procedure
During the renumbering process, the network transitions through eight states. In the initial state, the network uses just the prefix that is to be replaced during the renumbering process. At the end of the process, the old prefix has been entirely replaced by the new prefix, and the network is using just the new prefix. To avoid a flag day transition, the new prefix is deployed first and the network reaches an intermediate state in which either prefix can be used. In this state, individual hosts can make the transition to using the new prefix as appropriate to avoid disruption of applications. Once all
During the renumbering process, the network transitions through eight states. In the initial state, the network uses just the prefix that is to be replaced during the renumbering process. At the end of the process, the old prefix has been entirely replaced by the new prefix, and the network is using just the new prefix. To avoid a flag day transition, the new prefix is deployed first and the network reaches an intermediate state in which either prefix can be used. In this state, individual hosts can make the transition to using the new prefix as appropriate to avoid disruption of applications. Once all
Baker, et al. Informational [Page 5] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 5] RFC 4192 Renumbering IPv6 Networks September 2005
of the hosts have made the transition to the new prefix, the network is reconfigured so that the old prefix is no longer used in the network.
of the hosts have made the transition to the new prefix, the network is reconfigured so that the old prefix is no longer used in the network.
In this discussion, we assume that an entire prefix is being replaced with another entire prefix. It may be that only part of a prefix is being changed, or that more than one prefix is being changed to a single joined prefix. In such cases, the basic principles apply, but will need to be modified to address the exact situation. This procedure should be seen as a skeleton of a more detailed procedure that has been tailored to a specific environment. Put simply, season to taste.
In this discussion, we assume that an entire prefix is being replaced with another entire prefix. It may be that only part of a prefix is being changed, or that more than one prefix is being changed to a single joined prefix. In such cases, the basic principles apply, but will need to be modified to address the exact situation. This procedure should be seen as a skeleton of a more detailed procedure that has been tailored to a specific environment. Put simply, season to taste.
2.1. Initial Condition: Stable Using the Old Prefix
2.1. Initial Condition: Stable Using the Old Prefix
Initially, the network is using an old prefix in routing, device interface addresses, filtering, firewalls, and other systems. This is a stable configuration.
Initially, the network is using an old prefix in routing, device interface addresses, filtering, firewalls, and other systems. This is a stable configuration.
2.2. Preparation for the Renumbering Process
2.2. Preparation for the Renumbering Process
The first step is to obtain the new prefix and new reverse zone from the delegating authority. These delegations are performed using established procedures, from either an internal or external delegating authority.
The first step is to obtain the new prefix and new reverse zone from the delegating authority. These delegations are performed using established procedures, from either an internal or external delegating authority.
Before any devices are reconfigured as a result of the renumbering event, each link in the network must be assigned a sub-prefix from the new prefix. While this assigned link prefix does not explicitly appear in the configuration of any specific switch, router, or host, the network administrator performing the renumbering procedure must make these link prefix assignments prior to beginning the procedure to guide the configuration of switches and routers, assignment of addresses to interfaces, and modifications to network services such as DNS and DHCP.
Before any devices are reconfigured as a result of the renumbering event, each link in the network must be assigned a sub-prefix from the new prefix. While this assigned link prefix does not explicitly appear in the configuration of any specific switch, router, or host, the network administrator performing the renumbering procedure must make these link prefix assignments prior to beginning the procedure to guide the configuration of switches and routers, assignment of addresses to interfaces, and modifications to network services such as DNS and DHCP.
Prior to renumbering, various processes will need to be reconfigured to confirm bindings between names and addresses more frequently. In normal operation, DNS name translations and DHCP bindings are often given relatively long lifetimes to limit server load. In order to reduce transition time from old to new prefix, it may be necessary to reduce the time to live (TTL) associated with DNS records and increase the frequency with which DHCP clients contact the DHCP server. At the same time, a procedure must be developed through which other configuration parameters will be updated during the transition period when both prefixes are available.
Prior to renumbering, various processes will need to be reconfigured to confirm bindings between names and addresses more frequently. In normal operation, DNS name translations and DHCP bindings are often given relatively long lifetimes to limit server load. In order to reduce transition time from old to new prefix, it may be necessary to reduce the time to live (TTL) associated with DNS records and increase the frequency with which DHCP clients contact the DHCP server. At the same time, a procedure must be developed through which other configuration parameters will be updated during the transition period when both prefixes are available.
Baker, et al. Informational [Page 6] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 6] RFC 4192 Renumbering IPv6 Networks September 2005
2.2.1. Domain Name Service
2.2.1. Domain Name Service
During the renumbering process, the DNS database must be updated to add information about addresses assigned to interfaces from the new prefix and to remove addresses assigned to interfaces from the old prefix. The changes to the DNS must be coordinated with the changes to the addresses assigned to interfaces.
During the renumbering process, the DNS database must be updated to add information about addresses assigned to interfaces from the new prefix and to remove addresses assigned to interfaces from the old prefix. The changes to the DNS must be coordinated with the changes to the addresses assigned to interfaces.
Changes to the information in the DNS have to propagate from the server at which the change was made to the resolvers where the information is used. The speed of this propagation is controlled by the TTL for DNS records and the frequency of updates from primary to secondary servers.
Changes to the information in the DNS have to propagate from the server at which the change was made to the resolvers where the information is used. The speed of this propagation is controlled by the TTL for DNS records and the frequency of updates from primary to secondary servers.
The latency in propagating changes in the DNS can be managed through the TTL assigned to individual DNS records and through the timing of updates from primary to secondary servers. Appendix A gives an analysis of the factors controlling the propagation delays in the DNS.
The latency in propagating changes in the DNS can be managed through the TTL assigned to individual DNS records and through the timing of updates from primary to secondary servers. Appendix A gives an analysis of the factors controlling the propagation delays in the DNS.
The suggestions for reducing the delay in the transition to new IPv6 addresses applies when the DNS service can be given prior notice about a renumbering event. However, the DNS service for a host may be in a different administrative domain than the network to which the host is attached. For example, a device from organization A that roams to a network belonging to organization B, but the device's DNS A record is still managed by organization A, where the DNS service won't be given advance notice of a renumbering event in organization B.
The suggestions for reducing the delay in the transition to new IPv6 addresses applies when the DNS service can be given prior notice about a renumbering event. However, the DNS service for a host may be in a different administrative domain than the network to which the host is attached. For example, a device from organization A that roams to a network belonging to organization B, but the device's DNS A record is still managed by organization A, where the DNS service won't be given advance notice of a renumbering event in organization B.
One strategy for updating the DNS is to allow each system to manage its own DNS information through Dynamic DNS (DDNS) [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly recommended and can be accomplished through TSIG and SIG(0). Both TSIG and SIG(0) require configuration and distribution of keys to hosts and name servers in advance of the renumbering event.
One strategy for updating the DNS is to allow each system to manage its own DNS information through Dynamic DNS (DDNS) [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly recommended and can be accomplished through TSIG and SIG(0). Both TSIG and SIG(0) require configuration and distribution of keys to hosts and name servers in advance of the renumbering event.
2.2.2. Mechanisms for Address Assignment to Interfaces
2.2.2. Mechanisms for Address Assignment to Interfaces
IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If DHCP is used for IPv6 address assignment, there may be some delay in the assignment of IPv6 addresses from the new prefix because hosts using DHCP only contact the server periodically to extend the lifetimes on assigned addresses. This delay can be reduced in two ways:
IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If DHCP is used for IPv6 address assignment, there may be some delay in the assignment of IPv6 addresses from the new prefix because hosts using DHCP only contact the server periodically to extend the lifetimes on assigned addresses. This delay can be reduced in two ways:
Baker, et al. Informational [Page 7] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 7] RFC 4192 Renumbering IPv6 Networks September 2005
o Prior to the renumbering event, the T1 parameter (which controls
the time at which a host using DHCP contacts the server) may be
reduced.
o Prior to the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) may be reduced.
o The DHCP Reconfigure message may also be sent from the server to
the hosts to trigger the hosts to contact the server immediately.
o The DHCP Reconfigure message may also be sent from the server to the hosts to trigger the hosts to contact the server immediately.
2.3. Configuring Network Elements for the New Prefix
2.3. Configuring Network Elements for the New Prefix
In this step, switches and routers and services are prepared for the new prefix but the new prefix is not used for any datagram forwarding. Throughout this step, the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix. For example, addresses assigned from the new prefix are configured in addition to any addresses from the old prefix assigned to interfaces on the switches and routers. Changes to the routing infrastructure for the new prefix are added in parallel with the old prefix so that forwarding for both prefixes operates in parallel. At the end of this step, the network is still running on the old prefix but is ready to begin using the new prefix.
In this step, switches and routers and services are prepared for the new prefix but the new prefix is not used for any datagram forwarding. Throughout this step, the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix. For example, addresses assigned from the new prefix are configured in addition to any addresses from the old prefix assigned to interfaces on the switches and routers. Changes to the routing infrastructure for the new prefix are added in parallel with the old prefix so that forwarding for both prefixes operates in parallel. At the end of this step, the network is still running on the old prefix but is ready to begin using the new prefix.
The new prefix is added to the routing infrastructure, firewall filters, ingress/egress filters, and other forwarding and filtering functions. Routes for the new link prefixes may be injected by routing protocols into the routing subsystem, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes; in particular the "autonomous address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes. The reason hosts should not be forming addresses at this point is that routing to the new addresses may not yet be stable.
The new prefix is added to the routing infrastructure, firewall filters, ingress/egress filters, and other forwarding and filtering functions. Routes for the new link prefixes may be injected by routing protocols into the routing subsystem, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes; in particular the "autonomous address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes. The reason hosts should not be forming addresses at this point is that routing to the new addresses may not yet be stable.
The details of this step will depend on the specific architecture of the network being renumbered and the capabilities of the components that make up the network infrastructure. The effort required to complete this step may be mitigated by the use of DNS, DHCP prefix delegation [RFC3633], and other automated configuration tools.
The details of this step will depend on the specific architecture of the network being renumbered and the capabilities of the components that make up the network infrastructure. The effort required to complete this step may be mitigated by the use of DNS, DHCP prefix delegation [RFC3633], and other automated configuration tools.
While the new prefix is being added, it will of necessity not be working everywhere in the network, and unless properly protected by some means such as ingress and egress access lists, the network may be attacked through the new prefix in those places where it is operational.
While the new prefix is being added, it will of necessity not be working everywhere in the network, and unless properly protected by some means such as ingress and egress access lists, the network may be attacked through the new prefix in those places where it is operational.
Once the new prefix has been added to the network infrastructure, access-lists, route-maps, and other network configuration options that 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. Name services other than DNS and other services that provide
Once the new prefix has been added to the network infrastructure, access-lists, route-maps, and other network configuration options that 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. Name services other than DNS and other services that provide
Baker, et al. Informational [Page 8] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 8] RFC 4192 Renumbering IPv6 Networks September 2005
information that will be affected by renumbering must be updated in such a way as to avoid responding with stale information. There are several useful approaches to identify and augment configurations:
information that will be affected by renumbering must be updated in such a way as to avoid responding with stale information. There are several useful approaches to identify and augment configurations:
o Develop a mapping from each network and address derived from the
old prefix to each network and address derived from the new
prefix. Tools such as the UNIX "sed" or "perl" utilities are
useful to then find and augment access-lists, route-maps, and the
like.
o Develop a mapping from each network and address derived from the old prefix to each network and address derived from the new prefix. Tools such as the UNIX "sed" or "perl" utilities are useful to then find and augment access-lists, route-maps, and the like.
o A similar approach involves the use of such mechanisms as DHCP
prefix delegation to abstract networks and addresses.
o A similar approach involves the use of such mechanisms as DHCP prefix delegation to abstract networks and addresses.
Switches and routers or manually configured hosts that have IPv6 addresses assigned from the new prefix may be used at this point to test the network infrastructure.
Switches and routers or manually configured hosts that have IPv6 addresses assigned from the new prefix may be used at this point to test the network infrastructure.
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 defenses in place before advertising the prefix, if only because the prefix may come under immediate attack.
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 defenses in place before advertising the prefix, if only because the prefix may come under immediate attack.
At the end of this phase, routing, access control, and other network services should work interchangeably for both old and new prefixes.
At the end of this phase, routing, access control, and other network services should work interchangeably for both old and new prefixes.
2.4. Adding New Host Addresses
2.4. Adding New Host Addresses
Once the network infrastructure for the new prefix is in place and tested, IPv6 addresses from the new prefix may be assigned to host interfaces while the addresses from the old prefix are retained on those interfaces. The new IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If SLAC is used in the network, the switches and routers are configured to indicate that hosts should use SLAC to assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 address assignment, the DHCP service is configured to assign addresses from both prefixes to hosts. The addresses from the new prefixes will not be used until they are inserted into the DNS.
Once the network infrastructure for the new prefix is in place and tested, IPv6 addresses from the new prefix may be assigned to host interfaces while the addresses from the old prefix are retained on those interfaces. The new IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If SLAC is used in the network, the switches and routers are configured to indicate that hosts should use SLAC to assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 address assignment, the DHCP service is configured to assign addresses from both prefixes to hosts. The addresses from the new prefixes will not be used until they are inserted into the DNS.
Once the new IPv6 addresses have been assigned to the host interfaces, both the forward and reverse maps within DNS should be updated for the new addresses, either through automated or manual means. In particular, some clients may be able to update their forward maps through DDNS, but automating the update of the reverse zone may be more difficult as discussed in Section 4.2.
Once the new IPv6 addresses have been assigned to the host interfaces, both the forward and reverse maps within DNS should be updated for the new addresses, either through automated or manual means. In particular, some clients may be able to update their forward maps through DDNS, but automating the update of the reverse zone may be more difficult as discussed in Section 4.2.
Baker, et al. Informational [Page 9] RFC 4192 Renumbering IPv6 Networks September 2005
Baker, et al. Informational [Page 9] RFC 4192 Renumbering IPv6 Networks September 2005
2.5. Stable Use of Either Prefix
2.5. Stable Use of Either Prefix
Once the network has been configured with the new prefix and has had sufficient time to stabilize, it becomes a stable platform with two addresses configured on each and every infrastructure component interface (apart from interfaces that use only the link-local address), and two non-link-local addresses are available for the use of any host, one in the old prefix and one in the new. This is a stable configuration.
Once the network has been configured with the new prefix and has had sufficient time to stabilize, it becomes a stable platform with two addresses configured on each and every infrastructure component interface (apart from interfaces that use only the link-local address), and two non-link-local addresses are available for the use of any host, one in the old prefix and one in the new. This is a stable configuration.
2.6. Transition from Use of the Old Prefix to the New Prefix
2.6. Transition from Use of the Old Prefix to the New Prefix
When the new prefix has been fully integrated into the network infrastructure and has been tested for stable operation, hosts, switches, and routers can begin using the new prefix. Once the transition has completed, the old prefix will not be in use in the network.
When the new prefix has been fully integrated into the network infrastructure and has been tested for stable operation, hosts, switches, and routers can begin using the new prefix. Once the transition has completed, the old prefix will not be in use in the network.
2.6.1. Transition of DNS Service to the New Prefix
2.6.1. Transition of DNS Service to the New Prefix
The DNS service is configured to use the new prefix by removing any IPv6 addresses from the old prefix from the DNS server configuration. External references to the DNS servers, such as in the DNS service from which this DNS domain was delegated, are updated to use the IPv6 addresses from the new prefix.
The DNS service is configured to use the new prefix by removing any IPv6 addresses from the old prefix from the DNS server configuration. External references to the DNS servers, such as in the DNS service from which this DNS domain was delegated, are updated to use the IPv6 addresses from the new prefix.
2.6.2. Transition to Use of New Addresses
2.6.2. Transition to Use of New Addresses
When both prefixes are usable in the network, each host can make the transition from using the old prefix to the new prefix at a time that is appropriate for the applications on the host. If the host transitions are randomized, DNS dynamic update mechanisms can better scale to accommodate the changes to the DNS.
When both prefixes are usable in the network, each host can make the transition from using the old prefix to the new prefix at a time that is appropriate for the applications on the host. If the host transitions are randomized, DNS dynamic update mechanisms can better scale to accommodate the changes to the DNS.
As services become available through addresses from the new prefix, references to the hosts providing those services are updated to use the new prefix. Addresses obtained through DNS will be automatically updated when the DNS names are resolved. Addresses may also be obtained through DHCP and will be updated as hosts contact DHCP servers. Addresses that are otherwise configured must be updated appropriately.
As services become available through addresses from the new prefix, references to the hosts providing those services are updated to use the new prefix. Addresses obtained through DNS will be automatically updated when the DNS names are resolved. Addresses may also be obtained through DHCP and will be updated as hosts contact DHCP servers. Addresses that are otherwise configured must be updated appropriately.
It may be necessary to provide users with tools or other explicit procedures to complete the transition from the use of the old prefix to the new prefix, because some applications and operating system functions may be configured in ways that do not use DNS at all or will not use DNS to resolve a domain name to a new address once the new prefix is available. For example, a device that only uses DNS to
古い接頭語の使用から新しい接頭語までの変遷を終了するためにツールか他の明白な手順をユーザに提供するのが必要であるかもしれません、いくつかのアプリケーションとオペレーティングシステム機能がDNSを全く使用しないか、または新しい接頭語がいったん新しい住所に利用可能になるとドメイン名を決議するのにDNSを使用しない方法で構成されるかもしれないので。 例えば、それがDNSを使用するだけであるデバイス
Baker, et al. Informational [Page 10] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[10ページ]のRFC4192
resolve the name of an NTP server when the device is initialized will not obtain the address from the new prefix for that server at this point in the renumbering process.
デバイスがここに初期化されるとき、NTPサーバの名前が番号を付け替えるプロセスで新しい接頭語からアドレスをそのサーバとして得ないと決議してください。
This last point warrants repeating (in a slightly different form). Applications may cache addressing information in different ways, for varying lengths of time. They may cache this information in memory, on a file system, or in a database. Only after careful observation and consideration of one's environment should one conclude that a prefix is no longer in use. For more information on this issue, see [DNSOP].
この最後のポイントは、繰り返すのを(わずかに異なったフォームで)保証します。 アプリケーションは異なった長さの時間の異なった方法でアドレス指定情報をキャッシュするかもしれません。 彼らはファイルシステムの上、または、メモリか、データベースでこの情報をキャッシュするかもしれません。 人の環境の慎重な観測と考慮の後にだけ接頭語がもう使用中でないと結論を下すべきです。 この問題の詳しい情報に関しては、[DNSOP]を見てください。
The transition of critical services such as DNS, DHCP, NTP [RFC1305], and important business services should be managed and tested carefully to avoid service outages. Each host should take reasonable 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.
重要にDNSや、DHCPや、NTP[RFC1305]や、重要な商用サービスなどのサービスの変遷は、サービス供給停止を避けるために慎重に管理されて、テストされるべきです。 各ホストは失意の接続の機会を最小にするために新しい接頭語の使用に変化する前に、合理的な注意を払うべきです。 例えば、何かホストとの既存の接続がそのホストにまだ古い接頭語からのアドレスを使用しているかどうか決定するのにnetstatやネットワークアナライザなどのユーティリティを使用できます。
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.
ルータ通知における古い接頭語から接頭語をリンクしてください。そうすれば、ここにDHCPを通して提供された古い接頭語からのアドレスで彼らの都合のよい生涯をゼロに決めるべきです、ホストが新しいコミュニケーションに古い接頭語を使用しないように。
2.7. Removing the Old Prefix
2.7. 古い接頭語を取り除きます。
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.
かつて、セッションでそこに完成すると考えられるすべてが古い接頭語へのどんな依存にもならないでしょう。 ルーティングシステムの構成とどんな静的な構成からもそれに依存するそれを取り除くかもしれません。 DNS情報に基づいて何か構成を作成したなら、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.
この段階の間、古い接頭語はプロバイダーかRegionalインターネットによって開墾されて、それがその接頭語の中でそれ、およびアドレスを与えたRegistryが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).
さらに、プライマリネームサーバから古い接頭語のためのDNSの逆の地図を取り外すかもしれません、そして、親ゾーンからゾーン委譲を取り除くかもしれません。 変えられたいずれもDNS、DHCP、またはSLACタイマがそれらの元の値(最も著しくDNSの前進の地図TTL)にリセットされるべきです。
2.8. Final Condition: Stable Using the New Prefix
2.8. 最終的な状態: 新しい接頭語を使用するうまや
This is equivalent to the first state, but using the new prefix.
これは、最初の状態に同等であり、新しい接頭語を使用しています。
Baker, et al. Informational [Page 11] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[11ページ]のRFC4192
3. How to Avoid Shooting Yourself in the Foot
3. 自ら災いを招くのを避ける方法
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.
ネットワーク管理者のコントロールの下にないか、または手動で構成されるルータとホストの構成に対処するのにおいてセクション2.3、セクション2.6、およびセクション2.7の難しい操作上の問題があります。 そのようなデバイスに関する例はブーツかネームサーバの静的な構成があるボイス・オーバー IP(VoIP)電話、特定のサービスのためのIPアドレスがある構成された製造の中古である専用デバイス、ルータとスイッチのブート・サーバーなどを含んでいます。
3.1. Applications Affected by Renumbering
3.1. 番号を付け替えることによって影響を受けるアプリケーション
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.
アプリケーションはうっかりDNS解決で得るIPアドレスに関連している意味論をキャッシュするDNSを無視するかもしれません。 結果は長命のアプリケーションが、そのアドレスのためのTTLが期限が切れた時聞き古したIPアドレスを使用し続けるかもしれないということです、番号を付け替えるイベントの間、新しいアドレスでDNSをアップデートしても。
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()).
例えば、多くの既存のアプリケーションがgetaddrinfo()などの標準のPOSIX機能を利用します。(機能は意味論をキャッシュするDNSを保存しません)。 アプリケーションが応答をキャッシュするか、またはアプリケーションに応答のためのTTLがいつ期限が切れたかを知る方法が全く実際に応答をディスクに記録するいかなる理由でもないなら。 繰り返された使用にIPアドレスを要求するどんなアプリケーションも、結果をキャッシュするべきではありませんし、またまた、記録のTTLを運ぶ適切な機能を利用するべきではありません。(例えば、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.
アプリケーション設計者、設備ベンダー、およびオープンSource共同体はノートを取るべきです。 この領域で彼らの顧客によく役立つ機会があって、ネットワーク・オペレータは、適切なツールを開発するべきであるか、または購入するべきです。
3.2. Renumbering Switch and Router Interfaces
3.2. スイッチとルータインタフェースに番号を付け替えさせます。
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.
スイッチとルータの構成と操作は、要素が再開されるまで、IPアドレスがある静的な構成を使用するか、一度だけドメイン名を決議して、または結果として起こるIPアドレスを使用するようにしばしば設計されています。 これらの静的な構成は番号を付け替えることのプロセスを複雑にします、番号を付け替えるイベントの間、静的な情報と手動の構成のすべてを管理に要求して。
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
スイッチとルータが通常ただ一つの目的デバイスであるので、ユーザーインタフェースと操作機能(ソフトウェアとハードウェア)はしばしばサーバプラットホームで走る独立しているサービスよりよく統合しています。 したがって、それがベンダーとルータベンダーを切り換えるのは、ありそうです。
Baker, et al. Informational [Page 12] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[12ページ]のRFC4192
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.
サポートの番号を付け替えるほうがよいのに、スイッチとルータは構成にどこでも、適切であるところでドメイン名を使用するべきです、そして、彼らは名前の寿命が期限が切れるとDNSを使用することでそれらの名前を決議するべきです。
3.3. Ingress Filtering
3.3. イングレスフィルタリング
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].
セクション2.3、番号を付け替えられるネットワークが外部のプロバイダーに接続される場合における重要な考慮すべき事柄は、ネットワークのイングレスフィルタリング方針とプロバイダーのイングレスフィルタリング方針です。 ネットワークへのアクセスリンクのネットワークファイアウォールのイングレスフィルタとプロバイダーのイングレスフィルタの両方が、ソースアドレススプーフィングを使用する攻撃を防ぐために構成されるべきです。 イングレスフィルタリングは「Multihomedのためにネットワークをフィルターにかけるイングレス」[RFC3704]で詳細に考えられます。
3.4. Link Flaps in BGP Routing
3.4. BGPルート設定におけるリンクフラップ
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.
BGPルータを命名するのに使用されるアドレス(es)に番号を付け替えさせるとき、微妙なケースはステップ2の間、BGPルーティングで起こります。 2つの習慣が一般的です: 1つはループバックアドレスなどの安定したアドレスでBGPルータを特定することになっています。 別のものは、BGP同輩に面しながら、インターフェース・アドレスを使用することになっています。 新しい接頭語を加えるとき、その都度、あるあいまいさは加えられます: システムはアドレスを選ばなければなりません、そして、彼らがどう選ぶかによって、異なったイベントは起こることができます。
o If the existing address remains in use until removed, then this is
minimized to a routing flap on that event.
o 既存のアドレスが取り除くまで使用中であり残っているなら、これはそのイベントでルーティングフラップに最小にされます。
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 両方のシステムが、同時に新しい接頭語にアドレスを使用すると決めるなら、リンクフラップはプロセスと自動的にこれをするかどうかにおいて(プロトコルに番号を付け替えさせるルータを通したなど)より早く起こるかもしれなくて、それはネットワーク中でルートフラップをもたらすかもしれません。
o If the two systems choose differently (one uses the old address
and one uses the new address), a stable routing outage occurs.
o 2台のシステムが異なって選ばれるなら(1つは旧住所を使用します、そして、1つは新しいアドレスを使用します)、安定したルーティング供給停止は起こります。
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.
これは[IDR-RESTART]などの提案で扱われません、システムの「名前」を変えるとき、その件を既存の関係におけるフラップの1つではなく、別のものとの1人のルーティング隣人の(BGPの見解からの)交換にして。 理想的に、老人に新しいアドレスのための安定して使用中の古い残りである間の新しいBGP接続で持って来て、次に、取るだけであるべきです。 この様に、TCP接続フラップがありますが、ルーティングは安定した状態を保ちます。
Baker, et al. Informational [Page 13] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[13ページ]のRFC4192
4. Call to Action for the IETF
4. 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
4.1. 管理ドメイン中のDNSへのダイナミックなアップデート
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.
DNSサーバ(named.confなどの)のための構成ファイルは番号を付け替えるイベントの間に手動で再構成しなければならないアドレスを含むでしょう。 現在、これらのアドレスのアップデートを自動化するどんな簡単な方法もありません、アップデートがそれらについて確かめるために複合信託関係とオートメーションの両方を必要とするとき。 例えば、上流のISPで逆のゾーンを代表として派遣しますが、現在、追加委譲に注意するために、メカニズムは全くありません。
4.2. Management of the Reverse Zone
4.2. 逆のゾーン管理
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.
ホストがSLACを通してIPv6アドレスを得るネットワークでは、逆のゾーンのアップデートは接頭語を所有している管理ドメインとSLACを使用することで低64ビットを割り当てるホストとの信頼関係の不足のために問題が多いです。 例えば、組織Aからのホスト、Hが組織B.によって所有されていたネットワークに関連づけられると仮定してください。When Hは番号を付け替えるイベントの間、SLACを通して新しいアドレスを得て、Hは、DNSサーバを通してDNSで新しいアドレスのための逆のゾーンを所有しているBから逆のエントリーをアップデートする必要があるでしょう。 Hが逆のエントリーをアップデートするように、BからのDNSサーバはHからDDNS要求を受け入れなければならなくて、相互管理のドメイン信頼関係がB. HとIETFの間に存在するのが必要であるのがこのその問題を訴えるためのBCP推薦を開発するべきです。
5. Security Considerations
5. セキュリティ問題
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.
番号を付け替えることのプロセスは、実際には理論上簡単ですが、難しくて、危険である場合があります。 脅威は2つの広いカテゴリになります: misconfigurationから起こるものと実際の攻撃であるそれら。
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:
ネットワークにおけるどんなシステムもそれで先験的に古い接頭語、またはアドレスを「知っ」て、新しい接頭語によって構成されないか、または新しい接頭語がしばらくそれへの存在同等のものの代わりに老人を取り替える方法で構成されるなら、Misconfigurationsは容易に起こることができます。 安易な例は以下を含んでいます:
Baker, et al. Informational [Page 14] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[14ページ]のRFC4192
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.
IPv6アドレスでシステムを構成して、その旧住所を新しいアドレスに取り替えます: TCP接続が古くて現在無効のIPv6アドレスを使用しているので、SSHセッションは終えられるでしょう、そして、あなたは追加構成変更に新しいアドレスを通ってSSHを使用しなければならないでしょう。
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.
明確に、新しい接頭語を構成に加えるには延長時間がかかって、ネットワークに決着をつけるのを許容して、次に、老人を取り除くと、このクラスの問題は取り除かれます。 いくつかのデバイスが時折使用されるだけであるとき、特別の配慮は適用されます。 管理は、セクション2.6に十分な長さの時間を許容しなければならないか、またはそれらの検出の見込みが確実に十分高くなるようにするために他の検証手続を適用しなければなりません。
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.
DNSがアクセスコントロールリストと同様のセキュリティかQoS構成に居住するのに使用されるとき、このタイプの微妙なケースは結果として生じることができます。 対応するアドレスは、DNS名が以前はシステムかサービス名の間でよく翻訳されていて、都合のよい接頭語のアドレスを提供するとしてこの手順で扱われますが、ともに扱われるというわけではありません。接頭語は古いか新しい接頭語です。 そのようなDNS名は手段を提供します、ネットワークにおけるシステムが、サーバか同輩にアクセスして、彼らが新しい接頭語を使用し始めることを引き起こすのに古い接頭語を使用するのを止めることを引き起こすためにセクション2.6で説明されるように。 しかしながら、アクセスコントロールリストに使用されるDNS名は、他のアクセスコントロールリストのために同じ3ステップの実行した手順に直面する必要があります、セクション2.7で議論するようにセクション2.3で議論するようにそれらに加えられた新しい接頭語と古い接頭語を取り除かせて。
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.
このようにおけるDNS名の使用がソリューションとして一般にこの問題に認められないことに注意されるべきです。 [RFC3871]は静的IPアドレスがDNS名より好まれるケースに特に注意します、命名システムが近づきがたいか、ルックアップの結果がいくつかのインタフェースかシステムの1つであるときに、名前ルックアップを避けるために。そのような場合、適切に番号を付け替えることを管理するために付加的な注意を払わなければなりません。
Attacks are also possible. Suppose, for example, that the new prefix has been presented by a service provider, and the service provider
また、攻撃も可能です。 例えば、新しい接頭語がサービスプロバイダー、およびサービスプロバイダーによって提示されたと仮定してください。
Baker, et al. Informational [Page 15] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[15ページ]のRFC4192
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.
顧客ネットワークが準備ができる前に接頭語の広告を出す始め。 新しい接頭語が分散DoS攻撃で狙うかもしれませんか、または古い接頭語を使用することでファイアウォールを越えないアプリケーションを使用することでシステムは侵入されるかもしれません、ネットワークのディフェンスが構成される前に。 次にだけ最初にディフェンスを構成する明確に1個の必需品とアクセシビリティとセクション2.3とセクション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.
[RFC2462]で説明されたSLAC手順はホストに番号を付け替えさせます。 ダイナミックなDNSはそれに従って、DNSをアップデートするのに能力を提供します。 それらをすべてそのようなすべての構成が中央の構成倉庫かデータベースから生成されるか、一時的なデータベースから読み取って、適切なスクリプトを使用することで変えられて、または適切なシステムに適用できるなら、それらの手順は別としてコンフィギュレーション品目を管理するのは明らかに最も簡単です。手動で、原稿を書かれた構成管理が可能でないか、または使用されていないどんな場所も追跡されて、管理しなければなりません。 ここと、そこに、いてください。竜。
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.
「マルチ-家へ帰」っているネットワークのイングレスフィルタリングでは、セクション3.3で提起された問題の容易な解決は、「マルチ-家へ帰」っている顧客のためにイングレスフィルタリングをするべきではありませんし、またそのイングレスフィルタリングが特別にケースに入れるべきであることを勧めるかもしれません。 しかしながら、これはインターネットセキュリティに影響を与えます。 十分なレベルのイングレスフィルタリングが、偽造しているソースアドレスを使用することで攻撃を防ぐのに必要です。 別の問題はイングレスフィルタリングを難しく(例えば、それをするあらゆるISPで特別なケーシングを必要とするのによる)し過ぎるなら、全くISPでそれをしないかもしれないという事実から来ます。 したがって、チェックをフィルターにかける寛げるイングレスによるどんなメカニズムも極端な注意で対処されるべきです。
6. Acknowledgements
6. 承認
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.
このドキュメントがIETFリストに議論から生えました。 ドキュメントの論評はビル・フェナー、クリスチャンのHuitema、クレイグHuegen、ダンWing、フレッド・テンプリン、ハンス・クルーゼ、ハラルドTveit Alvestrand、IljitschバンBeijnum、ジェフ・ウェルズ、ジョンSchnizlein、ローラン・ニコラス、マイケル・トーマス、ミシェル・ピー、Ole Troan、ペッカSavola、ピーターElford、ローランド・ドビンズ、スコット・ブラドナー、ショーンConvery、およびトニー・ハインから来ました。
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
クリスチャンのHuitema、ペッカSavola、およびIljitschバンBeijnumは問題をフィルターにかけるイングレスについて説明しました。 これらは別々に[RFC3704]に進んでいました。(それは、そうするだれにも、読み込まれて、解釈されるべきです)。
Baker, et al. Informational [Page 16] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[16ページ]のRFC4192
temporarily or permanently create a multihomed network by renumbering from one provider to another.
一時的か永久に、1つのプロバイダーから別のプロバイダーまで番号を付け替えることによって、「マルチ-家へ帰」っているネットワークを創設してください。
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".
さらに、6NET共同体(著しくアラン・フォード、バーナード・ツイ、クリスチャンのシルド、グラハム・ホームズ、Gunterバン・デ・ベルデ、マークトンプソン、ニックLamb、スティVenaas、ティムChown、およびティナStrauf)は、手順をテストするのを引き受けました。 そのテストのいくつかの結果が即座の意味について手順に見えたようにここに記録されました。 また、6NETはそれ自身の「学習されたレッスン」を記録するでしょう。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
January 1997.
[RFC2072] バーコウィッツ、H.、「ガイドに番号を付け替えさせるルータ」、RFC2072、1997年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[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.
[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
7.2. Informative References
7.2. 有益な参照
[Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D.
Brodie, "On War, Chapter VII, 'Friction in War'", June
1989.
C.とハワード、M.、パレット、P.とD.ブローディ、「戦争、章VIIでは、'摩擦は中で戦争する'」1989年6月の[クラウゼビッツ]フォン・クラウゼビッツ。
Baker, et al. Informational [Page 17] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[17ページ]のRFC4192
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress, October 2004.
[DNSOP] 「IPv6 DNSの操作上の問題と問題」というジュランド、A.、Ihren、J.、およびP.Savolaは進歩、2004年10月に働いています。
[IDR-RESTART] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and
E. Chen, "Graceful Restart Mechanism for BGP", Work in
Progress, June 2004.
[IDR-再開] 「BGPのための優雅な再開メカニズム」というサーングリ、S.、Rekhter、Y.、フェルナンド、R.、Scudder、J.、およびE.チェンは進行中(2004年6月)で働いています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1995] 太田、M.、「DNSの増加のゾーン転送」、RFC1995、1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]Vixie、P.、「ゾーン変化(DNSは通知する)の迅速な通知のためのメカニズム」、RFC1996、1996年8月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[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.
[RFC2827] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000.
2000年の[RFC2931]イーストレークD.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 9月3日。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABとIESG、「サイトへのIPv6アドレス配分のIAB/IESG推薦」、RFC3177、2001年9月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
[RFC3633] TroanとO.とR.Droms、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
[RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
[RFC3871] ジョーンズ、G.、「大きいインターネットサービスプロバイダ(ISP)IPネットワークインフラのための操作上のセキュリティ要件」、RFC3871、2004年9月。
Baker, et al. Informational [Page 18] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[18ページ]のRFC4192
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
Baker, et al. Informational [Page 19] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[19ページ]のRFC4192
Appendix A. Managing Latency in the DNS
DNSで潜在を管理する付録A.
The procedure in this section can be used to determine and manage the latency in updates to information a DNS resource record (RR).
DNSリソースが記録する情報(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 わざわざ管理者がそれが変更を行う。
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 わざわざすぐにアップデートするのではなく、一定の間隔で、代理人をアップデートするだけであるならそれがDNSアップデートを待つかもしれない。 そして
o the time the updating to all the secondaries takes.
o すべての代理人へのアップデートがかかる時間。
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.
NOTIFY[RFC1996]とIXFR[RFC1995]の移す使用がプライマリDNSサーバからどんなセカンダリサーバまでも情報をアップデートしたと仮定してください。 これは非常に迅速な更新処理です、そして、情報のアップデートへの実際の時間は重要であると考えられません。
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.
目標時間、TCがあります。そこでは、DNS RRのコンテンツを変えたいと思います。 RRは現在、TTL=TTLOLDによって構成されます。 RRのどんなキャッシュされた参照も将来、TTLOLDほど期限が切れないでしょう。
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.
時間TC--(TTLOLD+TTLNEW)、TTLNEW(TTLNEW<TTLOLD)によって予備選挙によるRRは構成されます。 更新処理は、代理人にRRを押すために着手されます。 アップデートの後に、TTLNEWと共にRRのための質問への応答を返します。 まだ、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.
時間TC--TTLNEW、予備選挙によるRRは新しいアドレスによって構成されます。 更新処理は、代理人にRRを押すために着手されます。 アップデートの後に、RRのための質問への応答は新しいアドレスを返します。 すべてのキャッシュされた参照には、TTLNEWがあります。 今回とTCの間に、旧住所か新しいアドレスのどちらかと共にRRのための質問への応答を返すかもしれません。 ホストが両方のアドレスに応じるために構成されると仮定して、このあいまいさは許容できます。
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.
時間TCのときに、旧住所によるすべてのキャッシュされた参照が期限が切れました、そして、すべてのその後の質問が新しいアドレスを返すでしょう。 TC(セクション2.8で説明された最終的な状態に対応する)の後に、RRの上のTTLは初期の値のTTLOLDに用意ができることができます。
The network administrator can choose TTLOLD and TTLNEW to meet local requirements.
ネットワーク管理者は、地方の必要条件を満たすためにTTLOLDとTTLNEWを選ぶことができます。
Baker, et al. Informational [Page 20] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[20ページ]のRFC4192
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.
具体的な実例として、TTLOLDが1週間(168時間)とTTLNEWであるケースが1時間であると考えてください。 アドレスの変化のための準備はアドレス変化の169時間前で始まります。 168時間が経過して、ほんの1時間がことになった左では、TTLNEWがいたる所に伝播して、1つがアドレス記録を変えることができるという後に。 これらは時間中に伝播されます。その時、1つはTTL値をより大きい値に回復できます。 DNSからどういう(アドレス)情報を返すかが不確実であるところでこのアプローチは時間を最小にします。
Authors' Addresses
作者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
デル・レイカリフォルニア93117サンタバーバラ(米国)経由でフレッドベイカーシスコシステムズ1121
Phone: 408-526-4257 Fax: 413-473-2403 EMail: fred@cisco.com
以下に電話をしてください。 408-526-4257 Fax: 413-473-2403 メールしてください: fred@cisco.com
Eliot Lear Cisco Systems GmbH Glatt-com 2nd Floor CH-8301 Glattzentrum Switzerland
リアシスコシステムズGmbHグラット-com第2エリオット床のCH-8301 Glattzentrumスイス
Phone: +41 1 878 9200 EMail: lear@cisco.com
以下に電話をしてください。 +41 1 878 9200はメールされます: lear@cisco.com
Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 US
ラルフDromsシスコシステムズ200ビーバーブルック道路Boxborough、MA01719米国
Phone: +1 978 936-1674 EMail: rdroms@cisco.com
以下に電話をしてください。 +1 978 936-1674 メールしてください: rdroms@cisco.com
Baker, et al. Informational [Page 21] RFC 4192 Renumbering IPv6 Networks September 2005
ベイカー、他 2005年9月にIPv6ネットワークに番号を付け替えさせる情報[21ページ]のRFC4192
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baker, et al. Informational [Page 22]
ベイカー、他 情報[22ページ]
一覧
スポンサーリンク
