[要約] RFC 7934は、ホストアドレスの利用可能性に関する推奨事項を提供する。その目的は、IPv4アドレスの枯渇に対処し、アドレスの効果的な使用を促進することである。
Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 7934 V. Cerf
BCP: 204 Google
Category: Best Current Practice S. Cheshire
ISSN: 2070-1721 D. Schinazi
Apple Inc.
July 2016
Host Address Availability Recommendations
ホストアドレスの可用性に関する推奨事項
Abstract
概要
This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.
このドキュメントでは、ネットワークが汎用エンドホストに接続するときに複数のグローバルIPv6アドレスを提供することを推奨し、その利点とオプションを説明します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション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/rfc7934.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7934で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Common IPv6 Deployment Model . . . . . . . . . . . . . . . . 3
3. Benefits of Providing Multiple Addresses . . . . . . . . . . 3
4. Problems with Restricting the Number of Addresses per Host . 4
5. Overcoming Limits Using Network Address Translation . . . . . 5
6. Options for Providing More Than One Address . . . . . . . . . 6
7. Number of Addresses Required . . . . . . . . . . . . . . . . 8
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
9. Operational Considerations . . . . . . . . . . . . . . . . . 9
9.1. Host Tracking . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Address Space Management . . . . . . . . . . . . . . . . 10
9.3. Addressing Link-Layer Scalability Issues via IP Routing . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
In most aspects, the IPv6 protocol is very similar to IPv4. This similarity can create a tendency to think of IPv6 as 128-bit IPv4, and thus lead network designers and operators to apply identical configurations and operational practices to both. This is generally a good thing because it eases the transition to IPv6 and the operation of dual-stack networks. However, in some design and operational areas, it can lead to carrying over IPv4 practices that are limiting or not appropriate in IPv6 due to differences between the protocols.
ほとんどの点で、IPv6プロトコルはIPv4によく似ています。この類似性により、IPv6を128ビットのIPv4と考える傾向が生まれ、ネットワーク設計者とオペレーターが同じ構成と運用方法を両方に適用できるようになります。これは、IPv6への移行とデュアルスタックネットワークの運用を容易にするため、一般的には良いことです。ただし、一部の設計および運用領域では、プロトコル間の違いにより、IPv6では制限されている、または適切でないIPv4プラクティスが引き継がれる可能性があります。
One such area is IP addressing, particularly IP addressing of hosts. This is substantially different because unlike IPv4 addresses, IPv6 addresses are not a scarce resource. In IPv6, a single link provides over four billion times more address space than the whole IPv4 Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced by address scarcity concerns to provide only one address per host. Furthermore, providing multiple addresses has many benefits, including application functionality and simplicity, privacy, and flexibility to accommodate future applications. Another significant benefit is the ability to provide Internet access without the use of Network Address Translation (NAT). Providing only one IPv6 address per host negates these benefits.
そのような領域の1つは、IPアドレッシング、特にホストのIPアドレッシングです。 IPv4アドレスとは異なり、IPv6アドレスは希少なリソースではないため、これは大幅に異なります。 IPv6では、単一のリンクがIPv4インターネット全体[RFC7421]の40億倍以上のアドレス空間を提供します。したがって、IPv4とは異なり、IPv6ネットワークはアドレス不足の問題によってホストごとに1つのアドレスのみを提供することを強制されません。さらに、複数のアドレスを提供することには、アプリケーションの機能性とシンプルさ、プライバシー、将来のアプリケーションに対応する柔軟性など、多くの利点があります。もう1つの重要な利点は、ネットワークアドレス変換（NAT）を使用せずにインターネットアクセスを提供できることです。ホストごとに1つのIPv6アドレスのみを指定すると、これらの利点がなくなります。
This document details the benefits of providing multiple addresses per host, and the problems with not doing so. It recommends that networks provide general-purpose end hosts with multiple global addresses when they attach and lists current options for doing so. It does not specify any changes to protocols or host behavior.
このドキュメントでは、ホストごとに複数のアドレスを提供することの利点と、そうしないことの問題について詳しく説明します。アタッチするときに、ネットワークが汎用エンドホストに複数のグローバルアドレスを提供し、そのための現在のオプションを一覧表示することをお勧めします。プロトコルやホストの動作に対する変更は指定していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「は、「RFCで使用して要件レベルを示すためのキーワード」[RFC2119]で説明されているように解釈されます。
IPv6 is designed to support multiple addresses, including multiple global addresses, per interface (see Section 2.1 of [RFC4291] and Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts are configured with three or more addresses per interface: a link-local address, a stable address (e.g., using 64-bit Extended Unique Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and possibly one or more temporary or non-temporary addresses obtained using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
IPv6は、インターフェースごとに複数のグローバルアドレスを含む複数のアドレスをサポートするように設計されています（[RFC4291]のセクション2.1および[RFC6434]のセクション5.9.4を参照）。今日、多くの汎用IPv6ホストは、インターフェイスごとに3つ以上のアドレスで構成されています：リンクローカルアドレス、安定したアドレス（たとえば、64ビット拡張一意識別子（EUI-64）または不透明インターフェイス識別子[RFC7217]を使用） 、1つ以上のプライバシーアドレス[RFC4941]、およびIPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]を使用して取得された1つ以上の一時的または非一時的アドレス。
In most general-purpose IPv6 networks, hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. Such networks include all 3GPP networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862].
ほとんどの汎用IPv6ネットワークでは、ホストはネットワークへの明示的な要求なしに、リンクプレフィックスから追加のIPv6アドレスを構成できます。このようなネットワークには、ステートレスアドレス自動構成（SLAAC）[RFC4862]を使用するイーサネットおよびWi-Fiネットワークに加えて、すべての3GPPネットワーク（[RFC6459]、セクション5.2）が含まれます。
Today, there are many host functions that require more than one IP address to be available to the host, including:
今日、ホストが利用できるようにするために複数のIPアドレスを必要とする多くのホスト機能があります。
o Privacy addressing to prevent tracking by off-network hosts [RFC4941].
o ネットワーク外のホストによる追跡を防ぐプライバシーアドレッシング[RFC4941]。
o Multiple processors inside the same device. For example, in many mobile devices, both the application processor and the baseband processor need to communicate with the network, particularly for technologies like I-WLAN [TS.24327] where the two processors share the Wi-Fi network connection.
o 同じデバイス内の複数のプロセッサ。たとえば、多くのモバイルデバイスでは、特に2つのプロセッサがWi-Fiネットワーク接続を共有するI-WLAN [TS.24327]などのテクノロジでは、アプリケーションプロセッサとベースバンドプロセッサの両方がネットワークと通信する必要があります。
o Extending the network (e.g., "tethering").
o ネットワークの拡張（「テザリング」など）。
o Running virtual machines on hosts.
o ホストで仮想マシンを実行する。
o Translation-based transition technologies such as 464XLAT (a combination of stateful and stateless translation) [RFC6877] that translate between IPv4 and IPv6. Some of these technologies require the availability of a dedicated IPv6 address in order to determine whether inbound packets are translated or native ([RFC6877], Section 6.3).
o IPv4とIPv6の間で変換する464XLAT（ステートフル変換とステートレス変換の組み合わせ）[RFC6877]などの変換ベースの移行テクノロジ。これらのテクノロジーの一部では、インバウンドパケットが変換されたものかネイティブなものかを判別するために、専用のIPv6アドレスを利用できる必要があります（[RFC6877]、セクション6.3）。
o Identifier-locator addressing (ILA) [ILA].
o 識別子ロケータアドレッシング（ILA）[ILA]。
o Future applications (e.g., per-application IPv6 addresses [TARP]).
o 将来のアプリケーション（アプリケーションごとのIPv6アドレス[TARP]など）。
Two examples of how the availability of multiple addresses per host has already allowed substantial deployment of new applications without explicit requests to the network are:
ホストごとに複数のアドレスを使用できることで、ネットワークへの明示的な要求なしに、新しいアプリケーションの実質的な展開がすでにどのように可能になったかを示す2つの例を次に示します。
o 464XLAT. 464XLAT is usually deployed within a particular network; in this model, the operator can ensure that the network is appropriately configured to provide the customer-side translator (CLAT) with the additional IPv6 address it needs to implement 464XLAT. However, there are deployments where the provider-side translator (PLAT) (i.e., NAT64) is provided as a service by a different network, without the knowledge or cooperation of the residential ISP (e.g., the IPv6v4 Exchange Service [IPv6v4]). This type of deployment is only possible because those residential ISPs provide multiple IP addresses to their users, and thus those users can freely obtain the extra IPv6 address required to run 464XLAT.
o 464XLAT。 464XLATは通常、特定のネットワーク内に配置されます。このモデルでは、オペレーターは、464XLATの実装に必要な追加のIPv6アドレスをカスタマーサイドトランスレーター（CLAT）に提供するようにネットワークが適切に構成されていることを確認できます。ただし、プロバイダー側トランスレータ（PLAT）（つまり、NAT64）が、住宅用ISP（IPv6v4 Exchangeサービス[IPv6v4]など）の知識や協力なしに、別のネットワークによってサービスとして提供される展開もあります。この種類の展開は、これらの住宅用ISPがユーザーに複数のIPアドレスを提供し、464XLATの実行に必要な追加のIPv6アドレスを自由に取得できるためにのみ可能です。
o /64 sharing [RFC7278]. When the topology supports it, this is a way to provide IPv6 tethering without needing to wait for network operators to deploy DHCPv6 Prefix Delegation (PD), which is only available in 3GPP release 10 or above ([RFC6459], Section 5.3).
o / 64共有[RFC7278]。トポロジがサポートしている場合、これは、ネットワークオペレーターがDHCPv6プレフィックスデリゲーション（PD）を展開するのを待たずにIPv6テザリングを提供する方法です。これは、3GPPリリース10以降でのみ利用できます（[RFC6459]、セクション5.3）。
Providing a restricted number of addresses per host implies that functions that require multiple addresses either will be unavailable (e.g., if the network provides only one IPv6 address per host, or if the host has reached the limit of the number of addresses available) or will only be available after an explicit request to the network is granted. Requiring explicit requests to the network has the following drawbacks:
ホストごとに制限された数のアドレスを指定すると、複数のアドレスを必要とする機能が使用できなくなる（たとえば、ネットワークがホストごとに1つのIPv6アドレスしか提供しない場合、またはホストが使用可能なアドレス数の制限に達した場合）、またはネットワークへの明示的な要求が許可された後でのみ使用可能になります。ネットワークへの明示的な要求が必要な場合、次の欠点があります。
o Increased latency, because a provisioning operation, and possibly human intervention with an update to the Service Level Agreement (SLA), must complete before the functionality is available.
o プロビジョニング操作、および場合によってはサービスレベルアグリーメント（SLA）への更新による人間の介入が機能を使用する前に完了する必要があるため、レイテンシが増加します。
o Uncertainty, because it is not known if a particular application function will be available until the provisioning operation succeeds or fails.
o 不確定性。プロビジョニング操作が成功するか失敗するまで、特定のアプリケーション機能が利用可能かどうかは不明であるため。
o Complexity, because implementations need to deal with failures and somehow present them to the user. Failures may manifest as timeouts, which may be slow and frustrating to users.
o 実装が失敗に対処し、どういうわけかそれらをユーザーに提示する必要があるため、複雑さ。障害はタイムアウトとして現れる可能性があり、タイムアウトが発生してユーザーに不満を与える可能性があります。
o Increased load on the network's provisioning servers.
o ネットワークのプロビジョニングサーバーの負荷の増加。
Some operators may desire that their networks be configured to limit the number of IPv6 addresses per host. Reasons might include hardware limitations (e.g., Ternary Content-Addressable Memory (TCAM) size or size constraints of the Neighbor Cache table), business models (e.g., a desire to charge the network's users on a per-device basis), or operational consistency with IPv4 (e.g., an IP address management system that only supports one address per host). However, hardware limitations are expected to ease over time, and an attempt to generate additional revenue by charging per device may prove counterproductive if customers respond (as they did with IPv4) by using NAT, which results in no additional revenue, but leads to more operational problems and higher support costs.
一部のオペレーターは、ホストごとのIPv6アドレスの数を制限するようにネットワークを構成することを望んでいる場合があります。理由には、ハードウェアの制限（Ternary Content-Addressable Memory（TCAM）のサイズまたは近隣キャッシュテーブルのサイズの制約など）、ビジネスモデル（デバイスごとにネットワークのユーザーに課金したいなど）、または運用の一貫性が含まれますIPv4（たとえば、ホストごとに1つのアドレスのみをサポートするIPアドレス管理システム）。ただし、ハードウェアの制限は時間の経過とともに緩和すると予想され、デバイスごとに課金することで追加の収益を生み出そうとすると、NATを使用して顧客が（IPv4で行ったように）応答すると逆効果になることがあり、追加の収益は得られませんが、より多くの運用上の問題と高いサポートコスト。
When the network limits the number of addresses available to a host, this can mostly be overcome by end hosts by using NAT, and indeed in IPv4 the scarcity of addresses is often mitigated by using NAT on the host. Thus, the limits could be overcome in IPv6 as well by implementing NAT66 on the host.
ホストが利用できるアドレスの数がネットワークで制限されている場合、これはほとんどの場合、NATを使用することによりエンドホストで解決できます。実際、IPv4では、ホストでNATを使用することでアドレスの不足が軽減されることがよくあります。したがって、ホストにNAT66を実装することにより、IPv6でも制限を克服できます。
Unfortunately, NAT has well-known drawbacks. For example, it causes application complexity due to the need to implement NAT traversal. It hinders development of new applications. On mobile devices, it reduces battery life due to the necessity of frequent keepalives, particularly for UDP. Applications using UDP that need to work on most of the Internet are forced to send keepalives at least every 30 seconds [KA]. For example, the QUIC protocol uses a 15-second keepalive [QUIC]. Other drawbacks of NAT are well-known and documented [RFC2993]. While IPv4 NAT is inevitable due to the limited amount of IPv4 space available, that argument does not apply to IPv6. Guidance from the Internet Architecture Board (IAB) is that deployment of IPv6 NAT is not desirable [RFC5902].
残念ながら、NATには既知の欠点があります。たとえば、NATトラバーサルを実装する必要があるため、アプリケーションが複雑になります。新しいアプリケーションの開発を妨げます。モバイルデバイスでは、特にUDPの場合、キープアライブを頻繁に行う必要があるため、バッテリーの寿命が短くなります。ほとんどのインターネットで動作する必要があるUDPを使用するアプリケーションは、少なくとも30秒ごとにキープアライブを送信する必要があります[KA]。たとえば、QUICプロトコルは15秒のキープアライブ[QUIC]を使用します。 NATの他の欠点はよく知られており、文書化されています[RFC2993]。利用可能なIPv4スペースが限られているため、IPv4 NATは避けられませんが、その議論はIPv6には適用されません。インターネットアーキテクチャボード（IAB）からのガイダンスは、IPv6 NATの展開は望ましくないということです[RFC5902]。
The desire to overcome the problems listed in Section 4 without disabling any features has resulted in developers implementing IPv6 NAT. There are fully stateful address+port NAT66 implementations in client operating systems today: for example, Linux has supported NAT66 since 2012 [L66]. At least one popular software hypervisor also implemented NAT66 to work around these issues [V66]. Wide deployment of networks that provide a restricted number of addresses will cause proliferation of NAT66 implementations.
機能を無効にすることなく、セクション4にリストされている問題を克服したいという願望から、開発者はIPv6 NATを実装しています。今日、クライアントオペレーティングシステムには完全にステートフルなアドレス+ポートNAT66実装があります。たとえば、Linuxは2012年からNAT66をサポートしています[L66]。これらの問題を回避するために、少なくとも1つの一般的なソフトウェアハイパーバイザーもNAT66を実装しました[V66]。制限された数のアドレスを提供するネットワークの幅広い展開は、NAT66実装の急増を引き起こします。
This is not a desirable outcome. It is not desirable for users because they may experience application brittleness. It is likely not desirable for network operators either, as they may suffer higher support costs, and even when the decision to provide only one IPv6 address per device is dictated by the network's business model, there may be little in the way of incremental revenue, because devices can share their IPv6 address with other devices. Finally, it is not desirable for operating system manufacturers and application developers, who will have to build more complexity, lengthening development time and/or reducing the time spent on other features.
これは望ましい結果ではありません。ユーザーがアプリケーションの脆弱性を経験する可能性があるため、ユーザーには望ましくありません。ネットワークオペレーターもサポートコストが高くなる可能性があり、デバイスごとに1つのIPv6アドレスのみを提供する決定がネットワークのビジネスモデルによって決定される場合でも、ネットワークオペレーターには望ましくない可能性があります。デバイスが他のデバイスとIPv6アドレスを共有できるためです。最後に、オペレーティングシステムの製造元やアプリケーション開発者は、より複雑にしたり、開発時間を長くしたり、他の機能に費やす時間を減らしたりすることは望ましくありません。
Indeed, it could be argued that the main reason for deploying IPv6, instead of continuing to scale the Internet using only IPv4 and large-scale NAT44, is because doing so can provide all the hosts on the planet with end-to-end connectivity that is constrained not by accidental technical limitations, but only by intentional security policies.
実際、IPv4と大規模なNAT44のみを使用してインターネットを拡張し続ける代わりにIPv6を展開する主な理由は、そうすることで地球上のすべてのホストにエンドツーエンドの接続を提供できるためです。偶発的な技術的制限によってではなく、意図的なセキュリティポリシーによってのみ制約されます。
Multiple IPv6 addresses can be provided in the following ways:
複数のIPv6アドレスは、次の方法で提供できます。
o Using Stateless Address Autoconfiguration (SLAAC) [RFC4862]. SLAAC allows hosts to create global IPv6 addresses on demand by simply forming new addresses from the global prefix(es) assigned to the link. Typically, SLAAC is used on shared links, but it is also possible to use SLAAC while providing a dedicated /64 prefix to each host. This is the case, for example, if the host is connected via a point-to-point link such as in 3GPP networks, on a network where each host has its own dedicated VLAN, or on a wireless network where every Media Access Control (MAC) address is placed in its own broadcast domain.
o ステートレスアドレス自動構成（SLAAC）[RFC4862]の使用。 SLAACを使用すると、リンクに割り当てられたグローバルプレフィックスから新しいアドレスを作成するだけで、ホストはオンデマンドでグローバルIPv6アドレスを作成できます。通常、SLAACは共有リンクで使用されますが、各ホストに専用の/ 64プレフィックスを提供しながらSLAACを使用することもできます。これは、たとえば、ホストが3GPPネットワークなどのポイントツーポイントリンクを介して接続されている場合、各ホストが独自の専用VLANを持っているネットワーク、またはすべてのメディアアクセスコントロール（ MAC）アドレスは、独自のブロードキャストドメインに配置されます。
o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 clients only ask for one non-temporary address, but the protocol allows requesting multiple temporary and even multiple non-temporary addresses, and the server could choose to provide multiple addresses. It is also technically possible for a client to request additional addresses using a different DHCP Unique Identifier (DUID), though the DHCPv6 specification implies that this is not expected behavior ([RFC3315], Section 9). The DHCPv6 server will decide whether to grant or reject the request based on information about the client, including its DUID, MAC address, and more. The maximum number of IPv6 addresses that can be provided in a single DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is approximately 30.
oステートフルDHCPv6アドレス割り当ての使用[RFC3315]。ほとんどのDHCPv6クライアントは1つの非一時アドレスのみを要求しますが、プロトコルは複数の一時アドレスと複数の非一時アドレスを要求することを許可し、サーバーは複数のアドレスを提供することを選択できます。 DHCPv6仕様では、これは予期された動作ではないことが示されていますが（[RFC3315]、セクション9）、クライアントが別のDHCP一意識別子（DUID）を使用して追加のアドレスをリクエストすることも技術的に可能です。 DHCPv6サーバーは、クライアントのDUID、MACアドレスなどの情報に基づいて、要求を許可するか拒否するかを決定します。通常のMTUが1500バイト以下の場合、単一のDHCPv6パケットで提供できるIPv6アドレスの最大数は約30です。
o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the client to request and be delegated a prefix, from which it can autonomously form other addresses. If the prefix is shorter than /64, it can be divided into multiple subnets that can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], or /64 sharing [RFC7278], but it cannot be further subdivided, as a prefix longer than /64 is outside the current IPv6 specifications [RFC7421]. While the DHCPv6 Prefix Delegation specification [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD itself does not require that the client forward IPv6 packets not addressed to itself, and thus does not require that the client be an IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in many cases (such as tethering, or hosting virtual machines), hosts are already forwarding IPv6 packets and thus operating as IPv6 routers as defined in the IPv6 specification [RFC2460].
o DHCPv6プレフィックス委任（PD）[RFC3633]。 DHCPv6 PDを使用すると、クライアントはプレフィックスを要求して委任することができ、そこから他のアドレスを自律的に形成できます。プレフィックスが/ 64より短い場合は、複数のサブネットに分割して、さらにダウンストリームクライアントに委任できます。プレフィックスが/ 64の場合、L2ブリッジ、近隣探索（ND）プロキシ[RFC4389]、または/ 64共有[RFC7278]を介して拡張できますが、/ 64よりも長いプレフィックスが外側にあるため、さらに細分化することはできません。現在のIPv6仕様[RFC7421]。 DHCPv6プレフィックス委任仕様[RFC3633]は、DHCPv6クライアントがルーターであると想定していますが、DHCPv6 PD自体は、クライアントが自身にアドレス指定されていないIPv6パケットを転送する必要がないため、クライアントがIPv6ルーターである必要はありません。 IPv6仕様[RFC2460]。また、多くの場合（テザリングや仮想マシンのホスティングなど）、ホストはすでにIPv6パケットを転送しているため、IPv6仕様[RFC2460]で定義されているIPv6ルーターとして動作しています。
+--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | |
| | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+
| Can extend network | No+ | No | Yes | Yes |
| | | | | (NAT44) |
| Can number "unlimited" | Yes* | Yes* | No | No |
| endpoints | | | | |
| Uses stateful, request- | No | Yes | Yes | Yes |
| based assignment | | | | |
| Is immune to Layer 3 on- | No | Yes | Yes | Yes |
| link resource exhaustion | | | | |
| attacks | | | | |
+--------------------------+-------+-------------+--------+---------+
[*] Subject to network limitations, e.g., ND cache entry size limits. [+] Except on certain networks, e.g., /64 sharing [RFC7278].
[*] NDキャッシュエントリサイズの制限など、ネットワークの制限を受けます。 [+] / 64共有などの特定のネットワークを除く[RFC7278]。
Table 1: Comparison of Multiple Address Assignment Options
表1：複数のアドレス割り当てオプションの比較
If we itemize the use cases from Section 3, we can estimate the number of addresses currently used in normal operations. In typical implementations, privacy addresses use up to 7 addresses -- one per day ([RFC4941], Section 3.5). Current mobile devices sharing an uplink connection may typically support 8 downstream client devices, with each one requiring one or more addresses. A client might choose to run several virtual machines. Current implementations of 464XLAT require the use of a separate address. Some devices require another address for their baseband chip. Even a host performing just a few of these functions simultaneously might need on the order of 20 addresses at the same time. Future applications designed to use an address per application or even per resource will require many more. These will not function on networks that enforce a hard limit on the number of addresses provided to hosts. Thus, in general it is not possible to estimate in advance how many addresses are required.
セクション3のユースケースを項目化すると、通常の操作で現在使用されているアドレスの数を推定できます。一般的な実装では、プライバシーアドレスは最大7つのアドレスを使用します-1日1つ（[RFC4941]、セクション3.5）。アップリンク接続を共有する現在のモバイルデバイスは、通常、8つのダウンストリームクライアントデバイスをサポートし、それぞれに1つ以上のアドレスが必要です。クライアントが複数の仮想マシンを実行することを選択する場合があります。 464XLATの現在の実装では、別のアドレスを使用する必要があります。一部のデバイスでは、ベースバンドチップに別のアドレスが必要です。これらの機能のいくつかだけを同時に実行するホストでも、同時におよそ20のアドレスが必要になる場合があります。アプリケーションごと、またはリソースごとにアドレスを使用するように設計された将来のアプリケーションでは、さらに多くのものが必要になります。これらは、ホストに提供されるアドレス数にハード制限を適用するネットワークでは機能しません。したがって、一般に、必要なアドレス数を事前に見積もることはできません。
In order to avoid the problems described above and preserve the Internet's ability to support new applications that use more than one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts. To support future use cases, it is NOT RECOMMENDED to impose a hard limit on the size of the address pool assigned to a host. Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 address per prefix.
上記の問題を回避し、複数のIPv6アドレスを使用する新しいアプリケーションをサポートするインターネットの機能を維持するために、IPv6ネットワークの展開では、各プレフィックスから汎用ホストに複数のIPv6アドレスを提供することをお勧めします。将来の使用例をサポートするために、ホストに割り当てられたアドレスプールのサイズにハード制限を課すことはお勧めしません。特に、ホストをプレフィックスごとに1つのIPv6アドレスのみに制限することはお勧めしません。
Due to the drawbacks imposed by requiring explicit requests for address space (see Section 4), it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. This can be achieved either by allowing the host to form new addresses autonomously (e.g., via SLAAC) or by providing the host with a dedicated /64 prefix. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
アドレス空間の明示的な要求を要求することによって課される欠点（セクション4を参照）のため、ネットワークがホストに明示的な要求を要求せずに新しいアドレスを使用する機能を提供することが推奨されます。これは、ホストが自律的に（SLAACなどを介して）新しいアドレスを形成できるようにするか、ホストに専用の/ 64プレフィックスを提供することによって実現できます。プレフィックスは、DHCPv6 PD、デバイスごとのVLANを備えたSLAAC、またはその他の手段を使用して提供される場合があります。
Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multiple addresses when the host connects (e.g., the approximately 30 addresses that can fit into a single packet) would accommodate current clients, but it sets a limit on the number of addresses available to hosts when they attach and therefore limits the development of future applications.
ステートフルアドレス割り当て（DHCPv6 IA_NAまたはIA_TA）を使用して、ホストが接続するときに複数のアドレス（たとえば、単一のパケットに収まる約30個のアドレス）を提供すると、現在のクライアントに対応できますが、使用可能なアドレスの数に制限が設定されますホストは接続時にホストするため、将来のアプリケーションの開発を制限します。
Some network operators -- often operators of networks that provide services to third parties such as university campus networks -- are required to track which IP addresses are assigned to which hosts on their network. Maintaining persistent logs that map user IP addresses and timestamps to hardware identifiers such as MAC addresses may be used to attribute liability for copyright infringement or other illegal activity.
一部のネットワークオペレーター（多くの場合、大学のキャンパスネットワークなどのサードパーティにサービスを提供するネットワークのオペレーター）は、ネットワーク上のどのホストにどのIPアドレスが割り当てられているかを追跡する必要があります。ユーザーのIPアドレスとタイムスタンプをMACアドレスなどのハードウェア識別子にマッピングする永続的なログを維持することは、著作権侵害またはその他の違法行為の責任を特定するために使用できます。
It is worth noting that this requirement can be met without using DHCPv6 address assignment. For example, it is possible to maintain these mappings by monitoring the IPv6 neighbor table: routers typically allow periodic dumps of the Neighbor Cache via the Simple Network Management Protocol (SNMP) or other means, and many can be configured to log every change to the Neighbor Cache. Using SLAAC with a dedicated /64 prefix for each host simplifies tracking, as it does not require logging every address formed by the host, but only the prefix assigned to the host when it attaches to the network. Similarly, providing address space using DHCPv6 PD has the same tracking properties as DHCPv6 address assignment, but allows the network to provide unrestricted address space.
DHCPv6アドレス割り当てを使用しなくても、この要件を満たすことができることに注意してください。たとえば、IPv6ネイバーテーブルを監視することにより、これらのマッピングを維持することができます。ルーターは通常、シンプルネットワーク管理プロトコル（SNMP）またはその他の手段を介してネイバーキャッシュの定期的なダンプを許可し、多くの設定を変更して、ネイバーキャッシュ。ホストごとに専用の/ 64プレフィックスを付けてSLAACを使用すると、ホストによって形成されたすべてのアドレスをログに記録する必要がなく、ネットワークに接続するときにホストに割り当てられたプレフィックスのみをログに記録する必要があるため、追跡が簡単になります。同様に、DHCPv6 PDを使用してアドレススペースを提供することには、DHCPv6アドレス割り当てと同じトラッキングプロパティがありますが、ネットワークは無制限のアドレススペースを提供できます。
Many large enterprise networks are fully dual stack and implement address monitoring without using or supporting DHCPv6. The authors are directly aware of several networks that operate in this way, including the Universities of Loughborough, Minnesota, Reading, Southampton, and Wisconsin, and Imperial College London, in addition to the enterprise networks of the authors' employers.
多くの大規模エンタープライズネットワークは完全にデュアルスタックであり、DHCPv6を使用またはサポートせずにアドレス監視を実装しています。著者は、著者の雇用主の企業ネットワークに加えて、ラフバラ大学、ミネソタ大学、レディング大学、サウサンプトン大学、ウィスコンシン大学、インペリアルカレッジロンドンなど、このように動作するいくつかのネットワークを直接認識しています。
It should also be noted that using DHCPv6 address assignment does not ensure that the network can reliably track the IPv6 addresses used by hosts. On any shared network without Layer 2 (L2) edge port security, hosts are able to choose their own addresses regardless of what address provisioning methodology the network operator believes is in use. The only way to restrict the addresses used by hosts is to use L2 security mechanisms that enforce that particular IPv6 addresses are used by particular link-layer addresses (for example, Source Address Validation Improvement (SAVI) [RFC7039]). If those mechanisms are available, it is possible to use them to provide tracking; this form of tracking is more secure and reliable than server logs because it operates independently of how addresses are allocated. Finally, tracking address information via DHCPv6 server logs is likely to become decreasingly viable due to ongoing efforts to improve the privacy of DHCPv6 and MAC address randomization [RFC7844].
DHCPv6アドレス割り当てを使用しても、ネットワークがホストによって使用されるIPv6アドレスを確実に追跡できるとは限らないことにも注意してください。レイヤー2（L2）エッジポートセキュリティのない共有ネットワークでは、ネットワークオペレーターが使用していると考えるアドレスプロビジョニング方法に関係なく、ホストは独自のアドレスを選択できます。ホストによって使用されるアドレスを制限する唯一の方法は、特定のIPv6アドレスが特定のリンク層アドレスによって使用されることを強制するL2セキュリティメカニズムを使用することです（たとえば、Source Address Validation Improvement（SAVI）[RFC7039]）。これらのメカニズムが利用可能な場合、それらを使用して追跡を提供することが可能です。この形式の追跡は、アドレスの割り当て方法とは関係なく動作するため、サーバーログよりも安全で信頼性が高くなります。最後に、DHCPv6およびMACアドレスのランダム化[RFC7844]のプライバシーを改善するための継続的な取り組みにより、DHCPv6サーバーログを介してアドレス情報を追跡することは、実行可能性が低下する可能性があります。
In IPv4, all but the world's largest networks can be addressed using private space [RFC1918], with each host receiving one IPv4 address. Many networks can be numbered in 192.168.0.0/16, which has roughly 65 thousand addresses. In IPv6, that is equivalent to a /48, with each host receiving a /64 prefix. Under current Regional Internet Registry (RIR) policies, a /48 is easy to obtain for an enterprise network. Networks that need a bigger block of private space use 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is equivalent to a /40, with each host receiving a /64 prefix. Enterprises of such size can easily obtain a /40 under current RIR policies.
IPv4では、各ホストが1つのIPv4アドレスを受信するプライベートスペース[RFC1918]を使用して、世界最大のネットワークを除くすべてのアドレスを指定できます。多くのネットワークは、およそ65千のアドレスを持つ192.168.0.0/16で番号を付けることができます。 IPv6では、これは/ 48に相当し、各ホストは/ 64プレフィックスを受け取ります。現在の地域インターネットレジストリ（RIR）ポリシーでは、/ 48はエンタープライズネットワークで簡単に取得できます。プライベートスペースのより大きなブロックを必要とするネットワークは、およそ1600万のアドレスを持つ10.0.0.0/8を使用します。 IPv6では、これは/ 40に相当し、各ホストは/ 64プレフィックスを受け取ります。このような規模の企業は、現在のRIRポリシーでは/ 40を簡単に取得できます。
In the above cases, aggregation and routing can be equivalent to IPv4: if a network aggregates per-host IPv4 addresses into prefixes of length /32 - n, it can aggregate per-host /64 prefixes into the same number of prefixes of length /64 - n.
上記の場合、集約とルーティングはIPv4と同等です。ネットワークがホストごとのIPv4アドレスを長さ/ 32-nのプレフィックスに集約すると、ホストごとの/ 64プレフィックスを同じ長さのプレフィックス/に集約できます。 64-n。
Currently, residential users typically receive one IPv4 address and a /48, /56, or /60 IPv6 prefix. While such networks do not provide enough space to assign a /64 per host, such networks almost universally use SLAAC, and thus do not pose any particular limit to the number of addresses hosts can use.
現在、一般家庭ユーザーは通常、1つのIPv4アドレスと/ 48、/ 56、または/ 60 IPv6プレフィックスを受け取ります。このようなネットワークは、ホストごとに/ 64を割り当てるのに十分なスペースを提供しませんが、そのようなネットワークはほぼ普遍的にSLAACを使用するため、ホストが使用できるアドレスの数に特定の制限を課しません。
Unlike IPv4 where addresses came at a premium, in all of these networks there is enough IPv6 address space to supply clients with multiple IPv6 addresses.
アドレスが非常に重要であったIPv4とは異なり、これらのすべてのネットワークには、クライアントに複数のIPv6アドレスを提供するのに十分なIPv6アドレス空間があります。
The number of IPv6 addresses on a link has a direct impact on networking infrastructure nodes (routers, switches) and other nodes on the link. Setting aside exhaustion attacks via L2 address spoofing, every (L2, IP) address pair impacts networking hardware requirements in terms of memory, Multicast Listener Discovery (MLD) snooping, solicited node multicast groups, etc. Many of these costs are incurred by neighboring hosts.
リンク上のIPv6アドレスの数は、ネットワークインフラストラクチャノード（ルーター、スイッチ）およびリンク上の他のノードに直接影響します。 L2アドレススプーフィングによる枯渇攻撃を別にして、すべての（L2、IP）アドレスペアは、メモリ、マルチキャストリスナーディスカバリー（MLD）スヌーピング、要請ノードマルチキャストグループなどのネットワークハードウェア要件に影響を与えます。これらのコストの多くは、隣接ホストによって発生します。 。
Hosts on such networks that create unreasonable numbers of addresses risk impairing network connectivity for themselves and other hosts on the network, and in extreme cases (e.g., hundreds or thousands of addresses) may even find their network access restricted by denial-of-service protection mechanisms.
不当な数のアドレスを作成するこのようなネットワーク上のホストは、自分自身とネットワーク上の他のホストのネットワーク接続を損なう危険性があり、極端な場合（たとえば、数百または数千のアドレス）は、サービス拒否保護によってネットワークアクセスが制限されていることに気付く場合があります。メカニズム。
We expect these scaling limitations to change over time as hardware and applications evolve. However, switching to a dedicated /64 prefix per host can resolve these scaling limitations. If the prefix is provided via DHCPv6 PD, or if the prefix can be used by only one link-layer address (e.g., if the link layer uniquely identifies or authenticates hosts based on MAC addresses), then there will be only one routing entry and one ND cache entry per host on the network. Furthermore, if the host is aware that the prefix is dedicated (e.g., if it was provided via DHCPv6 PD and not SLAAC), it is possible for the host to assign IPv6 addresses from this prefix to an internal virtual interface such as a loopback interface. This obviates the need to perform Neighbor Discovery and Duplicate Address Detection on the network interface for these addresses, reducing network traffic.
ハードウェアとアプリケーションが進化するにつれて、これらのスケーリングの制限は時間とともに変化すると予想しています。ただし、ホストごとに専用の/ 64プレフィックスに切り替えると、これらのスケーリングの制限を解決できます。プレフィックスがDHCPv6 PDを介して提供される場合、またはプレフィックスが1つのリンク層アドレスのみで使用できる場合（たとえば、リンク層がMACアドレスに基づいてホストを一意に識別または認証する場合）、ルーティングエントリは1つだけであり、ネットワーク上のホストごとに1つのNDキャッシュエントリ。さらに、プレフィックスが専用であることをホストが認識している場合（SLAACではなくDHCPv6 PDを介して提供された場合など）、ホストはこのプレフィックスからIPv6アドレスをループバックインターフェイスなどの内部仮想インターフェイスに割り当てることができます。 。これにより、これらのアドレスのネットワークインターフェイスで近隣探索と重複アドレス検出を実行する必要がなくなり、ネットワークトラフィックが減少します。
Thus, assigning a dedicated /64 prefix per host is operationally prudent. Clearly, however, it requires more IPv6 address space than using shared links, so the benefits provided must be weighed with the operational overhead of address space management.
したがって、ホストごとに専用の/ 64プレフィックスを割り当てることは、運用上は賢明です。ただし、明らかに、共有リンクを使用する場合よりも多くのIPv6アドレス空間が必要になるため、提供される利点は、アドレス空間管理の運用オーバーヘッドと比較検討する必要があります。
As mentioned in Section 9.3, on shared networks using SLAAC, it is possible for hosts to attempt to exhaust network resources and possibly deny service to other hosts by creating unreasonable numbers (e.g., hundreds or thousands) of addresses. Networks that provide access to untrusted hosts can mitigate this threat by providing a dedicated /64 prefix per host. It is also possible to mitigate the threat by limiting the number of ND cache entries that can be created for a particular host, but care must be taken to ensure that the network does not prevent the legitimate use of multiple IP addresses by non-malicious hosts.
セクション9.3で述べたように、SLAACを使用する共有ネットワークでは、ホストがネットワークリソースを使い果たし、不当な数（数百または数千など）のアドレスを作成することにより、他のホストへのサービスを拒否する可能性があります。信頼できないホストへのアクセスを提供するネットワークは、ホストごとに専用の/ 64プレフィックスを提供することにより、この脅威を軽減できます。特定のホストに対して作成できるNDキャッシュエントリの数を制限することで脅威を軽減することも可能ですが、ネットワークが悪意のないホストによる複数のIPアドレスの正当な使用を妨げないように注意する必要があります。
Security issues related to host tracking are discussed in Section 9.1.
ホストトラッキングに関連するセキュリティの問題については、セクション9.1で説明します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[ILA] Herbert, T., "Identifier-locator addressing for network virtualization", Work in Progress, draft-herbert-nvo3- ila-02, March 2016.
[ILA]ハーバートT.、「ネットワーク仮想化の識別子ロケーターアドレッシング」、進行中の作業、draft-herbert-nvo3-ila-02、2016年3月。
[IPv6v4] Japan Internet Exchange, "IPv6v4 Exchange Service", April 2013, <http://www.jpix.ad.jp/en/service/ipv6v4.html>.
[IPv6v4]日本インターネットエクスチェンジ、「IPv6v4エクスチェンジサービス」、2013年4月、<http://www.jpix.ad.jp/en/service/ipv6v4.html>。
[KA] Roskind, J., "Quick UDP Internet Connections", November 2013, <http://www.ietf.org/proceedings/88/slides/ slides-88-tsvarea-10.pdf>.
[KA] Roskind、J。、「Quick UDP Internet Connections」、2013年11月、<http://www.ietf.org/proceedings/88/slides/ slides-88-tsvarea-10.pdf>。
[L66] McHardy, P., "netfilter: ipv6: add IPv6 NAT support", Linux commit 58a317f1061c894d2344c0b6a18ab4a64b69b815, August 2012, <https://git.kernel.org/cgit/linux/kernel/ git/torvalds/linux.git/commit/ ?id=58a317f1061c894d2344c0b6a18ab4a64b69b815>.
[L66] McHardy、P。、「netfilter：ipv6：add IPv6 NAT support」、Linuxコミット58a317f1061c894d2344c0b6a18ab4a64b69b815、2012年8月、<https://git.kernel.org/cgit/linux/kernel/ git / torvalds / linux.git / commit /？id = 58a317f1061c894d2344c0b6a18ab4a64b69b815>。
[QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Work in Progress, draft-tsvwg-quic-protocol-02, January 2016.
[QUIC]ハミルトン、R。、アイアンガー、J。、スウェット、I。、およびA.ウィルク、「QUIC：HTTP / 2用のUDPベースの安全で信頼性の高いトランスポート」、作業中、draft-tsvwg-quic- protocol-02、2016年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, <http://www.rfc-editor.org/info/rfc2993>.
[RFC2993] Hain、T。、「NATのアーキテクチャ上の影響」、RFC 2993、DOI 10.17487 / RFC2993、2000年11月、<http://www.rfc-editor.org/info/rfc2993>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<http：//www.rfc-editor。 org / info / rfc3633>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、DOI 10.17487 / RFC4389、2006年4月、<http：//www.rfc-editor。 org / info / rfc4389>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<http：//www.rfc-editor .org / info / rfc4941>。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, DOI 10.17487/RFC5902, July 2010, <http://www.rfc-editor.org/info/rfc5902>.
[RFC5902] Thaler、D.、Zhang、L。、およびG. Lebovitz、「IAB Thoughts on IPv6 Network Address Translation」、RFC 5902、DOI 10.17487 / RFC5902、2010年7月、<http：//www.rfc-editor。 org / info / rfc5902>。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、DOI 10.17487 / RFC6434、2011年12月、<http://www.rfc-editor.org/info/ rfc6434>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、and K. Iisakkila、 "IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（ EPS） "、RFC 6459、DOI 10.17487 / RFC6459、January 2012、<http://www.rfc-editor.org/info/rfc6459>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M。、およびC. Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、DOI 10.17487 / RFC6877、2013年4月、<http：//www.rfc-editor .org / info / rfc6877>。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F。、およびC. Vogt、編、「Source Address Validation Improvement（SAVI）Framework」、RFC 7039、DOI 10.17487 / RFC7039、 2013年10月、<http://www.rfc-editor.org/info/rfc7039>。
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<http://www.rfc-editor.org / info / rfc7217>。
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>.
[RFC7278] Byrne、C.、Drown、D。、およびA. Vizdal、「IPv6 / 64プレフィックスを第3世代パートナーシッププロジェクト（3GPP）モバイルインターフェイスからLANリンクに拡張」、RFC 7278、DOI 10.17487 / RFC7278、 2014年6月、<http://www.rfc-editor.org/info/rfc7278>。
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421] Carpenter、B.、Ed。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。、およびA. Yourtchenko、「IPv6アドレッシングの64ビット境界の分析」、RFC 7421、DOI 10.17487 / RFC7421、2015年1月、<http://www.rfc-editor.org/info/rfc7421>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<http://www.rfc-editor.org/ info / rfc7844>。
[TARP] Gleitz, PM. and SB. Bellovin, "Transient Addressing for Related Processes: Improved Firewalling by Using IPv6 and Multiple Addresses per Host", In Proceedings of the Eleventh Usenix Security Symposium, August 2001, <https://www.usenix.org/legacy/events/sec01/gleitz.html>.
[TARP] Gleitz、PM。とSB。 Bellovin、「関連プロセスの一時アドレス指定：IPv6とホストごとに複数のアドレスを使用することによるファイアウォールの改善」、第11回Usenixセキュリティシンポジウムのプロシーディングス、2001年8月、<https://www.usenix.org/legacy/events/sec01/ gleitz.html>。
[TS.24327] 3GPP, "Mobility between 3GPP Wireless Local Area Network (WLAN) interworking (I-WLAN) and 3GPP systems; General Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage 3", 3GPP TS 24.327, June 2011, <http://www.3gpp.org/DynaReport/24327.htm>.
[TS.24327] 3GPP、「3GPPワイヤレスローカルエリアネットワーク（WLAN）インターワーキング（I-WLAN）と3GPPシステム間のモビリティ、汎用パケット無線システム（GPRS）と3GPP I-WLANの側面、ステージ3」、3GPP TS 24.327、 2011年6月、<http://www.3gpp.org/DynaReport/24327.htm>。
[V66] Oracle, "What's New in VirtualBox 4.3?", October 2013, <https://blogs.oracle.com/fatbloke/entry/ what_s_new_in_virtualbox>.
[V66] Oracle、「VirtualBox 4.3の新機能」、2013年10月、<https://blogs.oracle.com/fatbloke/entry/ what_s_new_in_virtualbox>。
Acknowledgements
謝辞
The authors thank Tore Anderson, Brian Carpenter, David Farmer, Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng (Will) Liu, Shin Miyakawa, Dieter Siegmund, Mark Smith, Sander Steffann, Fred Templin, and James Woodyatt for their input and contributions.
著者は、Tore Anderson、Brian Carpenter、David Farmer、Wesley George、Geoff Huston、Erik Kline、Victor Kuarsingh、Shucheng（Will）Liu、Shin Miyakawa、Dieter Siegmund、Mark Smith、Sander Steffann、Fred Templin、James Woodyattに感謝します。入力と貢献。
Authors' Addresses
著者のアドレス
Lorenzo Colitti Google Roppongi 6-10-1 Minato, Tokyo 106-6126 Japan
ぉれんぞ こぃっち ごおｇぇ ろっぽんぎ ６ー１０ー１ みなと、 ときょ １０６ー６１２６ じゃぱん
Email: lorenzo@google.com
Vint Cerf Google 1875 Explorer Street 10th Floor Reston, VA 20190 United States of America
Vint Cerf Google 1875 Explorer Street 10th Floor Reston、VA 20190アメリカ合衆国
Email: vint@google.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
スチュアートチェシャーアップル社1インフィニットループクパチーノ、カリフォルニア95014アメリカ合衆国
Email: cheshire@apple.com
David Schinazi Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
David Schinazi Apple Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国
Email: dschinazi@apple.com