[要約] RFC 7010は、IPv6サイトの再番号付けに関する課題と解決策を分析したものです。その目的は、IPv6サイトの再番号付けに関連する問題を特定し、解決策を提案することです。
Internet Engineering Task Force (IETF) B. Liu
Request for Comments: 7010 S. Jiang
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
S. Venaas
Cisco Systems
W. George
Time Warner Cable
September 2013
IPv6 Site Renumbering Gap Analysis
IPv6サイト再番号付けギャップ分析
Abstract
概要
This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.
このドキュメントでは、IPv6サイトの再番号付けに利用できる既存のメカニズムを簡単に紹介し、IPv6の再番号付けに関連する明示的な問題と要件のほとんどをカバーしようとしています。内容は主にギャップ分析であり、ソリューションを特定して開発する、または必要に応じてそのような開発を刺激する将来の作業の基礎を提供します。ギャップ分析は、番号を付け直すプロセスの主要なステップで構成されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7010.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7010で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Overall Requirements for Renumbering ............................4
3. Existing Components for IPv6 Renumbering ........................5
3.1. Relevant Protocols and Mechanisms ..........................5
3.2. Management Tools ...........................................6
3.3. Procedures and Policies ....................................7
4. Managing Prefixes ...............................................7
4.1. Prefix Delegation ..........................................7
4.2. Prefix Assignment ..........................................8
5. Address Configuration ...........................................8
5.1. Host Address Configuration .................................8
5.2. Router Address Configuration ...............................9
6. Updating Address-Relevant Entries ..............................10
6.1. DNS Records Update ........................................10
6.2. In-Host Server Address Update .............................11
6.3. Address Update in Scattered Configurations ................11
7. Renumbering Event Management ...................................13
7.1. Renumbering Notification ..................................13
7.2. Synchronization Management ................................14
7.3. Renumbering Monitoring ....................................15
8. Miscellaneous ..................................................15
8.1. Multicast .................................................15
8.2. Mobility ..................................................17
9. Gap Summary ....................................................17
9.1. Managing Prefixes .........................................17
9.2. Address Configuration .....................................17
9.3. Address-Relevant Entries Update ...........................18
9.4. Renumbering Event Management ..............................19
9.5. Miscellaneous .............................................19
10. Gaps Considered Unsolvable ....................................20
10.1. Address Configuration ....................................20
10.2. Address-Relevant Entries Update ..........................20
10.3. Miscellaneous ............................................21
11. Security Considerations .......................................21
12. Acknowledgments ...............................................22
13. References ....................................................23
13.1. Normative References .....................................23
13.2. Informative References ...................................23
As introduced in [RFC5887], renumbering, especially for medium to large sites and networks, is currently viewed as expensive and painful. This error-prone process is avoided by network managers as much as possible. If IPv6 site renumbering continues to be considered difficult, network managers will turn to Provider Independent (PI) addressing for IPv6 as an attempt to minimize the need for future renumbering. However, widespread use of PI addressing may create very serious BGP4 scaling problems [RFC4984]. It is thus desirable to develop tools and practices that make renumbering a simpler process and reduces demand for IPv6 PI space.
[RFC5887]で紹介されているように、特に中規模から大規模のサイトとネットワークでは、番号の付け直しは現在、費用がかかり苦痛であると見なされています。このエラーが発生しやすいプロセスは、ネットワーク管理者によって可能な限り回避されます。 IPv6サイトの再番号付けが引き続き難しいと考えられる場合、ネットワーク管理者は、将来の再番号付けの必要性を最小限に抑える試みとして、IPv6のプロバイダー独立（PI）アドレッシングを使用します。ただし、PIアドレッシングを広く使用すると、非常に深刻なBGP4スケーリングの問題が発生する可能性があります[RFC4984]。したがって、番号の付け直しをより簡単にし、IPv6 PIスペースの需要を減らすツールとプラクティスを開発することが望まれます。
Building upon the IPv6 enterprise renumbering scenarios described in [RFC6879], this document performs a gap analysis to provide a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized according to the main steps of a renumbering process, which includes prefix management, node address (re)configuration, and updates to address-relevant entries in various devices such as firewalls, routers and servers, etc. Renumbering event management is presented independently from the steps of a renumbering process in order to identify some operational and administrative gaps in renumbering.
[RFC6879]で説明されているIPv6エンタープライズ再番号付けシナリオに基づいて、このドキュメントはギャップ分析を実行し、ソリューションを特定して開発する、または適切にそのような開発を刺激する将来の作業の基礎を提供します。ギャップ分析は、番号付けプロセスの主な手順に従って構成されます。これには、プレフィックス管理、ノードアドレス（再）構成、ファイアウォール、ルーター、サーバーなどのさまざまなデバイスのアドレス関連エントリへの更新が含まれます。番号付けの運用上および管理上のギャップを特定するために、番号付けプロセスのステップとは別に提示されます。
This document starts from existing work in [RFC5887] and [RFC4192]. It further analyzes and identifies the valuable and solvable issues, digs out of some undiscovered gaps, and gives some solution suggestions. This document considers the make-before-break approach as a premise for the gap analysis, so readers should be familiar with [RFC4192].
このドキュメントは、[RFC5887]と[RFC4192]の既存の作業から始まります。さらに、価値のある解決可能な問題を分析および特定し、未発見のギャップを掘り下げ、解決策を提案します。このドキュメントでは、make-before-breakアプローチをギャップ分析の前提として検討しているため、読者は[RFC4192]に精通している必要があります。
Renumbering nodes with static addresses has a particular set of problems, thus discussion of that space has been covered in a related document [RFC6866].
静的アドレスを使用してノードの番号を付け直すと、特定の一連の問題が発生するため、その領域の説明は関連ドキュメント[RFC6866]で説明されています。
This document does not cover the unplanned emergency renumbering cases.
このドキュメントでは、計画外の緊急番号変更のケースは扱いません。
This section introduces the overall goals of a renumbering event. In general, we need to leverage renumbering automation to avoid human intervention as much as possible at a reasonable cost. Some existing mechanisms already provide useful capabilities.
このセクションでは、番号を付け直すイベントの全体的な目標を紹介します。一般に、合理的なコストで可能な限り人間の介入を回避するために、番号付けの自動化を活用する必要があります。既存のメカニズムの中には、すでに便利な機能を提供しているものがあります。
The automation can be divided into four aspects as follows. (Detailed analysis of the four aspects is presented respectively in Sections 4 through 7.)
自動化は、次の4つの側面に分けることができます。 （4つの側面の詳細な分析は、それぞれセクション4〜7に示されています。）
o Prefix delegation and delivery should be automatic and accurate in aggregation and coordination.
o プレフィックスの委任と配信は、集約と調整において自動的かつ正確でなければなりません。
o Address reconfiguration should be automatically achieved through standard protocols with minimum human intervention.
o アドレスの再構成は、人の介入を最小限に抑えて、標準プロトコルを介して自動的に行われる必要があります。
o Address-relevant entry updates should be performed together and without error.
o アドレス関連のエントリの更新は、一緒にエラーなしで実行する必要があります。
o Renumbering event management is needed to provide the functions of renumbering notification, synchronization, and monitoring.
o 通知の再番号付け、同期、監視の機能を提供するには、イベント管理の再番号付けが必要です。
Besides automation, session survivability is another important issue during renumbering since application outage is one of the most obvious impacts that make renumbering painful and expensive. Session survivability is a fundamental issue that cannot be solved within a renumbering context only. However, the [RFC4192] make-before-break approach, which uses the address lifetime mechanisms in IPv6 Stateless Address Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6), allows for a smooth transition mechanism from old to new prefixes. In most cases, since we can set the transition period to be long enough to cover the ongoing sessions, we consider this mechanism sufficient to avoid broken sessions in IPv6 site renumbering. (Please note that if multiple addresses are running on hosts simultaneously, the address selection [RFC6724] needs to be carefully handled.)
自動化に加えて、セッションの存続可能性は、再番号付けの際のもう1つの重要な問題です。これは、アプリケーションの停止が、再番号付けを困難で費用のかかる最も明白な影響の1つだからです。セッションの存続可能性は、再番号付けのコンテキスト内でのみ解決できない基本的な問題です。ただし、[RFC4192] make-before-breakアプローチでは、IPv6ステートレスアドレス自動構成（SLAAC）とIPv6の動的ホスト構成プロトコル（DHCPv6）のアドレスライフタイムメカニズムを使用して、古いプレフィックスから新しいプレフィックスへのスムーズな移行メカニズムを可能にします。ほとんどの場合、移行期間は進行中のセッションをカバーするのに十分な長さに設定できるため、このメカニズムはIPv6サイトの再番号付けにおけるセッションの破損を回避するのに十分であると考えています。 （複数のアドレスがホストで同時に実行されている場合、アドレス選択[RFC6724]は慎重に処理する必要があることに注意してください。）
Since renumbering is not a new issue, some protocols and mechanisms have already been utilized for this purpose. There are also some dedicated protocols and mechanisms that have been developed for renumbering. This section briefly reviews these existing protocols and mechanisms to provide a basis for the gap analysis.
番号の付け替えは新しい問題ではないので、いくつかのプロトコルとメカニズムはこの目的のためにすでに利用されています。番号を付け直すために開発された専用のプロトコルとメカニズムもいくつかあります。このセクションでは、これらの既存のプロトコルとメカニズムを簡単に確認して、ギャップ分析の基礎を提供します。
o Router Advertisement (RA) messages, defined in [RFC4861], are used to deprecate prefixes that are old or announce prefixes that are new, and to advertise the availability of an upstream router. In renumbering, RA is one of the basic mechanisms for host configuration.
o [RFC4861]で定義されているルーターアドバタイズ（RA）メッセージは、古いプレフィックスを廃止するか、新しいプレフィックスをアナウンスし、上流ルーターの可用性を通知するために使用されます。番号を付け替える場合、RAはホスト構成の基本的なメカニズムの1つです。
o When renumbering a host, SLAAC [RFC4862] may be used for address configuration with the new prefix(es). Hosts receive RA messages that contain a routable prefix(es) and the address(es) of the default router(s); then hosts can generate an IPv6 address(es) by themselves.
o ホストの番号を付け直す場合、SLAAC [RFC4862]を使用して、新しいプレフィックスを持つアドレス構成を行うことができます。ホストは、ルーティング可能なプレフィックスとデフォルトルーターのアドレスを含むRAメッセージを受信します。その後、ホストは自分でIPv6アドレスを生成できます。
o Hosts that are configured through DHCPv6 [RFC3315] obtain new addresses through the renewal process or when they receive the reconfiguration messages initiated by the DHCPv6 servers.
o DHCPv6 [RFC3315]を介して構成されたホストは、更新プロセスを通じて、またはDHCPv6サーバーによって開始された再構成メッセージを受信したときに、新しいアドレスを取得します。
o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated delegation of IPv6 prefixes using the DHCPv6.
o DHCPv6-PD（プレフィックス委任）[RFC3633]は、DHCPv6を使用してIPv6プレフィックスの自動委任を有効にします。
o [RFC2894] defines standard ICMPv6 messages for router renumbering. This is a dedicated protocol for renumbering, but we are not aware of real network deployment.
o [RFC2894]は、ルータの再番号付けのための標準ICMPv6メッセージを定義しています。これは番号を付け直すための専用プロトコルですが、実際のネットワーク展開については認識していません。
Some renumbering operations could be automatically processed by management tools in order to make the renumbering process more efficient and accurate. The tools may be designed specifically for renumbering, or common tools could be utilized for some of the renumbering operations.
一部の再番号付け操作は、管理ツールによって自動的に処理され、再番号付けプロセスをより効率的かつ正確にすることができます。ツールは、番号の付け直しのために特別に設計されている場合があります。
Following are examples of such tools:
以下はそのようなツールの例です。
o IP address management (IPAM) tools. There are both commercial and open-source solutions. IPAM tools are used to manage IP address plans and usually integrate the DHCPv6 and DNS services together as a whole solution. Many mature commercial tools can support management operations, but normally they do not have dedicated renumbering functions. However, the integrated DNS/DHCPv6 services and address management function can obviously facilitate the renumbering process.
o IPアドレス管理（IPAM）ツール。商用とオープンソースの両方のソリューションがあります。 IPAMツールは、IPアドレス計画の管理に使用され、通常、DHCPv6サービスとDNSサービスをソリューション全体として統合します。多くの成熟した商用ツールは、管理操作をサポートできますが、通常、専用の番号を付け直す機能はありません。ただし、統合されたDNS / DHCPv6サービスとアドレス管理機能により、番号の付け直しプロセスが明らかに容易になります。
o Third-party tools. Some organizations use third-party tools to push configuration to devices. This is sometimes used as a supplement to vendor-specific solutions. A representative of such a third-party tool is [CFENGINE].
o サードパーティのツール。一部の組織では、サードパーティツールを使用して構成をデバイスにプッシュしています。これは、ベンダー固有のソリューションの補足として使用される場合があります。このようなサードパーティツールの代表は[CFENGINE]です。
o Macros. [LEROY] proposed a mechanism of macros to automatically update the address-relevant entries/configurations inside the DNS, firewall, etc. The macros can be delivered through the SOAP protocol from a network management server to the managed devices.
o マクロ。 [LEROY]は、DNS、ファイアウォールなどの内部のアドレス関連エントリ/構成を自動的に更新するマクロのメカニズムを提案しました。マクロは、SOAPプロトコルを介してネットワーク管理サーバーから管理対象デバイスに配信できます。
o Asset management tools/systems. These tools may provide the ability to manage configuration files in devices so that it is convenient to update the address-relevant configuration in these devices.
o 資産管理ツール/システム。これらのツールは、デバイスの構成ファイルを管理する機能を提供する場合があるため、これらのデバイスのアドレス関連の構成を更新すると便利です。
o [RFC4192] proposed a procedure for renumbering an IPv6 network without a flag day. The document includes a set of operational suggestions that can be followed step by step by network administrators. It should be noted that the administrators need to carefully deal with the address selection issue, while the old and new prefixes are both available during the overlapping period as described in the procedures in [RFC4192]. The address selection policies might need to be updated after renumbering, so the administrator could leverage the address-selection-policy distribution mechanism as described in [6MAN-ADDR-OPT].
o [RFC4192]は、フラグデイなしでIPv6ネットワークの番号を付け直す手順を提案しました。このドキュメントには、ネットワーク管理者が段階的に実行できる一連の運用上の提案が含まれています。 [RFC4192]の手順で説明されているように、古いプレフィックスと新しいプレフィックスの両方が重複期間中に利用可能である一方で、管理者はアドレス選択の問題に慎重に対処する必要があることに注意してください。 [6MAN-ADDR-OPT]で説明されているように、管理者はアドレス選択ポリシーの配布メカニズムを活用して、番号を付け直した後にアドレス選択ポリシーを更新する必要がある場合があります。
o [RFC6879] analyzes the enterprise renumbering events and makes recommendations based on the existing renumbering mechanisms. According to the different stages, renumbering considerations are described in three categories: considerations and recommendations during network design, for the preparation of enterprise network renumbering, and during the renumbering operation.
o [RFC6879]は、エンタープライズの再番号付けイベントを分析し、既存の再番号付けメカニズムに基づいて推奨を行います。さまざまな段階に応じて、再番号付けの考慮事項は、ネットワーク設計時の考慮事項と推奨事項、エンタープライズネットワークの再番号付けの準備のための考慮事項、および再番号付け操作中の3つのカテゴリで説明されています。
When renumbering an IPv6 enterprise site, the key procedural issue is switching the old prefix(es) to a new one(s). A new short prefix may be divided into longer ones for subnets, so we need to carefully manage the prefixes to ensure they are synchronized and coordinated within the whole network.
IPv6エンタープライズサイトの番号を付け直すときの重要な手順の問題は、古いプレフィックスを新しいプレフィックスに切り替えることです。新しい短いプレフィックスは、サブネット用に長いプレフィックスに分割される可能性があるため、プレフィックスを慎重に管理して、ネットワーク全体で同期および調整されるようにする必要があります。
For big enterprises, the new short prefix(es) usually comes down through offline human communication. But, for the SOHO-style (Small Office, Home Office) SMEs (Small & Medium Enterprises), the prefixes might be dynamically received by DHCPv6 servers or routers inside the enterprise networks. The short prefix(es) could be automatically delegated through DHCPv6-PD. Then the downlink DHCPv6 servers or routers could begin advertising the longer prefixes to the subnets.
大企業の場合、新しい短い接頭辞は通常、オフラインの人間のコミュニケーションを通じてダウンします。ただし、SOHOスタイル（小規模オフィス、ホームオフィス）のSME（中小規模企業）の場合、プレフィックスはエンタープライズネットワーク内のDHCPv6サーバーまたはルーターによって動的に受信される場合があります。短いプレフィックスは、DHCPv6-PDを介して自動的に委任できます。次に、ダウンリンクのDHCPv6サーバーまたはルーターが、より長いプレフィックスをサブネットにアドバタイズし始めます。
The delegation routers might need to renumber themselves with the new delegated prefixes. So, there should be a mechanism to inform the routers to renumber themselves by delegated prefixes; there should also be a mechanism for the routers to derive addresses automatically based on the delegated prefixes.
委任ルーターは、新しい委任されたプレフィックスを使用して自分自身の番号を付け直す必要がある場合があります。したがって、委任されたプレフィックスによって番号を付け直すようにルーターに通知するメカニズムが必要です。委任されたプレフィックスに基づいてルーターが自動的にアドレスを導出するメカニズムも必要です。
When subnet routers receive the longer prefixes, they can advertise a prefix on a link to which hosts are connected. Host address configuration, rather than routers, is the primary concern for prefix assignment, which is described in Section 5.1.
サブネットルーターが長いプレフィックスを受信すると、ホストが接続されているリンク上のプレフィックスをアドバタイズできます。ルーターではなくホストアドレスの構成は、セクション5.1で説明されているプレフィックス割り当ての主な関心事です。
o SLAAC and DHCPv6 Interaction Problems
o SLAACとDHCPv6の相互作用の問題
Both DHCPv6 and Neighbor Discovery (ND) protocols have an IP address configuration function, which are suitable for different scenarios. During renumbering, the SLAAC-configured hosts can reconfigure IP addresses by receiving ND Router Advertisement (RA) messages containing new prefix information. (It should be noted that the prefix delivery could be achieved through DHCPv6 according to [PREFIX-DHCPv6]). The DHCPv6-configured hosts can reconfigure addresses by initiating RENEW sessions [RFC3315] when the current addresses' lease times are expired or when they receive reconfiguration messages initiated by the DHCPv6 servers.
DHCPv6プロトコルと近隣探索（ND）プロトコルの両方にIPアドレス構成機能があり、さまざまなシナリオに適しています。再番号付け中に、SLAAC構成のホストは、新しいプレフィックス情報を含むNDルーターアドバタイズ（RA）メッセージを受信することにより、IPアドレスを再構成できます。 （プレフィックス配信は、[PREFIX-DHCPv6]に従ってDHCPv6を介して実現できることに注意してください）。 DHCPv6で構成されたホストは、現在のアドレスのリース期限が切れたとき、またはDHCPv6サーバーによって開始された再構成メッセージを受け取ったときに、RENEWセッション[RFC3315]を開始することによってアドレスを再構成できます。
Sometimes the two address configuration modes may be available in the same network. This would add additional complexity for both the hosts and network management.
2つのアドレス設定モードが同じネットワークで利用できる場合があります。これにより、ホストとネットワーク管理の両方がさらに複雑になります。
With the flags defined in RA (ManagedFlag (M) indicating the DHCPv6 service available in the network; OtherConfigFlag (O) indicating other configurations such as DNS/routing), the two separated address configuration modes are correlated. However, the ND protocol does not define the flags as prescriptive but only as advisory. This has led to variation in the behavior of hosts when interpreting the flags; different operating systems have followed different approaches. (For more details, please refer to [DHCPv6-SLAAC] and [6RENUM-SLAAC].)
RAで定義されたフラグ（ManagedFlag（M）はネットワークで使用可能なDHCPv6サービスを示し、OtherConfigFlag（O）はDNS /ルーティングなどの他の構成を示します）により、2つの別個のアドレス構成モードが関連付けられます。ただし、NDプロトコルでは、フラグを規範としてではなく、助言としてのみ定義しています。これにより、フラグを解釈するときのホストの動作にばらつきが生じました。オペレーティングシステムが異なれば、アプローチも異なります。 （詳細については、[DHCPv6-SLAAC]および[6RENUM-SLAAC]を参照してください。）
The impact of ambiguous M/O flags includes the following aspects:
あいまいなM / Oフラグの影響には、以下の側面が含まれます。
- DHCPv6-configured hosts might not be able to be renumbered by RA
- DHCPv6で構成されたホストは、RAによって再番号付けできない場合があります
It is unclear whether a DHCPv6-configured host will accept address configuration though RA messages, especially when the M flag transitions from 1 to 0; this depends on the implementation of the operating system. It might not be possible for administrators to only use RA messages for renumbering, since renumbering might fail on some already DHCPv6-configured hosts. This means administrators have to use DHCPv6 reconfiguration for some DHCPv6-configured hosts. It is not convenient, and DHCPv6 reconfiguration is not suitable for bulk usage as analyzed below.
特にMフラグが1から0に移行する場合、DHCPv6構成のホストがRAメッセージを介してアドレス構成を受け入れるかどうかは不明です。これは、オペレーティングシステムの実装によって異なります。 DHCPv6がすでに構成されている一部のホストでは番号の付け直しが失敗する可能性があるため、管理者が番号の付け直しにRAメッセージのみを使用することはできない場合があります。これは、管理者が一部のDHCPv6構成ホストに対してDHCPv6再構成を使用する必要があることを意味します。これは不便であり、DHCPv6の再構成は、以下で分析するように、一括使用には適していません。
- DHCPv6-configured hosts might not be able to learn new RA prefixes
- DHCPv6構成のホストが新しいRAプレフィックスを学習できないことがある
[RFC5887] mentions that DHCPv6-configured hosts may want to learn about the upstream availability of new prefixes or loss of prior prefixes dynamically by deducing this from periodic RA messages. Relevant standards [RFC4862] [RFC3315] are ambiguous about what approach should be taken by a DHCPv6-configured host when it receives RA messages containing a new prefix. Current behavior depends on the operating system of the host and cannot be predicted or controlled by the network.
[RFC5887]は、DHCPv6が設定されたホストが、定期的なRAメッセージからこれを推定することにより、新しいプレフィックスのアップストリームアベイラビリティまたは以前のプレフィックスの損失について動的に学習することを望むかもしれないと述べています。関連する標準[RFC4862] [RFC3315]は、新しいプレフィックスを含むRAメッセージを受信したときに、DHCPv6構成のホストがどのアプローチを取るべきかについてあいまいです。現在の動作はホストのオペレーティングシステムに依存し、ネットワークによって予測または制御することはできません。
- SLAAC-configured hosts might not be able to add a DHCPv6 address(es)
- SLAAC構成のホストがDHCPv6アドレスを追加できない場合がある
The behavior when the host receives RA messages with the M flag set is unspecified.
ホストがMフラグが設定されたRAメッセージを受信したときの動作は指定されていません。
The host may start a DHCPv6 session and receive the DHCPv6 address configuration, or it may just ignore the messages. Whether the hosts start DHCPv6 configuration is outside the control of the network side.
ホストはDHCPv6セッションを開始してDHCPv6アドレス構成を受信するか、単にメッセージを無視する場合があります。ホストがDHCPv6構成を開始するかどうかは、ネットワーク側の制御の範囲外です。
o Learning New Prefixes
o 新しいプレフィックスの学習
As described in [RFC5887], "if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths."
[RFC5887]で説明されているように、「アップストリームプロバイダーごとに1つのプレフィックスを持つ複数のプロバイダー集約（PA）ルーティングプレフィックスを使用してサイトをマルチホーム化したい場合、内部ルーターは、現在到達可能なアップストリームプロバイダーとプレフィックスを知るメカニズムが必要です。 （および有効）。この場合、ルーターアドバタイズメッセージは動的に更新され、現在有効なルーティングプレフィックスのみをホストにアドバタイズすることができます。これは、さまざまなプロバイダープレフィックスの長さが異なる場合、またはサイトに不均一な場合、非常に複雑になります。サブネットプレフィックス長。」
o Restarting After Renumbering
o 番号を付け直した後の再起動
As [RFC2072] mentions, some routers cache IP addresses in some situations, so routers might need to be restarted as a result of site renumbering. While most modern systems support a cache-clear function that eliminates the need for restarts, there are always exceptions that must be taken into account.
[RFC2072]が言及しているように、一部のルーターは状況によってはIPアドレスをキャッシュするため、サイトの再番号付けの結果としてルーターの再起動が必要になる場合があります。最近のほとんどのシステムは、再起動の必要をなくすキャッシュクリア機能をサポートしていますが、考慮に入れなければならない例外が常にあります。
o Router Naming
o ルーターの命名
[RFC4192] states that "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". As [RFC5887] described, this capability is not new, and currently it is present in most IPsec VPN implementations. However, many administrators may need to be alerted to the fact that it can be utilized to avoid manual modification during renumbering.
[RFC4192]は、「再番号付けをより適切にサポートするために、スイッチとルーターは構成にドメイン名を適切に使用し、名前の有効期限が切れたときにDNSを使用してそれらの名前を解決する必要がある」と述べています。 [RFC5887]で説明されているように、この機能は新しいものではなく、現在ほとんどのIPsec VPN実装に存在しています。ただし、多くの管理者は、番号を付け直す際に手動で変更することを回避するためにそれを利用できるという事実を警告する必要があるかもしれません。
In conjunction with renumbering the nodes, any configuration or data store containing previous addresses must be updated as well. Some examples include DNS records and filters in various entities such as Access Control Lists (ACLs) in firewalls/gateways.
ノードの番号を付け直すことに関連して、以前のアドレスを含む構成またはデータストアも更新する必要があります。いくつかの例には、ファイアウォール/ゲートウェイのアクセス制御リスト（ACL）などのさまざまなエンティティのDNSレコードとフィルターが含まれます。
o Secure Dynamic DNS (DDNS) Update
o セキュアダイナミックDNS（DDNS）アップデート
In real network operations, a DNS update is normally achieved by maintaining a DNS zone file and loading this file into the site's DNS server(s). Synchronization between host renumbering and the updating of its AAAA record is hard. [RFC5887] discusses an alternative that uses the Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address.
実際のネットワーク運用では、DNS更新は通常、DNSゾーンファイルを維持し、このファイルをサイトのDNSサーバーにロードすることによって行われます。ホストの再番号付けとそのAAAAレコードの更新の間の同期は困難です。 [RFC5887]は、セキュアダイナミックDNSアップデート[RFC3007]を使用する別の方法について説明しています。RFC3007では、ホストは、新しいアドレスを受信すると、自身のDNSサーバーに通知します。
The Secure Dynamic DNS Update has been widely supported by the major DNS implementations, but it hasn't been widely deployed. Normal hosts are not suitable to do the update, mainly because of the complex key-management issues inherited from secure DNS mechanisms, so current practices usually assign DHCP servers to act as DNS clients to request that the DNS server update relevant records [RFC4704]. The key-management problem is tractable in the case of updates for a limited number of servers, so Dynamic DNS updates could serve as a suitable solution for keeping server DNS records up to date on a typical enterprise network. However, this solution is not easily applicable to hosts in general.
Secure Dynamic DNS Updateは、主要なDNS実装で広くサポートされていますが、広く展開されていません。通常のホストは、主に安全なDNSメカニズムから継承された複雑なキー管理の問題のため、更新の実行に適していません。そのため、現在の慣行では、通常、DHCPサーバーを割り当ててDNSクライアントとして機能し、DNSサーバーが関連レコードを更新するように要求します[RFC4704]。限られた数のサーバーの更新の場合、キー管理の問題は扱いやすいため、動的DNS更新は、通常のエンタープライズネットワークでサーバーDNSレコードを最新の状態に保つための適切なソリューションとして役立ちます。ただし、このソリューションは一般的にホストに簡単に適用できません。
To address the larger use case of arbitrary non-server hosts being renumbered, DHCP servers have to learn that the relevant hosts have changed their addresses and thus trigger the DDNS update. If the hosts were numbered and also renumbered by DHCP, it would be easy for the DHCP servers to learn the address changes; however, if the hosts were numbered by SLAAC, then there could be trouble.
DHCPサーバーは、任意の非サーバーホストの番号が変更されるというより大きなユースケースに対処するために、関連するホストがアドレスを変更し、DDNS更新をトリガーすることを知る必要があります。ホストに番号が付けられ、DHCPによって番号が付け直された場合、DHCPサーバーはアドレスの変更を簡単に知ることができます。ただし、ホストにSLAACによって番号が付けられている場合は、問題が発生する可能性があります。
While DNS stores the addresses of hosts in servers, hosts are also configured with the addresses of servers, such as DNS and RADIUS servers [RFC2865]. While renumbering, the hosts must update these addresses if the server addresses change.
DNSはホストのアドレスをサーバーに保存しますが、ホストはDNSサーバーやRADIUSサーバー[RFC2865]などのサーバーのアドレスで構成されます。サーバーのアドレスが変更された場合、再番号付け中にホストはこれらのアドレスを更新する必要があります。
In principle, the addresses of DHCPv6 servers do not need to be updated since they could be dynamically discovered through DHCPv6-relevant multicast messages. But in practice, most relay agents have the option of being configured with a DHCPv6 server address rather than sending to a multicast address. Therefore, the DHCP server addresses update might be an issue in practice.
原則として、DHCPv6サーバーのアドレスは、DHCPv6関連のマルチキャストメッセージを通じて動的に検出できるため、更新する必要はありません。しかし実際には、ほとんどのリレーエージェントは、マルチキャストアドレスに送信するのではなく、DHCPv6サーバーアドレスを使用して設定するオプションを持っています。したがって、DHCPサーバーアドレスの更新は実際には問題になる可能性があります。
Besides the DNS records and the in-host server address entries, there are also many places in which IP addresses are configured, for example, filters such as ACL and routing policies. There are even more sophisticated cases where the IP addresses are used for deriving values, for example, using the unique portion of the loopback address to generate an ISIS net ID.
DNSレコードとホスト内サーバーアドレスエントリのほかに、IPアドレスが構成されている場所も多くあります。たとえば、ACLやルーティングポリシーなどのフィルターです。たとえば、ループバックアドレスの一意の部分を使用してISISネットIDを生成するなど、IPアドレスを使用して値を導出するさらに高度なケースがあります。
In renumbering, updating the IP addresses in all the above mentioned places is burdensome and error-prone. We lack a "one-stop" mechanism to trigger the updates for all the subsystems on a host/server and all the external databases that refer to the IP address update. We break the general "one-stop" gap into the following two aspects.
番号を付け直す場合、上記のすべての場所でIPアドレスを更新するのは面倒でエラーが発生しやすくなります。ホスト/サーバー上のすべてのサブシステムと、IPアドレスの更新を参照するすべての外部データベースの更新をトリガーする「ワンストップ」メカニズムがありません。一般的な「ワンストップ」ギャップを次の2つの側面に分割します。
o Self-Contained Configuration in Individual Devices
o 個々のデバイスの自己完結型構成
Ideally, IP addresses can be defined as a value once, and then the administrators can use either keywords or variables to call the value in other places such as a sort of internal inheritance in CLI (command line interface) or other local configurations. This makes it easier to manage a renumbering event by reducing the number of places where a device's configuration must be updated.
理想的には、IPアドレスは一度値として定義でき、管理者はキーワードまたは変数を使用して、CLI（コマンドラインインターフェイス）の内部継承のような他の場所や他のローカル構成などで値を呼び出すことができます。これにより、デバイスの構成を更新する必要のある場所の数を減らすことで、再番号付けイベントの管理が容易になります。
However, it still means that every device needs to be individually updated, but only once instead of having to inspect the whole configuration to ensure that none of the separate places that a given IP address occurs is missed.
ただし、すべてのデバイスを個別に更新する必要がありますが、構成全体を検査して特定のIPアドレスが発生する個別の場所が失われていないことを確認する必要はなく、1回だけです。
Among current devices, some routers support defining multiple loopback interfaces that can be called in other configurations. For example, when defining a tunnel, it can call the defined loopback interface to use its address as the local address of the tunnel. This can be considered as a kind of parameterized self-contained configuration. However, this only applies to certain use cases; it is impossible to use the loopback interfaces to represent external devices, and it is not always possible to call loopback interfaces in other configurations. Parameterized self-contained configuration is still a gap that needs to be filled.
現在のデバイスのうち、一部のルーターは、他の構成で呼び出すことができる複数のループバックインターフェイスの定義をサポートしています。たとえば、トンネルを定義するときに、定義されたループバックインターフェイスを呼び出して、そのアドレスをトンネルのローカルアドレスとして使用できます。これは、一種のパラメータ化された自己完結型の構成と考えることができます。ただし、これは特定のユースケースにのみ適用されます。ループバックインターフェイスを使用して外部デバイスを表すことは不可能であり、他の構成でループバックインターフェイスを呼び出すことが常に可能であるとは限りません。パラメータ化された自己完結型構成は、依然として埋める必要のあるギャップです。
o Unified Configuration Management among Devices
o デバイス間の統合構成管理
This refers to a more formalized central configuration management system, where all changes are made in one place, and the system manages how changes are pushed to the individual devices. This issue contains two aspects, as follows:
これは、すべての変更が1か所で行われ、変更が個々のデバイスにプッシュされる方法をシステムが管理する、より正式な中央構成管理システムを指します。この問題には、次の2つの側面があります。
- Configuration Aggregation
- 構成集約
Configuration data based on addresses or prefixes are usually spread out in various devices. As [RFC5887] describes, some address configuration data might be widely dispersed and much harder to find. Some will inevitably be found only after the renumbering event. Because there's a big gap in configuration aggregation, it is hard to get all the relevant configuration data together in one place.
アドレスまたはプレフィックスに基づく設定データは、通常、さまざまなデバイスに分散されます。 [RFC5887]が説明しているように、一部のアドレス構成データは広く分散しており、見つけるのがはるかに難しい場合があります。一部は必然的に番号の付け直しイベントの後でのみ見つかります。構成の集計には大きなギャップがあるため、関連するすべての構成データを1か所にまとめることは困難です。
- Configuration Update Automation
- 構成更新の自動化
As mentioned in Section 3.2, [LEROY] proposes a mechanism that can automatically update the configurations. The mechanism utilizes macros suitable for various devices such as routers and firewalls to update configurations based on the new prefix. Such an automation tool is valuable for renumbering because it can reduce manual operation, which is error-prone and inefficient.
セクション3.2で述べたように、[LEROY]は構成を自動的に更新できるメカニズムを提案します。このメカニズムは、ルーターやファイアウォールなどのさまざまなデバイスに適したマクロを利用して、新しいプレフィックスに基づいて構成を更新します。このような自動化ツールは、エラーが発生しやすく非効率的な手動操作を削減できるため、番号を付け直すのに役立ちます。
Besides the macros, [LEROY] also proposes the use of SOAP to deliver the macros to the devices. Along with SOAP, we may consider whether it is possible and suitable to use other standardized protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241].
マクロに加えて、[LEROY]はSOAPを使用してマクロをデバイスに配信することも提案しています。 SOAPとともに、ネットワーク構成プロトコル（NETCONF）[RFC6241]などの他の標準プロトコルを使用することが可能で適切かどうかを検討する場合があります。
In current real networks, most devices use vendor-private protocols to update configurations, so it is not necessarily valid to assume that there is going to be a formalized configuration management system to leverage. Although there are some vendor-independent tools as mentioned in Section 3.2, a standard and comprehensive way to uniformly update configurations in multi-vendor devices is still missing.
現在の実際のネットワークでは、ほとんどのデバイスがベンダープライベートプロトコルを使用して構成を更新しているため、活用する正式な構成管理システムがあると想定することは必ずしも有効ではありません。セクション3.2で述べたように、ベンダーに依存しないツールがいくつかありますが、マルチベンダーデバイスの構成を均一に更新するための標準的で包括的な方法はまだありません。
From the perspective of network management, renumbering is an event that may need additional processes to make it easier and more manageable.
ネットワーク管理の観点からは、再番号付けは、より簡単で管理しやすくするために追加のプロセスが必要になる可能性があるイベントです。
The process of renumbering could benefit from hosts or servers being made aware of an occurrence of a renumbering event. Following are several examples of additional processes that may ease renumbering.
再番号付けのプロセスは、再番号付けイベントの発生をホストまたはサーバーに認識させることでメリットを得られます。以下は、番号の付け直しを容易にする可能性がある追加のプロセスのいくつかの例です。
o A notification mechanism may be needed to indicate to hosts that a renumbering event has changed some DNS records in DNS servers (normally, in an enterprise, it is a local recursive DNS server(s)), and then the hosts might want to refresh the DNS cache. That mechanism may also need to indicate that such a change will happen at a specific time in the future.
o 再番号付けイベントによってDNSサーバー（通常、企業ではローカルの再帰DNSサーバー）の一部のDNSレコードが変更されたことをホストに示すために、通知メカニズムが必要になる場合があります。 DNSキャッシュ。そのメカニズムは、そのような変更が将来の特定の時間に発生することを示す必要がある場合もあります。
o As suggested in [RFC4192], if the DNS service can be given prior notice about a renumbering event, then delay in the transition to new IPv6 addresses could be reduced and thus improve the efficiency of renumbering.
o [RFC4192]で提案されているように、DNSサービスに再番号付けイベントに関する事前通知を与えることができれば、新しいIPv6アドレスへの移行の遅延が減少し、再番号付けの効率が向上します。
o Router awareness: In a site with multiple domains that are connected by border routers, all border routers should be aware of renumbering in one domain or multiple domains and update the internal forwarding tables and the address-/prefix-based filters accordingly to correctly handle inbound packets.
o ルーター認識：ボーダールーターで接続されている複数のドメインがあるサイトでは、すべてのボーダールーターが1つのドメインまたは複数のドメインでの再番号付けを認識し、内部転送テーブルとアドレス/プレフィックスベースのフィルターを更新して、インバウンドを正しく処理する必要があります。パケット。
o Ingress filtering: ISPs normally enable an ingress filter to drop packets with source addresses from other ISPs at the end-site routers to prevent IP spoofing [RFC2827]. In a multihomed site with multiple PA prefixes, the ingress router of ISP A should be notified if ISP B initiates a renumbering event in order to properly update its filters to permit the new legitimate prefix(es). For large enterprises, it might be practical to manage this new legitimate prefix information through human communication. However, for the millions of small enterprises, an automated notification mechanism is needed.
o 入力フィルタリング：ISPは通常、IPスプーフィング[RFC2827]を防止するために、エンドサイトルーターで他のISPからの送信元アドレスを持つパケットをドロップするために入力フィルターを有効にします。複数のPAプレフィックスを持つマルチホームサイトでは、新しい正当なプレフィックスを許可するようにフィルターを適切に更新するために、ISP Bが再番号付けイベントを開始した場合、ISP Aの入力ルーターに通知する必要があります。大企業の場合、この新しい正当なプレフィックス情報を人間のコミュニケーションを通じて管理することが現実的です。ただし、数百万の中小企業では、自動通知メカニズムが必要です。
o Log collectors: In the NMS (network management system), log collectors that collect logs through syslog, SNMP notification, IPFIX, etc. usually treat the UDP message source IP addresses as the host or router IDs. When one source IP address is changed, the log collectors will consider that a new device appeared in the network. Therefore, a mechanism is needed for the NMS applications to learn the renumbering event including the mappings of old and new IP addresses for each host/router, so that they could update the address-relevant mappings as described in Section 7.2.
o ログコレクター：NMS（ネットワーク管理システム）では、syslog、SNMP通知、IPFIXなどを通じてログを収集するログコレクターは、通常、UDPメッセージの送信元IPアドレスをホストまたはルーターIDとして扱います。 1つのソースIPアドレスが変更されると、ログコレクターは新しいデバイスがネットワークに出現したと見なします。したがって、NMSアプリケーションがセクション7.2で説明されているようにアドレス関連のマッピングを更新できるように、各ホスト/ルーターの新旧のIPアドレスのマッピングを含む再番号付けイベントを学習するメカニズムが必要です。
o DNS Update Synchronization
o DNS更新の同期
The DNS changes must be coordinated with node address configuration changes. DNS has a latency issue of propagating information from the server to the resolver. The latency is mainly caused by the Time to Live (TTL) assigned to individual DNS records and the timing of updates from primary to secondary servers [RFC4192].
DNSの変更は、ノードアドレス構成の変更と調整する必要があります。 DNSには、サーバーからリゾルバに情報を伝播するというレイテンシの問題があります。待ち時間は主に、個々のDNSレコードに割り当てられた存続時間（TTL）と、プライマリサーバーからセカンダリサーバーへの更新のタイミング[RFC4192]によって発生します。
Ideally, during a renumbering operation, the DNS TTLs should always be shorter than any other lifetimes associated with an address. If the TTLs were set correctly, then the DNS latency could be well controlled. However, there might be some exceptional situations in which the DNS TTLs were already set too long for the time available to plan and execute a renumbering event. In these situations, there are currently no mechanisms to deal with the already configured long DNS TTLs.
理想的には、再番号付け操作中、DNS TTLは常に、アドレスに関連付けられた他のライフタイムよりも短くなければなりません。 TTLが正しく設定されていれば、DNSレイテンシを適切に制御できます。ただし、DNS TTLがすでに設定されており、再番号付けイベントの計画と実行に利用できる時間に対して長すぎるという例外的な状況が発生する場合があります。これらの状況では、すでに構成済みの長いDNS TTLを処理するメカニズムは現在ありません。
o NMS Address-Relevant Mapping Synchronization
o NMSアドレス関連のマッピング同期
As described in Section 7.1, the NMS needs to learn the renumbering event and thus correlate the old and new address in the logs. If the NMS applies unique IDs for the hosts or routers, then the mappings between the unique IDs and IP addresses also need to be updated after renumbering.
セクション7.1で説明したように、NMSは再番号付けイベントを学習し、ログの古いアドレスと新しいアドレスを関連付ける必要があります。 NMSがホストまたはルーターに一意のIDを適用する場合は、一意のIDとIPアドレス間のマッピングも、番号を付け直した後に更新する必要があります。
While treating renumbering as a network event, mechanisms to monitor the renumbering process might be needed to inform the administrators whether the renumbering has been successful. Considering that the address configuration operation might be stateless (if ND is used for renumbering), it is difficult to monitor.
再番号付けがネットワークイベントとして扱われている間、再番号付けが成功したかどうかを管理者に通知するには、再番号付けプロセスを監視するメカニズムが必要になる場合があります。アドレス構成操作がステートレスである可能性があることを考慮して（NDが番号の付け直しに使用されている場合）、監視することは困難です。
Since multicast and mobility are special use cases that might not be included in routine or common renumbering operations, they are discussed separately in this miscellaneous section.
マルチキャストとモビリティは特殊な使用例であるため、ルーチンまたは一般的な番号の付け直しの操作には含まれない場合があるため、これらについては、このさまざまなセクションで個別に説明します。
From the perspective of interface renumbering operations, renumbering a multicast address is the same as renumbering a unicast address. So this section mainly discusses the issues from the perspective of the impact to the multicast application systems caused by renumbering. Renumbering also has an impact on multicast. Renumbering of unicast addresses affects multicast even if the multicast addresses are not changed. There may also be cases where the multicast addresses need to be renumbered.
インターフェイスの再番号付け操作の観点から見ると、マルチキャストアドレスの再番号付けは、ユニキャストアドレスの再番号付けと同じです。したがって、このセクションでは主に、番号の付け替えによるマルチキャストアプリケーションシステムへの影響の観点から問題について説明します。再番号付けもマルチキャストに影響を与えます。ユニキャストアドレスの再番号付けは、マルチキャストアドレスが変更されていなくてもマルチキャストに影響します。マルチキャストアドレスの番号を変更する必要がある場合もあります。
o Renumbering of Multicast Sources
o マルチキャストソースの再番号付け
If a host that is a multicast source is renumbered, the application on the host may need to be restarted for it to successfully send packets with the new source address.
マルチキャストソースであるホストの番号が変更された場合、新しいソースアドレスでパケットを正常に送信するには、ホスト上のアプリケーションを再起動する必要がある場合があります。
For ASM (Any-Source Multicast), the impact on a receiver is that a new source appears to start sending and it no longer receives from the previous source. Whether this is an issue depends on the application, but we believe it is likely not to be a major issue.
ASM（Any-Source Multicast）の場合、レシーバーへの影響は、新しいソースが送信を開始したように見え、以前のソースから受信しなくなったことです。これが問題であるかどうかはアプリケーションによって異なりますが、大きな問題ではないようです。
For SSM (Source-Specific Multicast) however, there is one significant problem. The receiver needs to learn which source addresses it must join. Some applications may provide their own method for learning sources, where the source application may somehow signal the receiver.
ただし、SSM（Source-Specific Multicast）の場合、1つの重大な問題があります。受信者は、参加する必要がある送信元アドレスを知る必要があります。一部のアプリケーションは、ソースを学習するための独自の方法を提供する場合があり、ソースアプリケーションは何らかの方法でレシーバーに信号を送る場合があります。
Otherwise, the receiver may, for example, need to get new SDP (Session Description Protocol) information with the new source address. This is similar to the process for learning a new group address; see the "Renumbering of Multicast Addresses" topic below.
それ以外の場合、受信者は、たとえば、新しい送信元アドレスで新しいSDP（Session Description Protocol）情報を取得する必要があります。これは、新しいグループアドレスを学習するプロセスに似ています。以下の「マルチキャストアドレスの再番号付け」トピックを参照してください。
o Renumbering of Rendezvous-Point
o ランデブーポイントの再番号付け
If the unicast addresses of routers in a network are renumbered, then the RP (Rendezvous-Point) address is also likely to change for at least some groups. An RP address is needed by PIM-SM (Protocol Independent Multicast - Sparse Mode) to provide ASM and for Bidir PIM. Changing the RP address is not a major issue, except that the multicast service may be impacted while the new RP addresses are configured. If dynamic protocols are used to distribute group-to-RP mappings, the change can be fairly quick and any impact time should be very brief. However, if routers are statically configured, the time impacted depends on how long it takes to update all the configurations.
ネットワーク内のルーターのユニキャストアドレスの番号が変更された場合、少なくとも一部のグループではRP（ランデブーポイント）アドレスも変更される可能性があります。 RPアドレスは、PIM-SM（プロトコルに依存しないマルチキャスト-スパースモード）でASMを提供するため、およびBidir PIMのために必要です。 RPアドレスの変更は大きな問題ではありませんが、新しいRPアドレスの構成中にマルチキャストサービスが影響を受ける可能性があります。動的プロトコルを使用してグループからRPへのマッピングを配布する場合、変更はかなり速くなる可能性があり、影響時間は非常に短いはずです。ただし、ルーターが静的に構成されている場合、影響を受ける時間は、すべての構成の更新にかかる時間によって異なります。
For PIM-SM, one typically switches to SPT (Shortest-Path-Tree) when the first packet is received by the last-hop routers. Forwarding on the SPT should not be impacted by the change of IP address. A network operator should be careful not to deprecate the previous mapping before configuring a new one, because implementations may revert to Dense Mode if no RP is configured.
PIM-SMの場合、最初のパケットがラストホップルーターによって受信されると、通常はSPT（Shortest-Path-Tree）に切り替わります。 SPTでの転送は、IPアドレスの変更の影響を受けません。ネットワークオペレーターは、新しいマッピングを構成する前に、以前のマッピングを廃止しないように注意する必要があります。RPが構成されていない場合、実装は高密度モードに戻る可能性があるためです。
o Renumbering of Multicast Addresses
o マルチキャストアドレスの再番号付け
In general, multicast addresses can be chosen independently of the unicast addresses, and the multicast addresses can remain fixed even if the unicast addresses are renumbered. However, for IPv6, there are useful ways of deriving multicast addresses from unicast addresses, such as described in "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] and "Embedded-RP IPv6 Multicast Addresses" [RFC3956]. In those cases, the multicast addresses used may have to be renumbered.
一般に、マルチキャストアドレスはユニキャストアドレスとは無関係に選択でき、ユニキャストアドレスの番号が変更されても、マルチキャストアドレスは固定されたままになります。ただし、IPv6の場合、「ユニキャストプレフィックスベースのIPv6マルチキャストアドレス」[RFC3306]や「Embedded-RP IPv6マルチキャストアドレス」[RFC3956]で説明されているように、ユニキャストアドレスからマルチキャストアドレスを導出する便利な方法があります。このような場合、使用されるマルチキャストアドレスの番号を変更する必要があります。
Renumbering group addresses may be complicated. For multicast, it is common to use literal addresses and not DNS. When multicast addresses are changed, source applications need to be reconfigured and restarted.
グループアドレスの再番号付けは複雑になる場合があります。マルチキャストの場合、DNSではなくリテラルアドレスを使用するのが一般的です。マルチキャストアドレスが変更された場合、ソースアプリケーションを再構成して再起動する必要があります。
Multicast receivers need to learn the new group addresses to join.
マルチキャストレシーバーは、参加する新しいグループアドレスを学習する必要があります。
Note that for SSM, receivers need to learn which multicast channels to join. A channel is a source and group pair. This means that for an SSM application, a change of source address is likely to have the same effect as a change of group address.
SSMの場合、受信者は参加するマルチキャストチャネルを学習する必要があることに注意してください。チャネルはソースとグループのペアです。つまり、SSMアプリケーションの場合、送信元アドレスの変更は、グループアドレスの変更と同じ効果を持つ可能性があります。
Some applications may have dynamic methods of learning which groups (and possibly sources) to join. If not, the application may have to be reconfigured and restarted.
一部のアプリケーションには、参加するグループ（および場合によってはソース）を動的に学習する方法があります。そうでない場合は、アプリケーションを再構成して再起動する必要があります。
One common way for receivers to learn the necessary parameters is by use of SDP. SDP information may be distributed via various application protocols or from a file. An SDP file may be distributed via HTTP, email, etc. If a user is using a web browser and clicking on a link to launch the application with the necessary data, it may be a matter of closing the current application and re-clicking the link.
レシーバーが必要なパラメーターを学習するための一般的な方法の1つは、SDPを使用することです。 SDP情報は、さまざまなアプリケーションプロトコルを介して、またはファイルから配布できます。 SDPファイルは、HTTP、電子メールなどを介して配布される場合があります。ユーザーがWebブラウザーを使用してリンクをクリックし、必要なデータを含むアプリケーションを起動する場合、現在のアプリケーションを閉じて再度クリックするだけで問題が発生する可能性があります。リンク。
In summary, currently, multicast renumbering issues are basically handled by application-specific methods. There is no standard way to guarantee that multicast service could live across a renumbering event.
要約すると、現在、マルチキャストの再番号付けの問題は、基本的にアプリケーション固有の方法で処理されます。マルチキャストサービスがリナンバリングイベント全体で機能することを保証する標準的な方法はありません。
As described in [RFC5887], if a mobile node's home address changes unexpectedly, the node can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. However, if the mobile node is disconnected at the time of home address renumbering, it will no longer know a valid subnet anycast address for its home agent, leaving it to deduce a valid address on the basis of DNS information.
[RFC5887]で説明されているように、モバイルノードのホームアドレスが予期せず変更された場合、ノードはモバイルプレフィックス要請およびモバイルプレフィックスアドバタイズメントICMPv6メッセージ[RFC6275]を通じて、ホームサイトで使用される新しいグローバルルーティングプレフィックスを通知できます。ただし、ホームアドレスの再番号付け時にモバイルノードが切断されると、モバイルエージェントはホームエージェントの有効なサブネットエニーキャストアドレスを認識できなくなり、DNS情報に基づいて有効なアドレスを推定します。
So, for Mobile IP, we need a better mechanism to handle the change of home agent address while the mobile address is disconnected.
したがって、モバイルIPの場合、モバイルアドレスが切断されている間にホームエージェントアドレスの変更を処理するためのより良いメカニズムが必要です。
The following is a summary of the gaps identified previously in this document that are considered solvable, but may require process or protocol changes to resolve.
以下は、このドキュメントで以前に特定された、解決可能と見なされているギャップの概要ですが、解決するにはプロセスまたはプロトコルの変更が必要になる場合があります。
o A mechanism informing the routers to renumber themselves by delegated prefixes.
o 委任されたプレフィックスによって番号を付け直すようにルーターに通知するメカニズム。
o A mechanism for the routers to derive addresses automatically based on the delegated prefixes.
o 委任されたプレフィックスに基づいてルーターがアドレスを自動的に導出するメカニズム。
o Host Address Configuration
o ホストアドレスの構成
- DHCPv6-configured hosts might not be able to be renumbered by RA on some current implementations.
- DHCPv6で構成されたホストは、現在の実装によっては、RAによって番号が付け替えられない場合があります。
- DHCPv6-configured hosts might not be able to learn new RA prefixes on some current implementations.
- DHCPv6構成のホストは、一部の現在の実装では新しいRAプレフィックスを学習できない場合があります。
- SLAAC-configured hosts might not be able to add DHCPv6 address(es) on some current implementations.
- 現在の実装によっては、SLAAC構成のホストがDHCPv6アドレスを追加できない場合があります。
o Router Address Configuration
o ルーターアドレス設定
- A mechanism for interior routers in a multihomed site to learn which upstream providers and prefixes are currently reachable.
- マルチホームサイトの内部ルーターが現在到達可能なアップストリームプロバイダーとプレフィックスを知るためのメカニズム。
- Cache-clear might need to restart (rarely in modern routers).
- キャッシュクリアは再起動する必要があるかもしれません（最近のルーターではまれです）。
- Use of router domain names is not widely learned or deployed by administrators.
- ルータードメイン名の使用は、管理者によって広く学習または配備されていません。
o DNS Records Update
o DNSレコードの更新
- For key-management scalability issues, secure dynamic DNS update is usually done by DHCP servers on behalf of the hosts, so it might not be practical for SLAAC-configured hosts to do secure DDNS.
- キー管理のスケーラビリティの問題の場合、安全な動的DNS更新は通常、ホストの代わりにDHCPサーバーによって行われるため、SLAACが構成されたホストが安全なDDNSを実行するのは現実的ではない場合があります。
o In-Host Server Address Update
o ホスト内サーバーアドレスの更新
- DHCP relays might be configured with DHCP server addresses rather than by sending multicast messages to discover the DHCP server dynamically, so updating the DHCP server addresses might be an issue in practice.
- DHCPリレーは、マルチキャストメッセージを送信してDHCPサーバーを動的に検出するのではなく、DHCPサーバーアドレスで構成されている可能性があるため、実際にはDHCPサーバーアドレスの更新が問題になる場合があります。
o Address Update in Scattered Configurations
o 分散構成でのアドレス更新
- For devices that don't support parameterized configuration, administrators need to individually update all devices in which IP addresses were previously configured.
- パラメータ化された構成をサポートしないデバイスの場合、管理者は、IPアドレスが以前に構成されていたすべてのデバイスを個別に更新する必要があります。
- It is hard to get all the address-relevant configurations spread in various devices through one place.
- さまざまなデバイスですべてのアドレス関連の構成を1か所に分散させることは困難です。
- Uniformly updating configurations in multi-vendor devices is currently a big gap that needs to be filled.
- マルチベンダーデバイスの構成を均一に更新することは、現在、埋める必要のある大きなギャップです。
o Renumbering Notification
o 再番号付け通知
- A mechanism to indicate a host's local recursive DNS is going to be renumbered.
- ホストのローカル再帰DNSが再番号付けされることを示すメカニズム。
- A prior notice about a renumbering event for DNS.
- DNSの再番号付けイベントに関する事前通知。
- A mechanism for border routers to know internal partial renumbering.
- ボーダールータが内部の部分的な再番号付けを認識するためのメカニズム。
- For multihomed sites, a mechanism is needed to notify the egress router connecting to ISP A that the egress router connecting to ISP B has initiated renumbering.
- マルチホームサイトの場合、ISP Aに接続している出力ルーターに、ISP Bに接続している出力ルーターが再番号付けを開始したことを通知するメカニズムが必要です。
- A mechanism is needed for the NMS applications to learn the renumbering event, so that they could correlate the old and new addresses in the logs, and update the unique ID of the device and address mappings.
- NMSアプリケーションが再番号付けイベントを学習して、ログ内の古いアドレスと新しいアドレスを関連付け、デバイスの一意のIDとアドレスマッピングを更新できるようにするメカニズムが必要です。
o Synchronization Management
o 同期管理
- DNS information propagation latency issue.
- DNS情報の伝搬遅延の問題。
- Mechanisms are needed for the NMS applications to correlate the old and new addresses in logs and to update the unique ID of the device and address mappings.
- NMSアプリケーションがログ内の古いアドレスと新しいアドレスを関連付け、デバイスの一意のIDとアドレスマッピングを更新するためのメカニズムが必要です。
o Renumbering Monitoring
o モニタリングの再番号付け
- Mechanisms to monitor the process and feedback of renumbering might be needed.
- 再番号付けのプロセスとフィードバックを監視するメカニズムが必要になる場合があります。
o Multicast
o マルチキャスト
- A mechanism for SSM receivers to learn the source addresses when multicast sources are renumbered.
- SSMレシーバーがマルチキャストソースの番号が付け直されたときにソースアドレスを学習するためのメカニズム。
o Mobility
o 可動性
- A better mechanism to handle a change of home agent address while the mobile address is disconnected.
- モバイルアドレスが切断されている間にホームエージェントアドレスの変更を処理するためのより良いメカニズム。
This section lists gaps that have been identified by other documents but are considered unsolvable.
このセクションでは、他のドキュメントで特定されているが解決できないと見なされているギャップをリストします。
o RA Prefix Lifetime Limitation
o RAプレフィックスのライフタイム制限
Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime." So when renumbering, if the previous RemainingLifetime is longer than two hours, it is impossible to reduce a prefix's lifetime to less than two hours. This limitation is to prevent denial-of-service attacks.
[RFC4862]のセクション5.5.3には、「受信した有効期間が2時間を超えるか、RemainingLifetimeを超える場合は、対応するアドレスの有効期間をアドバタイズされた有効期間に設定します。」したがって、番号を付け直すときに、前のRemainingLifetimeが2時間より長い場合、プレフィックスの有効期間を2時間未満に減らすことはできません。この制限は、サービス拒否攻撃を防ぐためのものです。
o DNS Authority
o DNS機関
In an enterprise that hosts servers on behalf of collaborators and customers, it is often the case that DNS zones outside the administrative control of the hosting enterprise maintain resource records concerning addresses for hosted nodes within its address space. When the hosting enterprise renumbers, it does not have sufficient authority to change those records.
共同作業者や顧客に代わってサーバーをホストする企業では、ホスティング企業の管理制御外のDNSゾーンが、ホストされたノードのアドレスに関するリソースレコードをそのアドレススペース内に維持することがよくあります。ホスティングエンタープライズの番号が変更された場合、それらのレコードを変更するための十分な権限がありません。
This is an operational and policy issue. It is out of scope for this document to consider a technical solution or to propose an additional protocol or mechanism to standardize the interaction between DNS systems for authority negotiations.
これは運用上およびポリシー上の問題です。技術的な解決策を検討したり、権限交渉のためにDNSシステム間の相互作用を標準化するための追加のプロトコルまたはメカニズムを提案したりすることは、このドキュメントの範囲外です。
o DNS Entries
o DNSエントリ
DNS entries commonly have matching reverse DNS entries that will also need to be updated during renumbering. It might not be possible to combine forward and reverse DNS entry updates in one procedure where addresses are not being managed using DHCP.
DNSエントリには通常、一致する逆DNSエントリがあり、番号の付け直し中にも更新する必要があります。 DHCPを使用してアドレスが管理されていない1つの手順で、フォワードおよびリバースDNSエントリの更新を組み合わせることができない場合があります。
o DNS Data Structure Optimization
o DNSデータ構造の最適化
[RFC2874] proposed an A6 record type for DNS recording of the IPv6 address and prefix. Several extensions to DNS query and processing were also proposed. A6 was designed to be a replacement for the AAAA record. The changes were designed to facilitate network renumbering and multihoming. With the A6 record and the extensions, an IPv6 address could be defined by using multiple DNS records. This feature would increase the complexity of resolvers but reduce the cost of zone file maintenance, so renumbering could be easier than with the AAAA record.
[RFC2874]は、IPv6アドレスとプレフィックスのDNS記録用にA6レコードタイプを提案しました。 DNSクエリと処理に対するいくつかの拡張も提案されました。 A6は、AAAAレコードの代わりになるように設計されました。この変更は、ネットワークの再番号付けとマルチホーミングを容易にするために設計されました。 A6レコードと拡張を使用すると、複数のDNSレコードを使用してIPv6アドレスを定義できます。この機能により、リゾルバーの複雑さが増しますが、ゾーンファイルのメンテナンスのコストが削減されるため、AAAAレコードよりも番号の付け直しが簡単になります。
[RFC2874] has been deprecated and moved to Historic status by
[RFC6563]. The A6 record has not been widely used and has been
shown to have various problems and disadvantages (see Section 2 in
[RFC6563]). The idea of a structured record to separate prefix
and suffix is still potentially valuable for renumbering, but
avoiding the problems of the A6 record would require a major
development effort.
o For the transport layer, [RFC5887] said that TCP connections and UDP flows are rigidly bound to a given pair of IP addresses.
o トランスポート層については、[RFC5887]は、TCP接続とUDPフローは特定のIPアドレスのペアに厳密にバインドされていると述べています。
o For the application layer, in general, we can assert that any implementation is at risk from renumbering if it does not check whether an address is valid each time it starts session resumption (e.g., a laptop wakes from sleep state). It is also more or less risky when it opens a new communications session by using cached addresses.
o アプリケーションレイヤーの場合、一般的に、セッションの再開を開始するたびにアドレスが有効であるかどうかをチェックしない場合（ラップトップがスリープ状態からウェイクアップするなど）、実装が再番号付けされるリスクがあると断言できます。また、キャッシュされたアドレスを使用して新しい通信セッションを開く場合にも、多少の危険があります。
We considered the above two points (ID/Locator overloading in transport layer and address caching in application layer) fundamental issues that might not be proper to deal with just in terms of renumbering.
上記の2つのポイント（トランスポートレイヤーでのID /ロケーターのオーバーロードとアプリケーションレイヤーでのアドレスキャッシング）の基本的な問題を検討しましたが、これらはリナンバリングだけでは適切に処理できない可能性があります。
o Prefix Validation
o プレフィックス検証
Prefixes from the ISP may need authentication to prevent prefix fraud. Announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question) also needs validation.
ISPからのプレフィックスは、プレフィックス詐欺を防ぐために認証が必要な場合があります。他のサイト（たとえば、問題のサイトを指すようにルーターまたはVPNを構成するサイト）へのサイトプレフィックスの変更を通知する場合も、検証が必要です。
In the LAN, Secure DHCPv6 [SECURE-DHCPv6] or Secure Neighbor Discovery (SEND) [RFC3971] deployment may be needed to validate prefixes.
LANでは、プレフィックスを検証するために、Secure DHCPv6 [SECURE-DHCPv6]またはSecure Neighbor Discovery（SEND）[RFC3971]の展開が必要になる場合があります。
o Influence on Security Controls
o セキュリティ管理への影響
During renumbering, security controls (e.g., ACLs) protecting legitimate resources should not be interrupted. For example, if some addresses are in a blacklist, they should not escape from the blacklist due to renumbering.
番号を付け直す間、正当なリソースを保護するセキュリティ制御（ACLなど）が中断されないようにする必要があります。たとえば、一部のアドレスがブラックリストに含まれている場合、番号が付け直されるため、それらのアドレスがブラックリストから脱出してはなりません。
Addresses in SEND certificates will need to get updated when renumbering. During the overlap between old and new addresses, both certificates must remain valid.
SEND証明書のアドレスは、番号を付け直すときに更新する必要があります。古いアドレスと新しいアドレスが重複している間、両方の証明書が有効なままである必要があります。
o Security Protection for Renumbering Notification
o 番号変更通知のセキュリティ保護
Section 7.1 mentions possible notification mechanisms to signal a change in the DNS system or in the border routers related to a renumbering event. Since the DNS system and border routers are key elements in any network, and they might take action according to the notification, a security authentication for the renumbering notification is needed.
セクション7.1では、再番号付けイベントに関連するDNSシステムまたは境界ルーターの変更を通知するための可能な通知メカニズムについて説明しています。 DNSシステムと境界ルーターはどのネットワークでも重要な要素であり、通知に従ってアクションを実行する可能性があるため、再番号付け通知のセキュリティ認証が必要です。
o Security Protection for Configuration Update
o 構成更新のセキュリティ保護
Automated configuration update approaches like [LEROY] would increase the risk since a bad actor with the right permission could cause havoc to the networks.
[LEROY]のような自動化された構成更新アプローチは、適切な権限を持つ悪質なアクターがネットワークに大混乱を引き起こす可能性があるため、リスクを増大させます。
This work adopts significant amounts of content from [RFC5887]. In addition, it draws largely from the "DNS Authority" topic in Section 10.2 from [IPv6-RENUM-THINK]. Both documents offer such important input for this work that some principles and considerations applied in this work are implicitly inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were provided by Oliver Bonaventure and his student, Damien Leroy.
この作品は[RFC5887]からのかなりの量のコンテンツを採用しています。さらに、[IPv6-RENUM-THINK]のセクション10.2の「DNS Authority」トピックから大きく引用されます。どちらのドキュメントも、この作業に非常に重要な情報を提供しているため、この作業に適用されるいくつかの原則と考慮事項は、暗黙的に継承されています。 Randall Atkinson、Hannu Flinck、Tim Chown、Mark Thompson、Alan Fordに感謝します。いくつかの有用な資料は、オリバーボナベンチャーと彼の学生、ダミアンリロイによって提供されました。
Many useful comments and contributions were made by Ted Lemon, Lee Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke, Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot, and other members of the 6renum WG.
テッドレモン、リーハワード、ロバートスパークス、S。ムーネサミー、フレッドベイカー、ショーンターナー、ブノワクレイズ、スティーブンファレル、ブライアンハーバーマン、ジョエルジャグリ、エリックヴィンケ、フィリップスマシュー、ベネディクトシュトックブランド、グスタフラインスベルガー、Teco Boot、および6renum WGの他のメンバー。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3315] Droms, R., Ed., 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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、2003年7月。
[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月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072] Berkowitz、H。、「Router Renumbering Guide」、RFC 2072、1997年1月。
[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.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]クロフォードM.およびC.ホイテマ、「IPv6アドレスの集約と再番号付けをサポートするDNS拡張機能」、RFC 2874、2000年7月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894] Crawford、M。、「Router Renumbering for IPv6」、RFC 2894、2000年8月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-Prefix-based IPv6 Multicast Addresses」、RFC 3306、2002年8月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、2004年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F。、リア、E。、およびR.ドロムス、「フラグデーのないIPv6ネットワークの番号を付け直すための手順」、RFC 4192、2005年9月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704] Volz、B。、「IPv6の動的ホスト構成プロトコル（DHCPv6）クライアントの完全修飾ドメイン名（FQDN）オプション」、RFC 4704、2006年10月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、A。Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984] Meyer、D。、編、Zhang、L。、編、およびK. Fall、編、「ルーティングとアドレッシングに関するIABワークショップからの報告」、RFC 4984、2007年9月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887] Carpenter、B.、Atkinson、R。、およびH. Flinck、「Renumbering Still Needs Work」、RFC 5887、2010年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, March 2012.
[RFC6563] Jiang、S.、Conrad、D。、およびB. Carpenter、「A6を歴史的ステータスに移行」、RFC 6563、2012年3月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「Default Protocol Selection for Internet Protocol Version 6（IPv6）」、RFC 6724、2012年9月。
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013.
[RFC6866] Carpenter、B。およびS. Jiang、「エンタープライズネットワークで静的アドレスを使用してIPv6ホストの番号を再設定するための問題ステートメント」、RFC 6866、2013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、2013年2月。
[6MAN-ADDR-OPT] Matsumoto, A., Fujisaki T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, August 2013.
[6MAN-ADDR-OPT]松本明朗、藤崎武司、T。チョン、「DHCPv6を使用したアドレス選択ポリシーの配布」、2013年8月、作業中。
[6RENUM-SLAAC] Liu, B., "DHCPv6/SLAAC Address Configuration Switching for Host Renumbering", Work in Progress, January 2013.
[6RENUM-SLAAC] Liu、B。、「DHCPv6 / SLAACアドレス構成の切り替えによるホストの再番号付け」、作業中、2013年1月。
[CFENGINE] CFEngine, <http://cfengine.com/what-is-cfengine>.
[CFENGINE] CFEngine、<http://cfengine.com/what-is-cfengine>。
[DHCPv6-SLAAC] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, February 2013.
[DHCPv6-SLAAC] Liu、B。およびR. Bonica、「DHCPv6 / SLAACアドレス構成の相互作用の問題に関する記述」、作業中、2013年2月。
[IPv6-RENUM-THINK] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[IPv6-RENUM-THINK] Chown、T.、Thompson、M.、Ford、A。、およびS. Venaas、「IPv6ネットワークの番号を再設定する際に考慮すべきこと」、進行中の作業、2006年9月。
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network
configurations for IPv6 renumbering", International of
Network Management, 2009, <http://inl.info.ucl.ac.be/
system/files/dleroy-nem-2009.pdf>
[PREFIX-DHCPv6] Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment in DHCPv6", Work in Progress, February 2013.
[PREFIX-DHCPv6] Jiang、S.、Xia、F。、およびB. Sarikaya、「DHCPv6でのプレフィックス割り当て」、Work in Progress、2013年2月。
[SECURE-DHCPv6] Jiang, S. and Shen S., "Secure DHCPv6 Using CGAs", Work in Progress, September 2012.
[SECURE-DHCPv6] Jiang、S。およびShen S。、「Secure DHCPv6 Using CGAs」、Work in Progress、2012年9月。
Authors' Addresses
著者のアドレス
Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: leo.liubing@huawei.com
Bing l IU hu A is Technologies co。、Ltd Q14、hu A is campus no。156 be i青RD。h爱-D Ian District、Beijing 100095 P.R. China email：Leo。溜冰@华华.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No. 156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
S横江hu Aはテクノロジー株式会社Q14、hu Aはキャンパス番号156はi青RDですh爱-Dイアン地区、北京100095 P.R.中国Eメール：natal@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
ブライアンカーペンターコンピューターサイエンス大学オークランド大学PB 92019オークランド、1142ニュージーランドメール：brian.e.carpenter@gmail.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 United States EMail: stig@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 United States EMail：stig@cisco.com
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States Phone: +1 703-561-2540 EMail: wesley.george@twcable.com
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171 United States電話：+1 703-561-2540メール：wesley.george@twcable.com