[要約] RFC 4192は、IPv6ネットワークの再番号付け手順を提供し、フラグデーを必要とせずに実施することを目的としています。このRFCの要約は、IPv6ネットワークの再番号付け手順を提供し、フラグデーを回避することを目的としています。
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
フラグの日なしでIPv6ネットワークを変更するための手順
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).
Copyright（c）The Internet Society（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つのプレフィックスが同じ長さでない場合に等しく適用できます。変更中、ネットワーク全体のリンクに割り当てられた古いプレフィックスのサブプレフィックス（または「リンクプレフィックス」）は、新しいプレフィックスのリンクプレフィックスに置き換えられます。ネットワーク全体のシステム上のインターフェイスは、新しいプレフィックスのリンクプレフィックスのIPv6アドレスで構成され、DNS [RFC1034] [RFC1035]などのサービスの古いプレフィックスのアドレスから、またはスイッチとルーターとアプリケーションに構成されたアドレスは、新しいプレフィックスからの適切なアドレス。
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）[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プレフィックス委任：DHCP [RFC3315]への拡張、たとえば、ISPから顧客への接頭辞の割り当て[RFC3633]。
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フィルター：ISPなどの外部組織に接続されたルーターインターフェイスに適用され、不適切なIPv6アドレスを使用してトラフィックを除外します。
link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
リンクプレフィックス：リンクに割り当てられたプレフィックス、通常はa /64 [rfc3177]。
SLAC: StateLess Address AutoConfiguration [RFC2462].
SLAC：ステートレスアドレスAutoconfiguration [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.
o スイッチとルーターのインターフェイスに割り当てられたIPv6アドレス。これらのアドレスは、通常、スイッチとルーターの構成の一部として手動で割り当てられます。
o Routing information propagated by switches and routers.
o スイッチとルーターによって伝播されるルーティング情報。
o Link prefixes advertised by switches and routers [RFC2461].
o スイッチとルーター[RFC2461]で宣伝されているリンクプレフィックス。
o Ingress/egress filters.
o イングレス/出口フィルター。
o ACLs and other embedded addresses on switches and routers.
o ACLSおよびスイッチとルーターのその他の埋め込みアドレス。
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アドレス。Stateless AddressのAutoconfiguration（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.
o IPv6アドレスおよび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アドレスは、構成ファイル、アプリケーション、その他に埋め込まれています。更新する必要があるすべてを見つけることと、プロセスを自動化する必要がある場合があります。これについては、セクション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つの理由のいずれかで変更されます。ネットワーク自体がアドレス指定ポリシーを変更しているため、新しいポリシーを実装するために変更する必要があります（たとえば、会社が取得され、新しい所有者が使用しているものに住所を変更しています）。プロバイダーはプレフィックスを変更し、その顧客は同時にそうすることを余儀なくされているか、会社がプロバイダーを変更しているため、新しいプロバイダーが割り当てたアドレスを使用する必要があります。3番目のケースは一般的です。
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].
企業がプロバイダーを変更する場合、オーバーラップ期間を制定することが一般的であり、その間に両方のプロバイダーがサービスを提供します。定義上、同社はそのような期間中にマルチホームされています。このドキュメントは多目的なそれ自体に関するものではありませんが、上流のプロバイダーまたはその上流のプロバイダーの1つによって適用されるイングレスフィルタリングポリシーの結果として問題が発生する可能性があります。したがって、このドキュメントのユーザーもこれらの問題を認識する必要があります。これについては詳細に説明し、[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.
新しいIPv6アドレスへの移行の遅延を減らすための提案は、DNSサービスに変更イベントに関する事前に通知できる場合に適用されます。ただし、ホストのDNSサービスは、ホストが添付されているネットワークとは異なる管理ドメインにある場合があります。たとえば、組織Aのデバイスは、組織Bに属するネットワークにローミングしますが、デバイスのDNS Aレコードはまだ組織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変更イベントの前に、T1パラメーター（DHCPを使用してサーバーに接触する時間を制御する）が削減される場合があります。
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」や「Perl」ユーティリティなどのツールは、アクセスリスト、ルートマップなどを見つけて拡張するのに役立ちます。
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がネットワークで使用されている場合、スイッチとルーターは、ホストがSLACを使用して新しいプレフィックスからIPv6アドレスを割り当てる必要があることを示すように構成されています。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内のフォワードマップとリバースマップの両方を新しいアドレスに対して更新する必要があります。特に、一部のクライアントはDDNを介してフォワードマップを更新できる場合がありますが、セクション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つ、新しいホストを使用するために利用できます。これは安定した構成です。
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サーバーの名前を解決するデバイスは、デバイスが初期化されているときに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の困難な運用上の問題は、ネットワーク管理者の制御下にないか、手動で構成されているルーターとホストの構成を扱うことです。このようなデバイスの例には、ブートサーバーまたは名前サーバーの静的な構成を備えたVoice Over IP（VoIP）電話、特定のサービスのIPアドレスで構成された製造に使用される専用のデバイス、ルーターとスイッチのブートサーバーなどがあります。
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アドレスを使用して静的構成を使用するか、ドメイン名を1回だけ解決し、要素が再起動されるまで結果の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で微妙なケースが発生します。2つのプラクティスが一般的です。1つは、ループバックアドレスなどの安定したアドレスでBGPルーターを識別することです。もう1つは、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つではなく（BGPの観点から）、1つのルーティングネイバーの置換を（BGPの観点から）にします。別。理想的には、古いものが安定して使用されている間に新しいアドレスの新しい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.
DNSサーバーの構成ファイル（named.confなど）には、変更イベント中に手動で再構成する必要があるアドレスが含まれます。現在、これらのアドレスの更新を自動化する簡単な方法はありません。更新では、複雑な信頼関係と自動化の両方を検証する必要があるためです。たとえば、リバースゾーンは上流の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ビットを割り当てるホストとの間の信頼関係がないためです。たとえば、組織Aのホストhが組織Bが所有するネットワークに接続されていると仮定します。HがSLACを介した変更イベント中に新しいアドレスを取得すると、HはDNSサーバーを介してDNSの逆エントリを更新する必要があります。新しいアドレスのリバースゾーンを所有するBから。Hの逆エントリを更新するには、BからのDNSサーバーはHからのDDNS要求を受け入れる必要があり、HとBの間に投与ドメインの信頼関係が存在することを要求する必要があります。IETFは、この問題に対処するためのBCP推奨事項を開発する必要があります。
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名は、この手順で扱われ、優先プレフィックスのアドレスを提供するものとして扱われます。このようなDNS名は、セクション2.6で説明されているように、ネットワーク内のシステムに古いプレフィックスの使用を停止してサーバーまたはピアにアクセスし、新しいプレフィックスの使用を開始する手段を提供します。ただし、アクセス制御リストに使用されるDNS名は、他のアクセス制御リストに使用される同じ3段階の手順を実行する必要があります。セクション2.3で説明したように、新しい接頭辞を追加し、セクション2.7で説明した古いプレフィックスを削除する必要があります。
It should be noted that the use of DNS names in this way is not universally accepted as a solution to this problem; [RFC3871] especially notes cases where static IP addresses are preferred over DNS names, in order to avoid a name lookup when the naming system is inaccessible or when the result of the lookup may be one of several interfaces or systems. In such cases, extra care must be taken to manage renumbering properly.
この方法でのDNS名の使用は、この問題の解決策として普遍的に受け入れられていないことに注意する必要があります。[RFC3871]特に、命名システムがアクセスできない場合、またはルックアップの結果がいくつかのインターフェースまたはシステムの1つである場合に、名前の検索を回避するために、DNS名よりも静的IPアドレスが優先される場合に注意してください。そのような場合、適切に変更を管理するために特別な注意を払う必要があります。
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.
攻撃も可能です。たとえば、新しいプレフィックスがサービスプロバイダーによって提示され、サービスプロバイダーが顧客ネットワークの準備が整う前にプレフィックスの宣伝を開始したとします。新しいプレフィックスは、分散型のサービス拒否攻撃でターゲットにされるか、ネットワークの防御が構成される前に、古いプレフィックスを使用してファイアウォールを横断しないアプリケーションを使用してシステムが分割される場合があります。明らかに、セクション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] Renumbersホストで説明されている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リストの議論から生まれました。この文書に関する解説は、ビル・フェナー、クリスチャン・フイテマ、クレイグ・フエゲン、ダン・ウィング、フレッド・テンプリン、ハンス・クルーゼ、ハラルド・トヴェイト・アルベスランド、イルジッチ・ヴァン・ベイナム、ジェフ・ウェルズ、ジョン・シュニズレイン、ローラン・ニコラス、マイケル・トーマス、ミシェル・パイ、Pekka Savola、Peter Elford、Roland Dobbins、Scott Bradner、Sean Convery、Tony Hain。
Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer.
一部の人は、ネットワークが通常または頻繁な手順として変更されるという概念が不安であることを著者に納得させるためにそれを取りました。彼らのコメントは、ネットワークの住所管理慣行が改善された場合、このメモが提供しなければならない最良の貢献かもしれません。
Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described the ingress filtering issues. These made their way separately into [RFC3704], which should be read and understood by anyone who will temporarily or permanently create a multihomed network by renumbering from one provider to another.
Christian Huitema、Pekka Savola、およびIljitsch Van Beijnumは、入り口のフィルタリングの問題について説明しました。これらは[RFC3704]に個別に進みました。これは、プロバイダーから別のプロバイダーに変更することで一時的または永続的にマルチホームネットワークを作成する人が読み、理解する必要があります。
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コンソーシアム、特にアラン・フォード、バーナード・チュイ、クリスチャン・シルド、グラハム・ホームズ、ガンター・ヴァン・デ・ヴェルデ、マーク・トンプソン、ニック・ラム、スティグ・ヴェナス、ティム・チェウン、ティナ・ストラウフは、処置をテストするためにそれを取りました。そのテストのいくつかの結果は、手順に即座に重要であると思われるため、ここで文書化されています。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] Berkowitz、H。、「ルーターのレニンバーガイド」、RFC 2072、1997年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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.
[Crosewitz] von clausewitz、C.、Howard、M.、Paret、P. and D. Brodie、「戦争、第VII章「戦争の摩擦」」、1989年6月。
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress, October 2004.
[DNSOP] Durand、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] Sangli、S.、Rekhter、Y.、Fernando、R.、Scudder、J。and E. Chen、「BGPの優雅な再起動メカニズム」、2004年6月の作業。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995] OHTA、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。、「ゾーンの変更の迅速な通知のメカニズム（DNS通知）」、RFC 1996、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.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、2000年5月、RFC 2845。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] EastLake 3rd、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。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス」、RFC 3177、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、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。、「大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラストラクチャの運用セキュリティ要件」、RFC 3871、2004年9月。
[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.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
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があります。この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）で、プライマリの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が1週間（168時間）、Ttlnewが1時間である場合を検討してください。住所の変更の準備は、住所が変更される169時間前に始まります。168時間が経過し、1時間しか残っていないため、TTLNewはどこにでも伝播し、アドレスレコードを変更できます。これらは1時間以内に伝播され、その後、TTL値をより大きな値に復元できます。このアプローチは、DNSからどのような（アドレス）情報が返されるかが不確かな時間を最小限に抑えます。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッド・ベイカー・シスコ・システム1121
Phone: 408-526-4257 Fax: 413-473-2403 EMail: fred@cisco.com
電話：408-526-4257ファックス：413-473-2403メール：fred@cisco.com
Eliot Lear Cisco Systems GmbH Glatt-com 2nd Floor CH-8301 Glattzentrum Switzerland
Eliot Lear Cisco Systems GmbH Glatt-Com 2階CH-8301 Glattzentrum Switzerland
Phone: +41 1 878 9200
EMail: lear@cisco.com
Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough, MA 01719 US
Ralph Droms Cisco Systems 200 Beaver Brook Road Boxborough、MA 01719 US
Phone: +1 978 936-1674
EMail: rdroms@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。