[要約] 要約： RFC 6879は、IPv6エンタープライズネットワークの再番号付けシナリオ、考慮事項、および方法に関するガイドラインです。目的： このRFCの目的は、IPv6ネットワークの再番号付けに関連する問題や課題を理解し、効果的な再番号付け戦略を開発するための指針を提供することです。
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6879 B. Liu
Category: Informational Huawei Technologies Co., Ltd.
ISSN: 2070-1721 B. Carpenter
University of Auckland
February 2013
IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
IPv6エンタープライズネットワークの再番号付けのシナリオ、考慮事項、および方法
Abstract
概要
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
このドキュメントでは、再番号付けの原因となるイベントを分析し、現在の再番号付け方法について説明します。これらは3つのカテゴリで説明されています。ネットワーク設計中に適用されるもの、再番号付けの準備中に適用されるもの、および再番号付け操作中に適用されるものです。
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/rfc6879.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6879で入手できます。
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 ....................................................2
2. Enterprise Network Illustration for Renumbering .................3
3. Enterprise Network Renumbering Scenario Categories ..............5
3.1. Renumbering Caused by External Network Factors .............5
3.2. Renumbering Caused by Internal Network Factors .............5
4. Network Renumbering Considerations and Current Methods ..........6
4.1. Considerations and Current Methods during Network Design ...6
4.2. Considerations and Current Methods for the
Preparation of Renumbering ................................10
4.3. Considerations and Current Methods during
Renumbering Operation .....................................11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................15
Site renumbering is difficult. Network managers frequently attempt to avoid future renumbering by numbering their network resources from Provider-Independent (PI) address space. However, widespread use of PI address space would aggravate BGP4 scaling problems [RFC4116] and, depending on Regional Internet Registry (RIR) policies, PI space is not always available for enterprises of all sizes. Therefore, it is desirable to develop mechanisms that simplify IPv6 renumbering for enterprises.
サイトの再番号付けは困難です。ネットワーク管理者は、プロバイダーに依存しない（PI）アドレス空間からネットワークリソースに番号を付けることで、将来の再番号付けを回避しようとすることがよくあります。ただし、PIアドレススペースを広く使用すると、BGP4スケーリングの問題が悪化します[RFC4116]。また、Regional Internet Registry（RIR）ポリシーによっては、PIスペースがすべての規模の企業で常に利用できるとは限りません。したがって、企業のIPv6再番号付けを簡素化するメカニズムを開発することが望まれます。
This document is an analysis of IPv6 site renumbering for enterprise networks. It undertakes scenario descriptions, including documentation of current capabilities and existing practices. The reader is assumed to be familiar with [RFC4192] and [RFC5887]. Proposals for new technology and methods are out of scope.
このドキュメントは、エンタープライズネットワークのIPv6サイトの番号付けの分析です。現在の機能や既存のプラクティスのドキュメント化など、シナリオの説明を引き受けます。読者は、[RFC4192]と[RFC5887]に精通していることを前提としています。新しい技術と方法の提案は範囲外です。
Since IPv4 and IPv6 are logically separate from the perspective of renumbering, regardless of overlapping of the IPv4/IPv6 networks or devices, this document focuses on IPv6 only, leaving IPv4 out of scope. Dual-stack networks or IPv4/IPv6 transition scenarios are out of scope as well.
IPv4とIPv6は、IPv4 / IPv6ネットワークまたはデバイスのオーバーラップに関係なく、再番号付けの観点から論理的に分離されているため、このドキュメントではIPv6のみに焦点を当て、IPv4は対象外とします。デュアルスタックネットワークまたはIPv4 / IPv6移行シナリオも対象外です。
This document focuses on enterprise network renumbering; however, most of the analysis is also applicable to ISP network renumbering. Renumbering in home networks is out of scope, but it can also benefit from the analysis in this document.
このドキュメントでは、エンタープライズネットワークの番号変更について重点的に説明します。ただし、ほとんどの分析はISPネットワークの番号付けにも適用できます。ホームネットワークでの再番号付けは範囲外ですが、このドキュメントの分析からもメリットが得られます。
The concept of an enterprise network and a typical network illustration are introduced first. Then, current renumbering methods are introduced according to the following categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.
まず、エンタープライズネットワークの概念と一般的なネットワークの図を紹介します。次に、現在の再番号付け方法が次のカテゴリに従って導入されます。ネットワーク設計中に適用できるもの、再番号付けの準備中に適用できるもの、および再番号付け操作中に適用できるもの。
An Enterprise Network, as defined in [RFC4057], is a network that has multiple internal links, has one or more router connections to one or more Providers, and is actively managed by a network operations entity.
[RFC4057]で定義されているエンタープライズネットワークは、複数の内部リンクがあり、1つ以上のプロバイダーへの1つ以上のルーター接続があり、ネットワーク運用エンティティによってアクティブに管理されているネットワークです。
Figure 1 provides a sample enterprise network architecture for a simple case. Those entities mainly affected by renumbering are illustrated:
図1は、単純なケースのサンプルのエンタープライズネットワークアーキテクチャを示しています。主に再番号付けの影響を受けるエンティティを以下に示します。
* Gateway (Border router, firewall, web cache, etc.)
* ゲートウェイ（ボーダールーター、ファイアウォール、Webキャッシュなど）
* Application server (for internal or external users)
* アプリケーションサーバー（内部または外部ユーザー用）
* DNS and DHCP servers
* DNSおよびDHCPサーバー
* Routers
* ルーター
* Hosts (desktops, etc.)
* ホスト（デスクトップなど）
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1. Enterprise Network Illustration
図1.エンタープライズネットワークの図
Address reconfiguration is fulfilled either by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) or by Neighbor Discovery (ND) for IPv6 protocols. During a renumbering event, the Domain Name Service (DNS) records need to be synchronized while routing tables, Access Control Lists (ACLs), and IP filtering tables in various devices also need to be updated. It is taken for granted that applications will work entirely on the basis of DNS names, but any direct dependencies on IP addresses in application-layer entities must also be updated.
アドレスの再構成は、IPv6の動的ホスト構成プロトコル（DHCPv6）またはIPv6プロトコルの近隣探索（ND）のいずれかによって実行されます。再番号付けイベント中、ルーティングテーブル、アクセス制御リスト（ACL）、およびさまざまなデバイスのIPフィルタリングテーブルも更新する必要がある一方で、ドメインネームサービス（DNS）レコードを同期する必要があります。アプリケーションがDNS名に基づいて完全に動作することは当然のことと考えられていますが、アプリケーション層エンティティのIPアドレスへの直接の依存関係も更新する必要があります。
The issue of static addresses is described in a dedicated document [RFC6866].
静的アドレスの問題は、専用のドキュメント[RFC6866]で説明されています。
The emerging cloud-based enterprise network architecture might be different than Figure 1. However, it is out of the scope of this document since it is far from mature and has not been widely deployed yet.
出現したクラウドベースのエンタープライズネットワークアーキテクチャは、図1とは異なる場合があります。ただし、まだ成熟しておらず、まだ広く展開されていないため、このドキュメントの範囲外です。
It is assumed that IPv6 enterprise networks are IPv6-only or dual-stack in which a logical IPv6 plane is independent from IPv4. As mentioned above, IPv4/IPv6 coexistence scenarios are out of scope.
IPv6エンタープライズネットワークは、IPv6のみ、または論理IPv6プレーンがIPv4から独立しているデュアルスタックであると想定されています。上記のように、IPv4 / IPv6共存シナリオは範囲外です。
This document focuses on routable unicast addresses; link-local, multicast, and anycast addresses are also out of scope.
このドキュメントでは、ルーティング可能なユニキャストアドレスに焦点を当てています。リンクローカル、マルチキャスト、およびエニーキャストアドレスも範囲外です。
In this section, we divide enterprise network renumbering scenarios into two categories defined by external and internal network factors, which require renumbering for different reasons.
このセクションでは、エンタープライズネットワークの再番号付けシナリオを、外部および内部のネットワーク要素によって定義される2つのカテゴリに分けます。これらの要因には、さまざまな理由で再番号付けが必要です。
The following ISP uplink-related events can cause renumbering:
次のISPアップリンク関連イベントにより、番号が付け直される可能性があります。
o The enterprise network switches to a new ISP. When this occurs, the enterprise stops numbering its resources from the prefix allocated by the old ISP and renumbers its resources from the prefix allocated by the new ISP.
o 企業ネットワークが新しいISPに切り替わります。これが発生すると、企業は古いISPによって割り当てられたプレフィックスからのリソースの番号付けを停止し、新しいISPによって割り当てられたプレフィックスからリソースの番号を付け直します。
When the enterprise switches ISPs, a "flag day" renumbering event [RFC4192] may be averted if, during a transitional period, the enterprise network may number its resources from either prefix. One way to facilitate such a transitional period is for the enterprise to contract service from both ISPs during the transition.
企業がISPを切り替えるとき、移行期間中に企業ネットワークがいずれかのプレフィックスからリソースに番号を付けることができる場合、「フラグデイ」番号付けイベント[RFC4192]が回避されることがあります。このような移行期間を促進する1つの方法は、移行中に企業が両方のISPからのサービスを契約することです。
o The renumbering event can be initiated by receiving new prefixes from the same uplink. This might happen if the enterprise network is switched to a different location within the network topology of the same ISP due to various considerations, such as commercial, performance or services reasons, etc. Alternatively, the ISP itself might be renumbered due to topology changes or migration to a different or additional prefix. These ISP renumbering events would initiate enterprise network renumbering events, of course.
o 同じアップリンクから新しいプレフィックスを受信することで、番号の付け直しイベントを開始できます。これは、商用、パフォーマンス、サービスの理由などのさまざまな考慮事項により、エンタープライズネットワークが同じISPのネットワークトポロジ内の別の場所に切り替えられた場合に発生する可能性があります。あるいは、トポロジの変更や別のまたは追加のプレフィックスへの移行。もちろん、これらのISP再番号付けイベントは、エンタープライズネットワークの再番号付けイベントを開始します。
o The enterprise network adds a new uplink(s) for multihoming purposes. This might not be a typical renumbering case because the original addresses will not be changed. However, initial numbering may be considered as a special renumbering event. The enterprise network removes uplink(s) or old prefixes.
o エンタープライズネットワークは、マルチホーミングの目的で新しいアップリンクを追加します。元のアドレスは変更されないため、これは典型的な番号変更のケースではない可能性があります。ただし、最初の番号付けは、特別な再番号付けイベントと見なされる場合があります。企業ネットワークは、アップリンクまたは古いプレフィックスを削除します。
o As companies split, merge, grow, relocate, or reorganize, the enterprise network architectures might need to be rebuilt. This will trigger partial or total internal renumbering.
o 企業が分割、統合、成長、再配置、または再編成するにつれて、エンタープライズネットワークアーキテクチャの再構築が必要になる場合があります。これにより、部分的または全体的な内部番号付けがトリガーされます。
o The enterprise network might proactively adopt a new address scheme, for example, by switching to a new transition mechanism or stage of a transition plan.
o エンタープライズネットワークは、たとえば新しい移行メカニズムまたは移行計画のステージに切り替えるなどして、新しいアドレススキームを積極的に採用する場合があります。
o The enterprise network might reorganize its topology or subnets.
o エンタープライズネットワークは、トポロジまたはサブネットを再編成する場合があります。
In order to carry out renumbering in an enterprise network, systematic planning and administrative preparation are needed. Careful planning and preparation could make the renumbering process smoother.
企業ネットワークで番号の付け替えを実行するには、体系的な計画と管理の準備が必要です。慎重な計画と準備により、番号の付け直しのプロセスがスムーズになります。
This section describes current considerations and methods for enterprise renumbering, chosen among existing mechanisms. There are known gaps analyzed by [GAP-ANALYSIS] and [RFC6866]. If these gaps are filled in the future, enterprise renumbering could be processed more automatically, with fewer issues.
このセクションでは、既存のメカニズムから選択された、エンタープライズの再番号付けに関する現在の考慮事項と方法について説明します。 [GAP-ANALYSIS]と[RFC6866]によって分析された既知のギャップがあります。これらのギャップが将来埋められる場合、企業の番号の付け替えはより少ない問題でより自動的に処理される可能性があります。
This section describes the considerations or issues relevant to renumbering that a network architect should carefully plan when building or designing a new network.
このセクションでは、ネットワーク設計者が新しいネットワークを構築または設計するときに慎重に計画する必要がある再番号付けに関する考慮事項または問題について説明します。
- Prefix Delegation (PD)
- プレフィックス委任（PD）
In a large or a multisite enterprise network, the prefix should be carefully managed, particularly for renumbering events. Prefix information needs to be delegated from router to router. The DHCPv6 PD options ([RFC3633] and [RFC6603]) provide a mechanism for automated delegation of IPv6 prefixes. Normally, DHCPv6 PD options are used between the internal enterprise routers; for example, a router receives a prefix(es) from its upstream router (a border gateway or edge router, etc.) through DHCPv6 PD options and then advertises it (them) to the local hosts through Router Advertisement (RA) messages.
大規模またはマルチサイトのエンタープライズネットワークでは、特にイベントの再番号付けのために、プレフィックスを慎重に管理する必要があります。プレフィックス情報はルーター間で委任する必要があります。 DHCPv6 PDオプション（[RFC3633]および[RFC6603]）は、IPv6プレフィックスの自動委任のメカニズムを提供します。通常、DHCPv6 PDオプションは内部エンタープライズルーター間で使用されます。たとえば、ルーターはDHCPv6 PDオプションを介して上流ルーター（境界ゲートウェイやエッジルーターなど）からプレフィックスを受信し、ルーターアドバタイズ（RA）メッセージを介してローカルホストにプレフィックスをアドバタイズします。
- Usage of Fully Qualified Domain Names (FQDNs)
- 完全修飾ドメイン名（FQDN）の使用
In general, FQDNs are recommended to be used to configure network connectivity, such as tunnels, servers, etc. The capability to use FQDNs as endpoint names has been standardized in several RFCs (e.g., for IPsec [RFC5996]) although many system/network administrators do not realize that it is there and it works well as a way to avoid manual modification during renumbering.
一般に、FQDNは、トンネル、サーバーなどのネットワーク接続を構成するために使用することをお勧めします。エンドポイント名としてFQDNを使用する機能は、いくつかのRFC（たとえば、IPsec [RFC5996]）で標準化されていますが、多くのシステム/ネットワーク管理者はそこにあることを認識しておらず、番号を付け直すときに手動で変更することを回避する方法としてうまく機能します。
Note that using FQDNs would rely on DNS systems. For a link-local network that does not have a DNS system, multicast DNS [RFC6762] could be utilized. For some specific circumstances, using FQDNs might not be chosen if adding DNS service in the node/network would cause undesired complexity or issues.
FQDNの使用はDNSシステムに依存することに注意してください。 DNSシステムを持たないリンクローカルネットワークでは、マルチキャストDNS [RFC6762]を利用できます。特定の状況では、ノード/ネットワークにDNSサービスを追加すると望ましくない複雑さや問題が発生する場合、FQDNの使用が選択されない場合があります。
Service discovery protocols such as the Service Location Protocol [RFC2608], multicast DNS with Service Records (SRVs), and DNS Service Discovery [RFC6763] use names and can reduce the number of places that IP addresses need to be configured. However, it should be noted that these protocols are normally used link-local only.
サービスロケーションプロトコル[RFC2608]、サービスレコード（SRV）付きのマルチキャストDNS、およびDNSサービスディスカバリ[RFC6763]などのサービスディスカバリプロトコルは名前を使用し、IPアドレスを構成する必要がある場所の数を減らすことができます。ただし、これらのプロトコルは通常、リンクローカルでのみ使用されることに注意してください。
Network designers generally have little control over the design of application software. However, it is important to avoid any software that has a built-in dependency on IP addresses instead of FQDNs [RFC6866].
ネットワーク設計者は、通常、アプリケーションソフトウェアの設計をほとんど制御できません。ただし、FQDNではなくIPアドレスに組み込みの依存関係があるソフトウェアを回避することが重要です[RFC6866]。
- Usage of Parameterized Address Configuration
- パラメータ化されたアドレス構成の使用
Besides DNS records, IP addresses might also be configured in many other places such as ACLs, various IP filters, various kinds of text-based configuration files, etc.
DNSレコードに加えて、IPアドレスは、ACL、さまざまなIPフィルター、さまざまな種類のテキストベースの設定ファイルなど、他の多くの場所でも設定できます。
In some cases, one IP address 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 CLI (command line interface) or other local configuration. Among the real 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.
場合によっては、1つのIPアドレスを1つの値として一度定義すると、管理者はキーワードまたは変数を使用して、一種の内部継承CLI（コマンドラインインターフェイス）や他のローカル構成などの他の場所で値を呼び出すことができます。実際の現在のデバイスのうち、一部のルーターは、他の構成で呼び出すことができる複数のループバックインターフェイスの定義をサポートしています。たとえば、トンネルを定義するときに、定義されたループバックインターフェイスを呼び出して、そのアドレスをトンネルのローカルアドレスとして使用できます。
This kind of parameterized address configuration is recommended, since it makes managing a renumbering event easier by reducing the number of places where a device's configuration must be updated.
この種のパラメーター化されたアドレス構成は、デバイスの構成を更新する必要のある場所の数を減らすことにより、再番号付けイベントの管理を容易にするため、推奨されます。
- Usage of Unique Local Addresses (ULAs)
- 一意のローカルアドレス（ULA）の使用
ULAs are defined in [RFC4193] as PI prefixes. Since there is a 40-bit pseudorandom field in the ULA prefix, there is no practical risk of collision (please refer to Section 3.2.3 in [RFC4193] for more detail). For enterprise networks, using ULA simultaneously with PA addresses can provide a local routing plane logically separated from the global routing plane. The benefit is to ensure stable and specific local communication regardless of any ISP uplink failure. This benefit is especially meaningful for renumbering. It mainly includes three use cases described below.
ULAは[RFC4193]でPIプレフィックスとして定義されています。 ULAプレフィックスには40ビットの疑似ランダムフィールドがあるため、衝突の実際的なリスクはありません（詳細については、[RFC4193]のセクション3.2.3を参照してください）。エンタープライズネットワークの場合、PAアドレスと同時にULAを使用すると、グローバルルーティングプレーンから論理的に分離されたローカルルーティングプレーンを提供できます。利点は、ISPアップリンクの障害に関係なく、安定した特定のローカル通信を保証することです。この利点は、番号を付け直すときに特に意味があります。主に以下の3つのユースケースが含まれます。
o During the transition period, it is desirable to isolate local communication changes in the global routing plane. If we use ULA for the local communication, this isolation is achieved.
o 移行期間中は、グローバルルーティングプレーンでローカル通信の変更を分離することが望ましいです。ローカル通信にULAを使用すると、この分離が実現します。
o Enterprise administrators might want to avoid the need to renumber their internal-only, private nodes when they have to renumber the PA addresses of the whole network because of changing ISPs, ISPs restructuring their address allocation, or any other reasons. In these situations, a ULA is an effective tool for the internal-only nodes.
o エンタープライズ管理者は、ISPの変更、ISPによるアドレス割り当ての再構築、またはその他の理由により、ネットワーク全体のPAアドレスを再番号付けする必要がある場合に、内部専用のプライベートノードの番号を付け直す必要性を回避したい場合があります。このような状況では、ULAは内部のみのノードに効果的なツールです。
o ULAs can be a way of avoiding renumbering from having an impact on multicast. In most deployments, multicast is only used internally (intra-domain), and the addresses used for multicast sources and Rendezvous Points need not be reachable nor routable externally. Hence, one may, at least internally, make use of ULAs for multicast-specific infrastructure.
o ULAは、再番号付けによるマルチキャストへの影響を回避する方法の1つです。ほとんどの展開では、マルチキャストは内部（ドメイン内）でのみ使用され、マルチキャストソースおよびランデブーポイントに使用されるアドレスは、外部から到達可能でもルーティング可能である必要もありません。したがって、少なくとも内部的には、マルチキャスト固有のインフラストラクチャにULAを利用できます。
- Address Types
- アドレスの種類
This document focuses on the dynamically configured global unicast addresses in enterprise networks. They are the targets of renumbering events.
このドキュメントでは、エンタープライズネットワークで動的に構成されたグローバルユニキャストアドレスに焦点を当てています。それらは、イベントの番号を付け直す対象です。
Manually configured addresses are not scalable in medium to large sites; hence, they should be avoided for both network elements and application servers [RFC6866].
手動で構成されたアドレスは、中規模から大規模のサイトでは拡張できません。したがって、ネットワーク要素とアプリケーションサーバーの両方でこれらを回避する必要があります[RFC6866]。
- Address configuration models
- アドレス構成モデル
In IPv6 networks, there are two autoconfiguration models for address assignment after each host obtains a link-local address: Stateless Address Autoconfiguration (SLAAC) [RFC4862] by ND [RFC4861] and stateful address configuration by DHCPv6 [RFC3315]. In the latest work, DHCPv6 may also support the host-generated address model by assigning a prefix through DHCPv6 messages [PREFIX-DHCPV6].
IPv6ネットワークでは、各ホストがリンクローカルアドレスを取得した後のアドレス割り当てに2つの自動構成モデルがあります。NDによるステートレスアドレス自動構成（SLAAC）[RFC4862]とDHCPv6によるステートフルアドレス構成[RFC3315]です。最新の作業では、DHCPv6は、DHCPv6メッセージ[PREFIX-DHCPV6]を介してプレフィックスを割り当てることにより、ホスト生成のアドレスモデルをサポートする場合もあります。
SLAAC is considered to support easy renumbering by broadcasting an RA message with a new prefix. DHCPv6 can also trigger the renumbering process by sending unicast RECONFIGURE messages, though it might cause a large number of interactions between hosts and the DHCPv6 server.
SLAACは、RAメッセージに新しいプレフィックスを付けてブロードキャストすることにより、簡単な再番号付けをサポートすると考えられています。 DHCPv6は、ユニキャストRECONFIGUREメッセージを送信することにより、再番号付けプロセスをトリガーすることもできますが、ホストとDHCPv6サーバーの間で多数の相互作用が発生する可能性があります。
This document has no preference between the SLAAC and DHCPv6 address configuration models. It is the network architect's job to decide which configuration model is employed. However, it should be noticed that using DHCPv6 and SLAAC together within one network, especially in one subnet, might cause operational issues. For example, some hosts use DHCPv6 as the default configuration model while some use ND. Then, the host's address configuration model depends on the policies of operating systems and cannot be controlled by the network. Section 5.1 of [GAP-ANALYSIS] discusses more details on this topic. So, in general, this document recommends using DHCPv6 or SLAAC independently in different subnets.
このドキュメントでは、SLAACとDHCPv6のアドレス構成モデルを優先していません。どの構成モデルを採用するかを決定するのは、ネットワーク設計者の仕事です。ただし、1つのネットワーク内、特に1つのサブネット内でDHCPv6とSLAACを一緒に使用すると、操作上の問題が発生する可能性があることに注意してください。たとえば、一部のホストはデフォルト構成モデルとしてDHCPv6を使用し、一部のホストはNDを使用します。次に、ホストのアドレス構成モデルはオペレーティングシステムのポリシーに依存し、ネットワークによって制御できません。 [GAP-ANALYSIS]のセクション5.1では、このトピックの詳細について説明しています。したがって、一般に、このドキュメントでは、異なるサブネットで独立してDHCPv6またはSLAACを使用することを推奨しています。
However, since DHCPv6 is also used to configure many other network parameters, there are ND and DHCPv6 coexistence scenarios. Combinations of address configuration models might coexist within a single enterprise network. [SAVI] provides recommendations to avoid collisions and to review collision handling in such scenarios.
ただし、DHCPv6は他の多くのネットワークパラメーターの構成にも使用されるため、NDとDHCPv6の共存シナリオがあります。アドレス構成モデルの組み合わせは、単一のエンタープライズネットワーク内で共存できます。 [SAVI]は、衝突を回避し、そのようなシナリオでの衝突処理を確認するための推奨事項を提供します。
- DNS
- DNS
Although the A6 DNS record model [RFC2874] was designed for easier renumbering, it left many unsolved technical issues [RFC3364]. Therefore, it has been moved to Historic status [RFC6563] and should not be used.
A6 DNSレコードモデル[RFC2874]は番号の付け直しを容易にするために設計されましたが、多くの未解決の技術的問題[RFC3364]が残りました。そのため、履歴ステータス[RFC6563]に移行しました。使用しないでください。
Often, a small site depends on its ISP's DNS system rather than maintaining its own. When renumbering, this requires administrative coordination between the site and its ISP.
多くの場合、小さなサイトはサイトを維持するのではなく、ISPのDNSシステムに依存しています。番号を付け直すときは、サイトとそのISPの間の管理上の調整が必要です。
It is recommended that the site have an automatic and systematic procedure for updating/synchronizing its DNS records, including both forward and reverse mapping. In order to simplify the operational procedure, the network architect should combine the forward and reverse DNS updates in a single procedure. A manual on-demand updating model does not scale and increases the chance of errors. Either a database-driven mechanism, a secure dynamic DNS update [RFC3007], or both could be used.
サイトには、順方向マッピングと逆方向マッピングの両方を含む、DNSレコードを更新/同期するための自動化された体系的な手順を用意することをお勧めします。運用手順を簡略化するために、ネットワークアーキテクトは、フォワードDNSリバースとリバースDNSアップデートを1つの手順で組み合わせる必要があります。手動のオンデマンド更新モデルは拡張されず、エラーの可能性が高くなります。データベース駆動のメカニズム、安全な動的DNS更新[RFC3007]、またはその両方を使用できます。
A dynamic DNS update can be provided by the DHCPv6 client or by the server on behalf of individual hosts. [RFC4704] defines a DHCPv6 option to be used by DHCPv6 clients and servers to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated AAAA and PTR (Pointer Record) RRs (Resource Records). For example, if a client wants the server to update the FQDN-address mapping in the DNS server, it can include the Client FQDN option with proper settings in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. When the DHCPv6 server gets this option, it can use a secure dynamic DNS update on behalf of the client. This document suggests use of this FQDN option. However, since it is a DHCPv6 option, only the DHCP-managed hosts can make use of it. In SLAAC mode, hosts need either to use a secure dynamic DNS update directly, or to register addresses on a registration server. This could in fact be a DHCPv6 server (as described in [ADDR-REG]); then the server would update corresponding DNS records.
動的DNS更新は、DHCPv6クライアントまたは個々のホストに代わってサーバーによって提供できます。 [RFC4704]は、DHCPv6クライアントとサーバーがクライアントのFQDNと、関連付けられたAAAAおよびPTR（ポインタレコード）RR（リソースレコード）でDNSを更新する責任を持つ情報を交換するために使用するDHCPv6オプションを定義します。たとえば、クライアントがサーバーにDNSサーバーのFQDNアドレスマッピングを更新することを望む場合、クライアントが発信したRapid Commit、REQUEST、RENEW、およびREBINDメッセージを使用して、適切な設定のClient FQDNオプションをSOLICITに含めることができます。 DHCPv6サーバーがこのオプションを取得すると、クライアントに代わって安全な動的DNS更新を使用できます。このドキュメントでは、このFQDNオプションの使用を提案しています。ただし、これはDHCPv6オプションであるため、DHCPで管理されたホストのみが使用できます。 SLAACモードでは、ホストは安全な動的DNS更新を直接使用するか、登録サーバーにアドレスを登録する必要があります。これは、実際にはDHCPv6サーバーである可能性があります（[ADDR-REG]で説明されています）。その後、サーバーは対応するDNSレコードを更新します。
- Security
- 安全保障
Any automatic renumbering scheme has a potential exposure to hijacking. A malicious entity in the network could forge prefixes to renumber the hosts, so proper network security mechanisms are needed. Further details are in the Security Considerations section below.
自動再番号付けスキームは、ハイジャックされる可能性があります。ネットワーク内の悪意のあるエンティティがプレフィックスを偽造してホストの番号を付け直す可能性があるため、適切なネットワークセキュリティメカニズムが必要です。詳細については、以下の「セキュリティに関する考慮事項」セクションをご覧ください。
- Miscellaneous
- 雑多
A site or network should also avoid embedding addresses from other sites or networks in its own configuration data. Instead, the FQDNs should be used. Thus, connections can be restored after renumbering events at other sites. This also applies to host-based connectivity.
サイトまたはネットワークでは、他のサイトまたはネットワークからのアドレスを独自の構成データに埋め込むことも避けてください。代わりに、FQDNを使用する必要があります。したがって、他のサイトでイベントの番号を付け直した後で接続を復元できます。これは、ホストベースの接続にも当てはまります。
4.2. Considerations and Current Methods for the Preparation of Renumbering
4.2. 再番号付けの準備に関する考慮事項と現在の方法
In ND, it is not possible to reduce a prefix's lifetime to below two hours. So, renumbering should not be an unplanned sudden event. This issue could only be avoided by early planning and preparation.
NDでは、プレフィックスのライフタイムを2時間未満に短縮することはできません。したがって、再番号付けは、計画外の突然のイベントであってはなりません。この問題は、初期の計画と準備によってのみ回避できます。
This section describes several recommendations for the preparation of an enterprise renumbering event. By adopting these recommendations, a site could be renumbered more easily. However, these recommendations might increase the daily traffic, server load, or burden of network operation. Therefore, only those networks that are expected to be renumbered soon, or very frequently, should adopt these recommendations, with balanced consideration between daily cost and renumbering cost.
このセクションでは、エンタープライズ番号変更イベントの準備に関するいくつかの推奨事項について説明します。これらの推奨事項を採用することで、サイトの番号を簡単に変更できます。ただし、これらの推奨事項により、毎日のトラフィック、サーバーの負荷、またはネットワーク操作の負担が増える可能性があります。したがって、すぐに、または非常に頻繁に番号が付け替えられると予想されるネットワークのみが、1日のコストと番号付けのコストをバランスよく考慮して、これらの推奨事項を採用する必要があります。
- Reduce the address preferred time or valid time or both
- アドレス優先時間または有効時間、あるいはその両方を減らします
Long-lifetime addresses might cause issues for renumbering events. Particularly, some offline hosts might reconnect using these addresses after renumbering events. Shorter, preferred lifetimes with relatively long valid lifetimes may allow short transition periods for renumbering events and avoid frequent address renewals.
存続期間の長いアドレスは、イベントの番号を付け直す際に問題を引き起こす可能性があります。特に、一部のオフラインホストは、イベントの番号を付け直した後、これらのアドレスを使用して再接続する場合があります。有効期間が比較的長い推奨期間を短くすると、イベントの番号を付け直すための移行期間が短くなり、頻繁なアドレスの更新が回避されます。
- Reduce the DNS record Time to Live (TTL) on the local DNS server
- ローカルDNSサーバーでDNSレコードのTime to Live（TTL）を削減する
The DNS AAAA RR TTL on the local DNS server should be manipulated to ensure that stale addresses are not cached.
ローカルDNSサーバーのDNS AAAA RR TTLを操作して、古いアドレスがキャッシュされないようにする必要があります。
Recent research [BA2011] [JSBM2002] indicates that it is both practical and reasonable for A, AAAA, and PTRs that belong to leaf nodes of the DNS (i.e., not including the DNS root or DNS top-level domains) to be configured with very short DNS TTL values, not only during renumbering events but also for longer-term operation.
最近の調査[BA2011] [JSBM2002]は、DNSのリーフノードに属するA、AAAA、およびPTR（つまり、DNSルートまたはDNSトップレベルドメインを含まない）を構成することは実用的かつ合理的であることを示していますリナンバリングイベント中だけでなく、長期間の運用のための非常に短いDNS TTL値。
- Reduce the DNS configuration lifetime on the hosts
- ホストのDNS構成の有効期間を短縮する
Since the DNS server could be renumbered as well, the DNS configuration lifetime of the hosts should also be reduced if renumbering events are expected. In ND, the DNS configuration can be done through reducing the lifetime value in the Recursive DNS Server (RDNSS) option [RFC6106]. In DHCPv6, the DNS configuration option specified in [RFC3646] doesn't provide a lifetime attribute, but we can reduce the DHCPv6 client lease time to achieve a similar effect.
DNSサーバーも再番号付けされる可能性があるため、再番号付けイベントが予想される場合は、ホストのDNS構成ライフタイムも短縮する必要があります。 NDでは、再帰DNSサーバー（RDNSS）オプション[RFC6106]のライフタイム値を減らすことでDNS構成を行うことができます。 DHCPv6では、[RFC3646]で指定されているDNS構成オプションはライフタイム属性を提供しませんが、DHCPv6クライアントのリース時間を短縮して同様の効果を達成できます。
- Identify long-living sessions
- 長く続くセッションを特定する
Any applications that maintain very long transport connections (hours or days) should be identified in advance, if possible. Such applications will need special handling during renumbering, so it is important to know that they exist.
非常に長いトランスポート接続（数時間または数日）を維持するアプリケーションは、可能であれば事前に特定する必要があります。このようなアプリケーションは、番号を付け直すときに特別な処理が必要になるため、それらが存在することを知ることが重要です。
Renumbering events are not instantaneous events. Normally, there is transition period in which both the old prefix and the new prefix are used in the site. Better network design and management, better preparation, and a longer transition period are helpful to reduce the issues during a renumbering operation.
番号の付け直しイベントは瞬間的なイベントではありません。通常、サイトで古いプレフィックスと新しいプレフィックスの両方が使用される移行期間があります。ネットワークの設計と管理の改善、準備の改善、移行期間の延長は、番号の付け直し操作中の問題を減らすのに役立ちます。
- Within/Without a flag day
- 旗日内/なし
As is described in [RFC4192] "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".
[RFC4192]で説明されているように、「「旗日」とは、計画停止中にネットワークまたはその一部が変更される手順、または突然、ネットワークの回復中に停止を引き起こす手順です。」
If a renumbering event is processed within a flag day, the network service/connectivity will be unavailable for a period until the renumbering event is completed. It is efficient and provides convenience for network operation and management. However, a network outage is usually unacceptable for end users and enterprises. A renumbering procedure without a flag day provides smooth address switching, but much more operational complexity and difficulty is introduced.
再番号付けイベントがフラグ日以内に処理される場合、ネットワークサービス/接続性は、再番号付けイベントが完了するまでの期間使用できません。効率的で、ネットワークの運用と管理に便利です。ただし、ネットワークの停止は通常、エンドユーザーと企業にとって許容できません。フラグデイのない再番号付け手順では、スムーズなアドレススイッチングが提供されますが、操作がさらに複雑になり、困難が生じます。
- Transition period
- 移行期間
If a renumbering transition period is longer than all address lifetimes, after which the address leases expire, each host will automatically pick up its new IP address. In this case, it would be the DHCPv6 server or RA itself that automatically accomplishes client renumbering.
番号変更の移行期間がすべてのアドレスの有効期間よりも長く、その後アドレスのリースが期限切れになると、各ホストは自動的に新しいIPアドレスを取得します。この場合、DHCPv6サーバーまたはRA自体がクライアントの再番号付けを自動的に実行します。
Address deprecation should be associated with the deprecation of associated DNS records. The DNS records should be deprecated as early as possible, before the addresses themselves.
アドレスの廃止は、関連するDNSレコードの廃止と関連付ける必要があります。 DNSレコードは、アドレス自体の前に、できるだけ早く非推奨にする必要があります。
- Network initiative enforced renumbering
- ネットワークイニシアチブによる番号変更の強制
If the network has to enforce renumbering before address leases expire, the network should initiate DHCPv6 RECONFIGURE messages. For some operating systems such as Windows 7, if the hosts receive RA messages with ManagedFlag=0, they will release the DHCPv6 addresses and utilize SLAAC according to the prefix information in the RA messages, so this could be another enforcement method for some specific scenarios.
アドレスリースの期限が切れる前にネットワークが再番号付けを強制する必要がある場合、ネットワークはDHCPv6 RECONFIGUREメッセージを開始する必要があります。 Windows 7などの一部のオペレーティングシステムでは、ホストがManagedFlag = 0のRAメッセージを受信した場合、ホストはDHCPv6アドレスを解放し、RAメッセージのプレフィックス情報に従ってSLAACを利用するため、これは特定のシナリオの別の実施方法になる可能性があります。
- Impact on main and branch sites
- メインおよびブランチサイトへの影響
Renumbering in the main site might cause impact on branch site communications, and vice versa. The routes, ingress filtering of the site's gateways, and DNS might need to be updated. This needs careful planning and organizing.
メインサイトで番号を付け直すと、ブランチサイトの通信に影響が生じる可能性があり、その逆の場合もあります。ルート、サイトのゲートウェイの入力フィルタリング、およびDNSを更新する必要がある場合があります。これには注意深い計画と整理が必要です。
- DNS record update and DNS configuration on hosts
- ホストでのDNSレコードの更新とDNS構成
DNS records on the local DNS server should be updated if hosts are renumbered. If the site depends on an ISP's DNS system, it should report the new hosts' DNS records to its ISP. During the transition period, both old and new DNS records are valid. If the TTLs of DNS records are shorter than the transition period, an administrative operation might not be necessary.
ホストの番号が変更された場合、ローカルDNSサーバーのDNSレコードを更新する必要があります。サイトがISPのDNSシステムに依存している場合、新しいホストのDNSレコードをISPに報告する必要があります。移行期間中は、古いDNSレコードと新しいDNSレコードの両方が有効です。 DNSレコードのTTLが移行期間よりも短い場合は、管理操作が不要な場合があります。
DNS configuration on hosts should be updated if local recursive DNS servers are renumbered. During the transition period, both old and new DNS server addresses might coexist on the hosts. If the lifetime of DNS configuration is shorter than the transition period, name resolving failure may be reduced to a minimum.
ローカルの再帰DNSサーバーの番号が変更された場合は、ホストのDNS構成を更新する必要があります。移行期間中、新旧両方のDNSサーバーアドレスがホスト上に共存する可能性があります。 DNS構成の有効期間が移行期間よりも短い場合、名前解決の失敗は最小限に抑えられます。
- Tunnel concentrator renumbering
- トンネルコンセントレータの再番号付け
A tunnel concentrator itself might be renumbered. This change should be reconfigured in relevant hosts or routers, unless the configuration of the tunnel concentrator was based on FQDN.
トンネルコンセントレータ自体の番号が変更される場合があります。この変更は、トンネルコンセントレータの構成がFQDNに基づいていなかった場合を除き、関連するホストまたはルーターで再構成する必要があります。
For IPsec, Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] defines the ID_FQDN Identification type, which could be used to identify an IPsec VPN concentrator associated with a site's domain name. For current practice, the community needs to change its bad habit of using IPsec in an address-oriented way, and renumbering is one of the main reasons for that.
IPsecの場合、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC5996]はID_FQDN識別タイプを定義します。これは、サイトのドメイン名に関連付けられたIPsec VPNコンセントレーターを識別するために使用できます。現在の慣行では、コミュニティはIPsecをアドレス指向の方法で使用するという悪い癖を変える必要があり、そのため、番号の付け直しがその主な理由の1つです。
- Connectivity session survivability
- 接続セッションの存続可能性
During the renumbering operations, connectivity sessions in the IP layer would break if the old address is deprecated before the session ends. However, the upper-layer sessions can survive by using session survivability technologies, such as Stanza Headers and Internet Metadata 6 (SHIM6) [RFC5533]. As mentioned above, some long-living applications may need to be handled specially.
再番号付け操作中に、セッションが終了する前に古いアドレスが廃止された場合、IPレイヤーの接続セッションが切断されます。ただし、上位層セッションは、スタンザヘッダーやインターネットメタデータ6（SHIM6）[RFC5533]などのセッションサバイバビリティテクノロジーを使用することで存続できます。上述のように、一部の長期間有効なアプリケーションは特別に処理する必要がある場合があります。
- Verification of success
- 成功の検証
The renumbering operation should end with a thorough check that all network elements and hosts are using only the new prefixes and that network management and monitoring systems themselves are still operating correctly. A database clean up may also be needed.
番号の付け直し操作は、すべてのネットワーク要素とホストが新しいプレフィックスのみを使用しており、ネットワーク管理システムと監視システム自体がまだ正しく動作していることを徹底的にチェックして終了する必要があります。データベースのクリーンアップも必要になる場合があります。
Any automatic renumbering scheme has a potential exposure to hijacking by an insider attack. For attacks on ND, SEcure Neighbor Discovery (SEND) [RFC3971] is a possible solution, but it is complex and there is almost no real deployment at the time of writing. Compared to the nontrivial deployment of SEND, RA-Guard [RFC6105] is a lightweight alternative that focuses on preventing rogue router advertisements in a network. However, it is also not widely deployed at the time when this memo was published.
自動再番号付けスキームは、インサイダー攻撃によるハイジャックの可能性があります。 NDへの攻撃の場合、SEcure Neighbor Discovery（SEND）[RFC3971]が可能な解決策ですが、それは複雑であり、執筆時点では実際の配備はほとんどありません。 SENDの重要な展開と比較すると、RA-Guard [RFC6105]は、ネットワークでの不正なルーターアドバタイズメントの防止に重点を置いた軽量の代替手段です。ただし、このメモが公開された時点では、あまり普及していません。
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 [SECURE-DHCPV6]), and authentication of DHCPv6 messages [RFC3315] could be utilized. However, these security mechanisms also have not been verified by widespread deployment at the time of writing.
DHCPv6の場合、組み込みの安全なメカニズム（Secure DHCPv6 [SECURE-DHCPV6]など）があり、DHCPv6メッセージの認証[RFC3315]を利用できます。ただし、これらのセキュリティメカニズムは、執筆時点での広範な展開によっても検証されていません。
A site that is listed by IP address in a blacklist can escape that list by renumbering itself. However, the new prefix might be back on a blacklist rather soon if the root cause for being added to such a list is not corrected. In practice, the cost of renumbering will typically be much larger than the cost of getting off the blacklist.
ブラックリストにIPアドレスでリストされているサイトは、自身の番号を付け直すことでそのリストをエスケープできます。ただし、リストに追加される根本的な原因が修正されない場合、新しいプレフィックスがブラックリストにすぐに戻る可能性があります。実際には、再番号付けのコストは、通常、ブラックリストから降りるコストよりもはるかに大きくなります。
A Dynamic DNS update might bring risk of a Denial-of-Service (DoS) attack to the DNS server. So, along with the update authentication, session filtering/limitation might also be needed.
動的DNS更新は、DNSサーバーにサービス拒否（DoS）攻撃のリスクをもたらす可能性があります。そのため、更新認証とともに、セッションのフィルタリング/制限も必要になる場合があります。
The "make-before-break" approach of [RFC4192] requires the routers to keep advertising the old prefixes for some time. However, if the ISP changes the prefixes very frequently, the coexistence of old and new prefixes might cause potential risk to the enterprise routing system, since the old address relevant route path might already be invalid and the routing system just doesn't know it. However, normally, enterprise scenarios don't involve this extreme situation.
[RFC4192]の「make-before-break」アプローチでは、ルーターが古いプレフィックスをしばらくアドバタイズし続ける必要があります。ただし、ISPがプレフィックスを非常に頻繁に変更する場合は、古いプレフィックスと新しいプレフィックスの共存により、エンタープライズルーティングシステムにリスクが生じる可能性があります。これは、古いアドレス関連のルートパスがすでに無効であり、ルーティングシステムがそれを知らないためです。ただし、通常、エンタープライズシナリオにはこの極端な状況は含まれません。
This work is inspired by RFC 5887; thank you to the authors (Randall Atkinson and Hannu Flinck). Useful ideas were also presented in documents by Tim Chown and Fred Baker. The authors also want to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald Bonica, other 6renum members, and several reviewers for their valuable comments.
この作品はRFC 5887に触発されています。著者（Randall AtkinsonおよびHannu Flinck）に感謝します。 Tim ChownとFred Bakerによる有用なアイデアも文書で提示されました。著者はまた、ウェスリー・ジョージ、オリビエ・ボナベンチャー、リー・ハワード、ロナルド・ボニカ、他の6renumメンバー、および数人のレビューアに貴重なコメントをしてくれたことに感謝したいと思います。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「Service Location Protocol、バージョン2」、RFC 2608、1999年6月。
[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月。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、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。
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057] Bound、J.、Ed。、「IPv6 Enterprise Network Scenarios」、RFC 4057、2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[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月。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。
[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月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364] Austein、R。、「インターネットプロトコルバージョン6（IPv6）のドメインネームシステム（DNS）サポートにおけるトレードオフ」、RFC 3364、2002年8月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116] Abley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4マルチホーミングの実践と制限」、RFC 4116、2005年7月。
[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月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E.およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、2009年6月。
[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月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月。
[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月。
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603] Korhonen、J.、Ed。、Savolainen、T.、Krishnan、S。、およびO. Troan、「DHCPv6ベースのプレフィックス委任のプレフィックス除外オプション」、RFC 6603、2012年5月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、2013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[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月。
[ADDR-REG] Jiang, S., Chen, G., and S. Krishnan "A Generic IPv6 Addresses Registration Solution Using DHCPv6", Work in Progress, February 2013.
[ADDR-REG] Jiang、S.、Chen、G。、およびS. Krishnan「DHCPv6を使用した一般的なIPv6アドレス登録ソリューション」、作業中、2013年2月。
[BA2011] S. Bhatti, and R. Atkinson, "Reducing DNS Caching", Proc. 14th IEEE Global Internet Symposium (GI2011), Shanghai, China, April 15 2011.
[BA2011] S. Bhatti、およびR. Atkinson、「Reducing DNS Caching」、Proc。第14回IEEEグローバルインターネットシンポジウム（GI2011）、中国、上海、2011年4月15日。
[GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B. Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012.
[ギャップ分析] Liu、B.、Jiang、S.、Carpenter、B。Venaas、S。、およびW. George、「IPv6 Site Renumbering Gap Analysis」、Work in Progress、2012年12月。
[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, "DNS Performance and the Effectiveness of Caching", IEEE/ACM Transactions on Networking, 10(5):589-603, 2002.
[JSBM2002] J. Jung、E。Sit、H。Balakrishnan、およびR. Morris、「DNS Performance and the Effectiveness of Caching」、IEEE / ACM Transactions on Networking、10（5）：589-603、2002。
[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月。
[SAVI] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI for Mixed Address Assignment Methods Scenario", Work in Progress, November 2012.
[SAVI] Bi、J.、Yao、G.、Halpern、J。、およびE. Levy-Abegnoli、「SAVI for Mixed Address Assignment Methods Scenario」、Work in Progress、2012年11月。
[SECURE-DHCPV6] Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", Work in Progress, March 2012.
[SECURE-DHCPV6] Jiang、S.、S。Shen、「Secure DHCPv6 Using CGAs」、Work in Progress、2012年3月。
Authors' Addresses
著者のアドレス
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China
S H Jiang hu Aはテクノロジー株式会社です。Q14、hu Aはキャンパス番号156であり、i青RDです。h爱-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com
Bing Liu Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China
Bing l IU hu Aはテクノロジー株式会社です。Q14、hu Aはキャンパス番号156です。i青RD。h爱-Dイアン地区、北京100095 P.R.中国
EMail: leo.liubing@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド、1142ニュージーランド
EMail: brian.e.carpenter@gmail.com