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
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、1つのプレフィックスから別のネットワークの番号を変更するために使用することができます手順を説明します。それは「作る・ビフォア・ブレイク」の移行だけでなく、アドレスの命名および構成管理の問題を介してネットワークサービスの継続性を提供するために、ネットワーク・インターフェースに複数のアドレスを割り当てるためのIPv6の固有の能力を使用しています。また、古い接頭辞から新しい接頭辞への移行を完了するのに必要な労力と時間を最小限にするために、他のIPv6機能を使用しています。
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
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.
プロイセン軍の理論家カール・フォン・クラウゼヴィッツ[クラウゼヴィッツ]はすべてが戦争で非常に簡単ですが、最も簡単な事は困難である。これらの困難が蓄積し、だれが戦争を見ていない、正確に誰が想像もできない摩擦を生み出す」、書いた....だから、戦争で、適切に紙の上に記述することはできません「ささいな状況の無限大」の影響を受けて、「物事は私たちを失望、我々はマークの及ばない。動作するネットワークが適切に戦争を行うと比較されます。違いは、相手がホモ盲がインテリジェントに動作することを無益な期待を持っていることです。
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.
このドキュメントは、「フラグの日」なしでのIPv6 [RFC2460]ネットワークを再番号付けに重要な手続き上の問題に対処しています。手順が記述することは簡単であるが、運用による一つが適切に「ささいな状況の無限」として記述可能性が静的に構成されたネットワーク状態の問題に自動化又は実行することが困難であることができます。結果として、特定の地域では、ネットワーク環境が大きく変化したように、この手順は、必ずしも不完全であり、誰も解決策は、すべてのフィットしません。これは、複数のアプローチがある多くの地域のいくつかを指摘しています。このドキュメントの更新[RFC2072]。この文書はまた、真剣に服用すれば、アプリケーションの設計およびネットワーク管理のための提言を、含まれている問題の影響を回避または最小限に抑えることができます。
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.
「ネットワークのリナンバリング」によって、我々は新しい接頭辞でネットワーク全体の既存の（または「古い」）の接頭辞の使用を置き換えることを意味します。通常、両方のプレフィックスが同じ長さになります。 2つのプレフィックスが同じ長さでない場合は、この文書に記載された手順は、大部分は、同様に適用可能です。リナンバリング時には、サブプレフィックス（または「リンクプレフィックス」）ネットワーク全体のリンクに割り当てられている古いプレフィックスからは、新しいプレフィックスからリンクプレフィックスに置き換えられます。ネットワーク全体のシステムのインターフェイスは[RFC1034] [RFC1035]またはスイッチやルータやアプリケーション内に構成が置き換えられます新しいプレフィックスのリンクプレフィックス、およびDNSのようなサービスでは、古いプレフィックスから任意のアドレスからIPv6アドレスで構成されます新しいプレフィックスから適切なアドレス。
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.
この文書で説明したリナンバリング手順は、ネットワークの一部にだけでなく、組織のネットワーク全体に適用することができます。大規模な組織の場合には、より小さなネットワークの集合としてネットワークを治療するために有利であり得ます。小さなネットワークのそれぞれの番号を変更することは別にプロセスをより管理しやすくなります。この文書に記載された方法は、組織全体のネットワークまたはより大きなネットワークの一部であるかどうか、任意のネットワークに適用可能です。
DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured through the use of SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG [RFC2845].
DDNS：ダイナミックDNS [RFC2136]、[RFC3007]の更新がSIG（0）[RFC4033]、[RFC4034]、[RFC4035]、[RFC2931]と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のプレフィックス委譲：ISPから顧客[RFC3633]に、たとえば、プレフィックスの割り当てを自動化するDHCPの拡張[RFC3315]。
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.
入力/出力フィルタ：フィルタは不適切なIPv6アドレスを持つトラフィックを除外するために、ISPなど、外部機関に接続されたルータインターフェイスに適用されます。
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
リンクプレフィックス：リンクに割り当てられたプレフィックス、通常/ 64 [RFC3177]。
SLAC: StateLess Address AutoConfiguration [RFC2462].
SLAC：ステートレスアドレス自動設定[RFC2462]。
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リンクプレフィックス。ネットワーク内の各リンクは、新しいプレフィックスからのリンクのプレフィックスを割り当てる必要があります。
o IPv6 addresses assigned to interfaces on switches and routers. These addresses are typically assigned manually, as part of configuring switches and routers.
スイッチおよびルータ上のインターフェイスに割り当てられたIPv6アドレスO。これらのアドレスは、典型的には、スイッチやルータの設定の一部として、手動で割り当てられています。
o Routing information propagated by switches and routers.
Oスイッチおよびルーターによって伝播情報をルーティング。
o Link prefixes advertised by switches and routers [RFC2461].
スイッチおよびルータ[RFC2461]によってアドバタイズOリンクプレフィックス。
o Ingress/egress filters.
O入力/出力フィルタ。
o ACLs and other embedded addresses on switches and routers.
ACLとスイッチおよびルータ上の他の埋め込まれたアドレスO。
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.
ホスト上のインターフェイスに割り当てられたIPv6アドレスO。ステートレスアドレス自動設定（SLAC）[RFC2462]またはDHCP [RFC3315]を使用することは、ホスト上のインターフェイスをリナンバリングの影響を軽減することができます。
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エントリ。新しいAAAAとPTRレコードが追加され、古いものは、プレフィックスの変更を反映するために、いくつかの段階で除去されます。キャッシュ時間は、これらのフェーズに応じて調整されています。
o IPv6 addresses and other configuration information provided by DHCP.
DHCPが提供するIPv6アドレスおよびその他の構成情報、O。
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.
他の場所の設定ファイル、アプリケーション、およびに埋め込まれたIPv6アドレスO。更新されなければならないすべてのものを発見し、プロセスを自動化することは、このプロセスは、各ネットワークのニーズに合わせて調整する必要があります第3節で詳しく説明されて多大な労力を必要とする可能性があります。
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.
提示の配慮に加えて、マルチホーミングの運用の問題に対処する必要があるかもしれません。ネットワークは、一般的に3つのいずれかの理由で再番号付けされています。ネットワーク自体がそのアドレス指定のポリシーを変更して、新しいポリシーを実装するために番号を付け直す必要があります（たとえば、会社が買収されており、その新しい所有者によって使用されるものにアドレスを変更している）、上流のプロバイダは、その接頭辞を変更しましたし、その顧客は、同時に、そうすることを余儀なくされている、または会社がプロバイダを変更され、新しいプロバイダーによって割り当てられ、使用アドレスをPERFORCEの必要があります。第三のケースが一般的です。
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].
同社は、プロバイダを変更すると、両方のプロバイダによって提供されている間、オーバーラップ期間を提起するのが一般的です。定義によると、同社はこの期間中にマルチホームです。この文書はそれ自体マルチホーミングに関するものではありませんが、問題は、上流プロバイダまたはその上流プロバイダのいずれかによって適用さイングレスフィルタリングポリシーの結果として生じることができますので、このドキュメントの使用者は、これらの問題を認識する必要があります。これは詳細に説明され、それに対処するアプローチは、[RFC2827]及び[RFC3704]に記載されています。
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 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.
リナンバリング処理中に、ネットワークは、8つの状態を経て移行します。初期状態では、ネットワークは、リナンバリング処理中に置き換えられるだけのプレフィックスを使用しています。プロセスの終了時に、古いプレフィックスは完全に新しい接頭辞に置き換えられている、とのネットワークはちょうど新しい接頭辞を使用しています。フラグ日遷移を回避するために、新たなプレフィックスが最初に配備され、ネットワークプレフィックスのいずれかを使用することができる中間状態に到達します。この状態では、個々のホストは、アプリケーションの中断を回避するために、必要に応じて新しい接頭辞を使用してへの移行を行うことができます。すべてのホストが新しいプレフィックスへの移行を行った後、古いプレフィックスがネットワークで使用されなくなったように、ネットワークを再構成されません。
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.
この議論では、我々は全体のプレフィックスが別の全体のプレフィックスに置き換えられていることを前提としています。これは、接頭辞の一部のみが変更され、またはそれ以上の接頭辞が単一接合接頭辞に変更されていることであってもよいです。このような場合には、基本的な原則が適用されますが、正確な状況に対処するために変更する必要があります。この手順は、特定の環境に合わせてきた、より詳細な手順の骨格と見られるべきです。簡単に言えば、今シーズンは、味に。
Initially, the network is using an old prefix in routing, device interface addresses, filtering, firewalls, and other systems. This is a stable configuration.
最初に、ネットワークは、ルーティング、デバイスインターフェイスアドレス、フィルタリング、ファイアウォール、およびその他のシステムの古いプレフィックスを使用しています。これは安定した構成です。
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.
任意のデバイスがリナンバリングイベントの結果として再構成されている前に、ネットワーク内の各リンクは、新しいプレフィックスからサブプレフィックスを割り当てる必要があります。この割り当てられたリンクの接頭辞が明示的に特定のスイッチ、ルータ、またはホストの設定には表示されませんが、リナンバリングの手順を実行するネットワーク管理者が割り当て、前にスイッチやルータの設定を案内するための手順を開始するには、これらのリンクのプレフィックスの割り当てを行う必要がありますDNSや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.
前リナンバリングに、様々なプロセスは、より頻繁に名前とアドレスの間のバインディングを確認するために再構成する必要があります。通常の操作では、DNS名の翻訳、DHCPバインディングは、多くの場合、サーバーの負荷を制限するために、比較的長い寿命を与えています。新しいプレフィックスに古いからの遷移時間を短縮するためには、DNSレコードに関連付けられた生存時間（TTL）を削減し、DHCPクライアントがDHCPサーバーに連絡する頻度を増やす必要があります。同時に、手順は、他の構成パラメータは、両方のプレフィックスが利用可能である遷移期間中に更新され、それを通して開発しなければなりません。
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.
リナンバリング処理中に、DNSデータベースは、新しいプレフィックスからインターフェイスに割り当てられたアドレスについての情報を追加すると、古いプレフィックスからのインターフェイスに割り当てられたアドレスを削除するように更新する必要があります。 DNSへの変更は、インターフェイスに割り当てられたアドレスへの変更と調整する必要があります。
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.
DNS内の情報への変更は、変更は情報が使用されているレゾルバに行われた時にサーバから伝播しなければなりません。この伝播速度は、DNSレコードのTTL一次から二次サーバへの更新の頻度によって制御されます。
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.
DNSの変更を伝播する際の待ち時間は、個々のDNSレコードに、プライマリからセカンダリサーバへの更新のタイミングによって割り当てられたTTLを介して管理することができます。付録Aは、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.
DNSサービスがリナンバリングイベントに関する予告を与えることができたときに新しいのIPv6アドレスへの移行の遅延を低減させるための提案が適用されます。ただし、ホストのDNSサービスは、ホストが接続されているネットワークとは異なる管理ドメインであってもよいです。たとえば、組織Bに属するネットワークにローミングする組織Aからデバイスが、デバイスのDNSは、レコードがまだDNSサービスは、組織Bにリナンバリングイベントの事前通知を与えられません組織A、によって管理されています
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.
DNSを更新するための1つの戦略は、各システムは、ダイナミックDNS（DDNS）[RFC2136]、[RFC3007]を介して、自身のDNS情報を管理できるようにすることです。これらDDNS更新の認証が強く推奨され、TSIGとSIG（0）を介して達成することができます。両方のTSIGとSIG（0）リナンバリングイベントの事前に構成し、ホストとネームサーバへのキーの配布を必要とします。
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: 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.
IPv6アドレスはSLAC、DHCP、および手動プロセスを通じて割り当てすることができます。 DHCPは、IPv6アドレスの割り当てに使用されている場合はホストがDHCPを使用しているため、新しいプレフィックスからIPv6アドレスの割り当てでは、いくつかの遅延が発生する場合がありのみ割り当てられたアドレスに寿命を延ばすために、定期的にサーバーに問い合わせてください。この遅延は、2つの方法で低減することができる：O先立ち低減することができる（DHCP連絡先サーバを使用して、ホストが時刻を制御する）リナンバリングイベント、T1パラメータに。
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 DHCP再設定メッセージは、即座にサーバに連絡するようにホストをトリガするためにホストにサーバから送信されてもよいです。
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.
新しいプレフィックスは、ルーティングインフラストラクチャ、ファイアウォールフィルタ、入力/出力フィルタ、およびその他の転送およびフィルタリング機能に追加されます。新しいリンクプレフィックスのためのルートは、ルーティングサブシステムにルーティングプロトコルによって注入してもよいが、ルータアドバタイズメントは、ホストが新しいリンクプレフィックスにSLACを実行させるべきではありません。特に「自律アドレス設定」フラグ[RFC2461]は新しいリンクプレフィックスの広告で設定すべきではありません。ホストはこの時点でアドレスを形成すべきではない理由は、新しいアドレスにルーティングがまだ安定していない可能性があることです。
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.
このステップの詳細は付け直されているネットワークの特定のアーキテクチャおよびネットワークインフラストラクチャを構成するコンポーネントの能力に依存します。この手順を完了するのに必要な作業は、DNS、DHCPのプレフィックス委譲[RFC3633]、およびその他の自動設定ツールを使用することによって軽減することができます。
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 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:
新しいプレフィックスは、ネットワークインフラストラクチャ、アクセスリスト、ルートマップに追加されていて、IPアドレスを使用する他のネットワーク設定オプションは、彼らがやったように、新しいプレフィックスを使用するホストとサービスが動作しますことを保証するためにチェックする必要がありたら古いもの。 DNSや古い情報で応答を回避するような方法で更新する必要がありリナンバリングによって影響を受けることになる情報を提供する他のサービス以外のネームサービスを提供しています。構成を識別し、強化するためにいくつかの有用なアプローチがあります。
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新しい接頭語に由来し、各ネットワークとアドレスに古い接頭語に由来し、各ネットワークとアドレスのマッピングを開発します。 UNIXなどのツール「のsed」や「パール」ユーティリティは、アクセスリスト、ルートマップ、などを見つけて強化するのに有用です。
o A similar approach involves the use of such mechanisms as DHCP prefix delegation to abstract networks and addresses.
O同様のアプローチは、抽象的ネットワークやアドレスにDHCPのプレフィックス委譲などのメカニズムの使用を含みます。
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.
新しいプレフィックスから割り当てられたIPv6アドレスを持つスイッチやルータ、または手動で設定されたホストは、ネットワークインフラストラクチャをテストするために、この時点で使用することができます。
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.
このフェーズでは、ルーティング、アクセス制御、およびその他のネットワークサービスの終了時、新旧両方のプレフィックスのために、交換可能に動作するはずです。
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.
新しいプレフィックスのためのネットワーク・インフラが整備されているし、テストしたら、新しいプレフィックスからIPv6アドレスは、古いプレフィックスからのアドレスは、これらのインタフェース上に保持されている間のインターフェイスをホストするために割り当ててもよいです。新しいIPv6アドレスはSLAC、DHCP、および手動プロセスを通じて割り当てすることができます。 SLACがネットワークで使用されている場合は、スイッチとルータは、ホストが新しいプレフィックスからIPv6アドレスを割り当てるためにSLACを使用すべきことを指示するように設定されています。 DHCPは、IPv6アドレスの割り当てに使用されている場合は、DHCPサービスがホストに両方のプレフィックスからアドレスを割り当てるように構成されています。彼らは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.
新しいIPv6アドレスは、両方の前方に、ホストインターフェースに割り当てられ、DNS内のマップを逆転された後のいずれかの自動または手動の手段を通じて、新しいアドレスに更新する必要があります。特に、一部のクライアントは、DDNSを通じて順方向マップを更新することができるかもしれないが、セクション4.2で議論するように、逆ゾーンの更新を自動化することはより困難であり得ます。
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つのアドレスを持つ安定したプラットフォームになると、2つの非リンクローカルアドレスは、古い接頭辞に1つ、新しい1つの任意のホストを使用できます。これは安定した構成です。
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.
新しいプレフィックスが完全にネットワークインフラストラクチャに統合されており、安定した動作のためにテストされている場合は、ホスト、スイッチ、ルータは新しい接頭辞の使用を開始することができます。移行が完了すると、古いプレフィックスは、ネットワークでの使用になりません。
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.
DNSサービスは、DNSサーバの設定から古いプレフィックスから任意のIPv6アドレスを削除することで、新たなプレフィックスを使用するように設定されています。このDNSドメインが委任されたようにDNSサービスのように、DNSサーバへの外部参照は、新しいプレフィックスからIPv6アドレスを使用するように更新されます。
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.
両方のプレフィックスがネットワークで使用可能な場合は、各ホストは、ホスト上のアプリケーションに適している時に新しいプレフィックスに古い接頭辞を使用してからの移行を行うことができます。ホスト遷移が無作為化されている場合、DNS動的更新メカニズムは、より良好なスケールは、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.
サービスは新しいプレフィックスからアドレスを介して使用できるようになると、それらのサービスを提供するホストへの参照は、新しい接頭辞を使用するように更新されます。 DNS名が解決されたときにDNSを経て得られたアドレスは自動的に更新されます。アドレスもDHCPを介して取得することができると、ホストの接触DHCPサーバとして更新されます。それ以外の場合は設定されているアドレスは適切に更新する必要があります。
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 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.
一部のアプリケーションやオペレーティングシステムの機能はすべて、または意志でDNSを使用しない方法で構成することができるので、新しい接頭辞に古い接頭語の使用からの移行を完了するためのツールや他の明示的な手順をユーザーに提供する必要があるかもしれ新しい接頭辞が使用可能になると新しいアドレスにドメイン名を解決するためにDNSを使用しません。たとえば、唯一のDNSを使用するデバイスは、デバイスが再番号付けプロセスのこの時点でそのサーバー用の新しいプレフィックスからアドレスを取得しません初期化されている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を通じて提供古いプレフィックスからアドレスの古いプレフィックスからリンクプレフィックスは、この時点でゼロに設定好みの寿命を持っている必要があります。
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.
このフェーズでは、古い接頭辞は、それを許可されたプロバイダまたは地域インターネットレジストリによって再利用することができる、そしてその接頭辞内のアドレスを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）にリセットする必要があります。
This is equivalent to the first state, but using the new prefix.
これが第一の状態と同じですが、新しい接頭辞を使用しました。
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アドレスで構成されている製造に使用される専用機器、ルータやスイッチのブートサーバとボイスオーバーIP（VoIP）の電話、
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キャッシングセマンティクスを無視することができます。その結果、長寿命のアプリケーションはDNSがリナンバリングイベント中に新しいアドレスで更新された場合でも、そのアドレスのTTLの期限が切れた時点を超えて古いIPアドレスを使用し続けることです。
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()).
例えば、多くの既存のアプリケーションは、DNSキャッシングセマンティクスを保存しないのgetaddrinfo（）などの標準的なPOSIX機能を利用します。アプリケーションが応答をキャッシュしたり何らかの理由で実際にディスク上の応答を記録した場合、アプリケーションが応答のための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.
アプリケーション設計者、機器ベンダー、およびオープンソース・コミュニティには、ノートを取る必要があります。そここの分野ではよく彼らの顧客にサービスを提供する機会があり、ネットワークオペレータは、適切なツールを開発したり購入しなければならないのいずれか。
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 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を使用して、これらの名前を解決する必要があります。
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における重要な考慮事項は、再番号付けされているネットワークが外部プロバイダに接続されている場合には、ネットワークの入口フィルタリングポリシーとそのプロバイダのイングレスフィルタリングポリシーです。ネットワークへのアクセスリンク上のネットワークファイアウォールの侵入フィルタとプロバイダの侵入フィルタの両方がソースアドレススプーフィングを使用する攻撃を防ぐために設定する必要があります。イングレスフィルタリングは、「マルチホームネットワークの入力フィルタリング」[RFC3704]で詳細に考察されます。
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ルータに名前を付けるために使用されるアドレスをリナンバリングするとき微妙な場合は、BGPルーティングのステップ2中に生じます。二つのプラクティスは共通しています。一つは、このようなループバックアドレスとして安定したアドレスにより、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.
2つのシステムが（1古いアドレスを使用し、もう1つは、新しいアドレスを使用しています）、異なる選択した場合は、O、安定したルーティング障害が発生します。
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.
それは問題ではなく、既存の関係のフラップの一つが、1つのルーティングネイバーの（BGPの視点から）交換とを行う、システムの「名前」に変更するように、これは、そのような[IDR-RESTART]などの提案によって対処されていません別の。古いが安定し、使用のまま理想的には、一つは新しいアドレスのための新しいBGP接続を持参してください、とだけにして、古いをテイクダウン。 TCP接続フラップが存在する間、このようにして、ルーティングは安定なままです。
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.
より自動化された一つが皆のためのより良い、リナンバリングプロセスを作ることができます。悲しいことに、どちらかが自動化されていないか、プラットフォーム間で一貫して自動化されていないいくつかのメカニズムがあります。
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.
（などのnamed.confなど）DNSサーバの設定ファイルは、リナンバリングイベント中に手動で再設定する必要がありますアドレスが含まれています。更新は、それらを検証するために、複雑な信頼関係と自動化の両方を必要とするこれらのアドレスの更新を自動化する簡単な方法は、現在ありません。例えば、逆ゾーンは、上流ISPによって委任が、追加の委任を注意するメカニズムは、現在、存在していません。
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ビットを割り当てるホストとの間の信頼関係の欠如の問題があります。 HはSLACてリナンバリングイベント中に新しいアドレスを取得した場合たとえば、Aが組織Bが所有するネットワークに接続されている組織からホスト、Hを、仮定、Hは、DNSサーバを介してDNSでの逆エントリを更新する必要があります新しいアドレスの逆ゾーンを所有しているBから。 Hはその逆エントリを更新するために、BからDNSサーバは、インター管理ドメインの信頼関係は、この問題に対処するためのBCPの推薦を開発する必要がHとBザIETFの間に存在することが必要、HからDDNS要求を受け入れなければなりません。
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つの広いカテゴリーに分類されます。
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.
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名が古いか新しい接頭辞ではなく、両方のいずれかである、好ましいプレフィックスのアドレスを提供するものとして、この手順で処理されています。サーバまたはピアにアクセスし、新しい接頭辞の使用を開始するためにそれらを引き起こすために、古い接頭辞の使用を停止するには、ネットワーク内のシステムを引き起こすために、2.6節で説明したように、このようなDNS名は、手段を提供します。アクセス制御リストに使用するDNS名は、しかし、2.3節と2.7節で述べたように除去古い接頭語で説明したように、新たなプレフィックスがそれらに付加された、他のアクセス制御リストに使用したのと同じ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名よりも好まれる場合を指摘しています。このような場合には、細心の注意が適切にリナンバリング管理するために注意する必要があります。
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.
攻撃も可能です。新しいプレフィックスは、サービスプロバイダによって提示されており、サービスプロバイダは、顧客のネットワークの準備が整う前にプレフィックスを広告することを開始し、例えば、と仮定します。新しいプレフィックスは、サービス攻撃の分散拒否に標的にされる可能性があります、またはシステムは、ネットワークの防御が設定されている前に、古い接頭辞を使用してファイアウォールを越えないとアプリケーションを使用してに分割される可能性があります。明らかに、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で行われていないかもしれないという事実から来ています。したがって、イングレスフィルタリングチェックを緩和に応じて任意の機構は十分に注意して扱わなければなりません。
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、ダン・ウィング、フレッド・テンプリン、ハンス・クルーゼ、ハラルド・トバイット・アルベストランド、IljitschバンBeijnum、ジェフ・ウェルズ、ジョンSchnizlein、ローラン・ニコラス、マイケル・トーマス、ミシェルのPy、オレTroanから来ましたペッカSavola、ピーター・エルフォード、ローランド・ドビンズ、スコット・ブラッドナー、ショーン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]に別々に自分の道を作りました
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".
また、6NETコンソーシアム、特にアラン・フォード、バーナード・トゥイ、クリスチャン・シルト、グラハム・ホームズ、ギュンター・ヴァン・デ・ヴェルデ、マーク・トンプソン、ニック・ラム、スティグVenaas、ティムのchown、とティナStraufは、プロシージャをテストするために自分自身時にそれを取りました。彼らは手続きにすぐに意義が見えたように、そのテストのいくつかの成果は、ここに記載されています。 6NETは、独自の「教訓」文書化されます。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]バーコウィッツ、H.、 "ルータリナンバリングガイド"、RFC 2072、1997年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[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）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、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.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989.
[クラウゼヴィッツ]・フォン・クラウゼヴィッツ、C.、ハワード、M.、Paret、P。およびD.ブロディ、 "戦争、第VII章では、戦争中摩擦」"、1989年6月。
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress, October 2004.
[DNSOP]デュラン、A.、Ihren、J.とP. Savola、 "IPv6のDNSで運用考慮事項と課題"、進歩、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-RESTART]サングリ、S.、Rekhter、Y.、フェルナンド、R.、スカダー、J.およびE.チェン、 "BGPのためのグレースフルリスタート機構"、進歩、2004年6月に働いています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田、M.、 "DNSにおける増分ゾーン転送"、RFC 1995、1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]いるVixie、P.、RFC 1996、1996年8月 "ゾーンの変更（DNSがNOTIFY）のプロンプト通知のメカニズム"。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、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を使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、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）"、RFC 2845、2000年5月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]イーストレイク3日、D.、 "DNS要求とトランザクション署名（SIG（0）S）"、RFC 2931、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABとIESG、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。
[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、 "IPv6のプレフィックスオプション動的ホスト構成プロトコル（DHCP）バージョン6のために"、RFC 3633、2003年12月。
[RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[RFC3871]ジョーンズ、G.、RFC 3871 "大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラの運用セキュリティ要件"、2004年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
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
それはすぐにセカンダリが唯一定期的に更新されている場合は、DNSの更新を待つために取る、としないことがあり、時間O;そして
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.
任意のセカンダリサーバへのプライマリDNSサーバから更新情報を転送するためにNOTIFY [RFC1996]とIXFR [RFC1995]の使用を想定。これは非常に迅速な更新プロセスである、との情報を更新するための実際の時間は有意であると見なされていません。
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.
私たちは、DNSのRRの内容を変更したい時に目標時間、TCは、あります。 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）、原発におけるRRはTTLNEW（TTLNEW <TTLOLD）で構成されています。更新プロセスは、セカンダリにRRをプッシュするために開始されます。更新後、RRのためのクエリへの応答がTTLNEWで返されます。 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を選択することができます。
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は週（168時間）で、TTLNEWは時間である場合を考えます。アドレスの変更のための準備は、アドレス変更前の169時間を開始します。 168時間が経過していると1時間だけが残された後、TTLNEWはどこにでも伝播しており、もう一方はアドレスレコード（複数可）を変更することができます。これらは、1が大きな値にTTL値を復元することができた後、時間以内に反映されます。このアプローチは、情報をDNSから返される（アドレス）のどのような不確定である時間を最小限に抑えます。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア州93117米国
Phone: 408-526-4257 Fax: 413-473-2403 EMail: fred@cisco.com
電話：408-526-4257ファックス：413-473-2403 Eメール：fred@cisco.com
Eliot Lear Cisco Systems GmbH Glatt-com 2nd Floor CH-8301 Glattzentrum Switzerland
エリオット・リアシスコシステムズ社のGlatt-COM 2階CH-8301 Glattzentrumスイス
Phone: +41 1 878 9200 EMail: lear@cisco.com
電話：+41 1 878 9200 Eメール：lear@cisco.com
Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 US
ラルフDromsシスコシステムズ200ビーバーブルック・ロードボックスボロー、MA 01719米国
Phone: +1 978 936-1674 EMail: rdroms@cisco.com
電話：+1 978 936-1674 Eメール：rdroms@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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 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機能のための基金は現在、インターネット協会によって提供されます。