Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 9663 Google, LLC
Category: Informational J. Linkova, Ed.
ISSN: 2070-1721 X. Ma, Ed.
Google
October 2024
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415.
このドキュメントでは、大規模なブロードキャストネットワーク（エンタープライズネットワークやパブリックWi-Fiネットワークなど）に接続された個々のノードが、RFC 8415で指定されているようにDHCPV6プレフィックス委任（DHCPV6-PD）を介して一意のプレフィックスを割り当てられた場合のIPv6展開シナリオについて説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9663.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9663で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Terminology
4. Design Principles
5. Applicability and Limitations
6. Routing and Addressing Considerations
6.1. Prefix Pool Allocation
6.2. First-Hop Router Requirements
6.3. Topologies with Multiple First-Hop Routers
6.4. On-Link Communication
7. DHCPv6-PD Server Considerations
8. Prefix Length Considerations
9. Client Mobility
10. Antispoofing and SAVI Interaction
11. Migration Strategies and Co-existence with SLAAC Using Prefixes
from the PIO
12. Benefits
13. Privacy Considerations
14. IANA Considerations
15. Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. Multiple Addresses Considerations
Acknowledgements
Authors' Addresses
Often, broadcast networks such as enterprise or public Wi-Fi deployments place many devices on a shared link with a single on-link prefix. This document describes an alternative deployment model where individual devices obtain prefixes from the network. This provides two important advantages.
多くの場合、エンタープライズやパブリックWi-Fiの展開などのブロードキャストネットワークは、単一のオンリンクプレフィックスを使用した共有リンクに多くのデバイスを配置します。このドキュメントでは、個々のデバイスがネットワークからプレフィックスを取得する代替展開モデルについて説明します。これは2つの重要な利点を提供します。
First, it offers better scalability. Unlike IPv4, IPv6 allows hosts to have multiple addresses, and this is the case in most deployments (see Appendix A for more details). However, increasing the number of addresses introduces scalability issues on the network infrastructure. Network devices need to maintain various types of tables and hashes (Neighbor Cache on first-hop routers, Neighbor Discovery Proxy caches on Layer 2 devices, etc.). On Virtual eXtensible Local Area Network (VXLAN) networks [RFC7348], each address might be represented as a route. This means, for example, that if every client has 10 addresses instead of one, the network must support 10 times more routes, etc. If an infrastructure device's resources are exhausted, the device might drop some IPv6 addresses from the corresponding tables, while the address owner might still be using the address to send traffic. This leads to traffic being discarded and a degraded customer experience. Providing every host with one prefix allows the network to maintain only one entry per device, while still providing the device the ability to use an arbitrary number of addresses.
まず、より良いスケーラビリティを提供します。IPv4とは異なり、IPv6を使用すると、ホストは複数のアドレスを持つことができます。これは、ほとんどの展開の場合です（詳細については、付録Aを参照）。ただし、アドレスの数を増やすと、ネットワークインフラストラクチャにスケーラビリティの問題が発生します。ネットワークデバイスは、さまざまなタイプのテーブルとハッシュを維持する必要があります（最初のホップルーターでのネイバーキャッシュ、レイヤー2デバイスの隣接ディスカバリープロキシキャッシュなど）。仮想拡張可能なローカルエリアネットワーク（VXLAN）ネットワーク[RFC7348]では、各アドレスがルートとして表される場合があります。これは、たとえば、すべてのクライアントが1つではなく10のアドレスを持っている場合、ネットワークは10倍のルートなどをサポートする必要があることを意味します。インフラストラクチャデバイスのリソースが使い果たされている場合、デバイスは対応するテーブルからIPv6アドレスをドロップする可能性があります。住所の所有者は、住所を使用してトラフィックを送信している可能性があります。これにより、トラフィックが破棄され、顧客体験が劣化します。すべてのホストに1つのプレフィックスを提供すると、ネットワークはデバイスごとに1つのエントリのみを維持でき、デバイスに任意の数のアドレスを使用する機能を提供できます。
Second, this deployment model provides the ability to extend the network. In IPv4, a device that connects to the network can provide connectivity to subtended devices by using NAT. With DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415], such a device can similarly extend the network, but unlike IPv4 NAT, it can provide its subtended devices with full end-to-end connectivity.
第二に、この展開モデルは、ネットワークを拡張する機能を提供します。IPv4では、ネットワークに接続するデバイスは、NATを使用して、抑制されたデバイスへの接続を提供できます。DHCPV6プレフィックス代表団（DHCPV6-PD）[RFC8415]を使用すると、このようなデバイスも同様にネットワークを拡張できますが、IPv4 NATとは異なり、エンドツーエンドの接続性をフルに供給することができます。
Another method of deploying unique prefixes per device is documented in [RFC8273]. Similarly, the standard deployment model in cellular IPv6 networks [RFC6459] provides a unique prefix to every device. However, providing a unique prefix per device is very uncommon in enterprise-style networks, where nodes are usually connected to broadcast segments such as VLANs and each link has a single on-link prefix assigned. This document takes a similar approach to [RFC8273], but allocates the prefix using DHCPv6-PD.
デバイスごとに一意のプレフィックスを展開する別の方法は、[RFC8273]に文書化されています。同様に、セルラーIPv6ネットワーク[RFC6459]の標準展開モデルは、すべてのデバイスに一意のプレフィックスを提供します。ただし、デバイスごとに一意のプレフィックスを提供することは、エンタープライズスタイルのネットワークでは非常にまれです。通常、ノードはVLANなどのブロードキャストセグメントに接続され、各リンクには単一のオンリンクプレフィックスが割り当てられています。このドキュメントは[RFC8273]と同様のアプローチを採用していますが、DHCPV6-PDを使用してプレフィックスを割り当てます。
This document focuses on the behavior of the network. Host behavior is not defined in this document.
このドキュメントは、ネットワークの動作に焦点を当てています。このドキュメントでは、ホストの動作は定義されていません。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Node:
ノード：
a device that implements IPv6 [RFC8200]
IPv6 [RFC8200]を実装するデバイス
Host:
ホスト：
any node that is not a router [RFC8200]
ルーターではないノード[RFC8200]
Client:
クライアント:
a node that connects to a network and acquires addresses. The node may wish to obtain addresses for its own use, or it may be a router that wishes to extend the network to its physical or virtual subsystems, or both. It may be either a host or a router as defined by [RFC8200].
ネットワークに接続してアドレスを取得するノード。ノードは、独自の使用のためにアドレスを取得したい場合があります。または、ネットワークを物理的または仮想サブシステム、またはその両方に拡張したいルーターである場合があります。[RFC8200]で定義されているホストまたはルーターのいずれかです。
AP:
AP:
(wireless) Access Point
（ワイヤレス）アクセスポイント
DHCPv6 IA_NA:
dhcpv6 ia_na：
Identity Association for Non-temporary Addresses (Section 21.4 of [RFC8415])
非同時住所のためのアイデンティティ協会（[RFC8415]のセクション21.4）
DHCPv6 IA_PD:
dhcpv6 ia_pd：
Identity Association for Prefix Delegation (Section 21.21 of [RFC8415])
接頭辞委任のアイデンティティ協会（[RFC8415]のセクション21.21）
DHCPv6-PD:
dhcpv6-pd：
DHCPv6 Prefix Delegation [RFC8415]; a mechanism to delegate IPv6 prefixes to clients.
DHCPV6プレフィックス委任[RFC8415];IPv6プレフィックスをクライアントに委任するメカニズム。
ND:
ND:
Neighbor Discovery [RFC4861]
隣人発見[RFC4861]
NUD:
NUD:
Neighbor Unreachability Detection [RFC4861]
隣人の到達不能の検出[RFC4861]
PIO:
PIO:
Prefix Information Option [RFC4862]
プレフィックス情報オプション[RFC4862]
SLAAC:
Slaac：
IPv6 Stateless Address Autoconfiguration [RFC4862]
IPv6ステートレスアドレスAutoconfiguration [RFC4862]
Instead of all clients on a given link forming addresses from the same shared prefix assigned to that link, this deployment model operates as described below:
特定のリンク上のすべてのクライアントの代わりに、そのリンクに割り当てられた同じ共有プレフィックスのアドレスを形成する代わりに、この展開モデルは以下に説明するように動作します。
* A device acts as a DHCPv6-PD client and requests a prefix via DHCPv6-PD by sending an IA_PD request.
* デバイスはDHCPV6-PDクライアントとして機能し、IA_PD要求を送信することによりDHCPV6-PDを介してプレフィックスを要求します。
* The server delegates a prefix to the client and the delegated prefix is installed into the routing table of the first-hop router as a route pointing to the client's link-local address. The first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply messages from an off-link DHCPv6 server, or it can act as a DHCPv6 server itself. In both cases, it can install the route locally, and if the network is running a dynamic routing protocol, distribute the route or the entire prefix pool into the protocol.
* サーバーはクライアントにプレフィックスを委任し、委任されたプレフィックスは、クライアントのリンクローカルアドレスを指すルートとして、最初のホップルーターのルーティングテーブルにインストールされます。最初のホップルーターは、DHCPV6リレーとして機能し、Off-Link DHCPV6サーバーからのSnoopDHCPV6応答メッセージまたはDHCPV6サーバー自体として機能することができます。どちらの場合も、ルートをローカルにインストールできます。ネットワークが動的ルーティングプロトコルを実行している場合は、ルートまたはプレフィックスプール全体をプロトコルに配布します。
* For the router and all other infrastructure devices, the delegated prefix is considered off-link, so traffic to that prefix does not trigger any ND packets, other than the minimum ND required to sustain Neighbor Unreachability Detection (NUD) for the client's link-local address.
* ルーターおよびその他のすべてのインフラストラクチャデバイスの場合、委任されたプレフィックスはオフリンクと見なされるため、クライアントのリンクローカルの近隣の到達性検出（NUD）を維持するために必要な最小NDを除き、そのプレフィックスへのトラフィックはNDパケットをトリガーしません。住所。
* The device can use the delegated prefix in various ways. For example, it can form addresses, as described in requirement WAA-7 of [RFC7084]. It can also extend the network, as described in [RFC7084] or [RFC7278].
* デバイスは、さまざまな方法で委任されたプレフィックスを使用できます。たとえば、[RFC7084]の要件WAA-7で説明されているように、アドレスを形成できます。[RFC7084]または[RFC7278]で説明されているように、ネットワークを拡張することもできます。
An example scenario is shown in Figure 1. Note that the prefix lengths used in the example are /64 because that is the prefix length currently supported by SLAAC and is not otherwise required by the proposed deployment model.
例のシナリオを図1に示します。この例で使用されているプレフィックスの長さは /64であることに注意してください。これは、SLAACによって現在サポートされており、提案された展開モデルでは必要ではないためです。
+------------------------------------------------------------------+
| DHCPv6 Servers |
| Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link |
+------------+---------------------+----------------------------+--+
^ | | ^ |
| | | | |
+-------+------+---------------------+--------------------+-------+---+
| DHCPv6| | IPv6 Network DHCPv6 | | |
|Relay-Forward | Relay-Forward | |
| ^ v Route for 3fff:0:d::/48 ^ v |
| | DHCPv6 | | | DHCPv6 |
| | Relay-Reply | | | Relay-Reply|
| | | | | | | |
+------+-------+--+----------+------------+------+-------+--------+---+
| | | | | | | |
| v | v v | | v
+----+----------+---------------+ +---------+-------+------------+
| First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay|
| 3fff:0:d:1::/64 -> fe80::aa | | 3fff:0:d:1::/64 -> fe80::aa |
| 3fff:0:d:2::/64 -> fe80::cc | | 3fff:0:d:2::/64 -> fe80::cc |
+------------+----------+-------+ +--------+----------------+----+
^ | | Shared IPv6 link | ^ |
| | | 2001:db8:ff::/64 | | |
| | -+-----+-----------+---------+-----+- | |
| | | | | | |
| | | +---------------+-------------+ | DHCPv6 |
DHCPv6 | | | Client B (no DHCPv6-PD) | | Request v
Request | | |link-local address fe80::b | | ^ DHCPv6
^ | | |global address 2001:db8:ff::b| | | Reply
| | | +-----------------------------+ | | |
| v | | | v
| DHCPv6 | +--------------------+--+----------+
| Reply | | Client C |
| | | | link-local address fe80::cc |
| | | | delegated prefix 3fff:0:d:2::/64 |
| | | +------------+-------------------+-+
| v | | |
+---+-------------+----------------------+ | Router |
| Client A | | Advertisement |
| link-local address: fe80::aa | | containing PIO v
| delegated prefix: 3fff:0:d:1::/64 | | 3fff:0:d:2::/64
| +----------------+ +----------------+ | -+---------+-----------
| | virtual system | | virtual system | | |
| | 3fff:0:d:1::de | | 3fff:0:d:1::ad | | +------+----------+
| | 3fff:0:d:1::ca | | 3fff:0:d:1::fe | | | Tethered device |
| +----------------+ +----------------+ | | 3fff:0:d:2::66 |
| | +-----------------+
+----------------------------------------+
Figure 1: An Example Topology with Two First-Hop Routers
図1：2つの最初のホップルーターを備えたトポロジの例
Delegating a unique prefix per client provides all the benefits of both SLAAC and DHCPv6 address allocation, but at the cost of greater address-space usage. This design would substantially benefit some networks (see Section 12) in which the additional cost of an additional service (such as DHCPv6 Prefix Delegation) and allocation of a larger amount of address space can easily be justified. Examples of such networks include but are not limited to:
クライアントごとに一意のプレフィックスを委任すると、SLAACとDHCPV6アドレスの両方のアドレス割り当てのすべての利点がありますが、アドレス空間使用量が大きくなります。この設計は、追加のサービス（DHCPV6プレフィックス委任など）の追加コストと、より多くのアドレススペースの割り当てを簡単に正当化できるいくつかのネットワーク（セクション12を参照）に大幅に利益をもたらすでしょう。このようなネットワークの例には、以下が含まれますが、これらに限定されません。
* Large-scale networks where even three to five addresses per client might introduce scalability issues.
* クライアントごとに3〜5個のアドレスでさえ、スケーラビリティの問題が発生する可能性のある大規模なネットワーク。
* Networks with a high number of virtual hosts, so physical devices require multiple addresses.
* 多数の仮想ホストを備えたネットワークなので、物理デバイスには複数のアドレスが必要です。
* Managed networks where extensive troubleshooting, device traffic logging, or forensics might be required.
* 大規模なトラブルシューティング、デバイストラフィックロギング、またはフォレンジックが必要な管理ネットワークが必要になる場合があります。
In smaller networks, such as home networks or small enterprises with smaller address space and a lower number of clients, SLAAC is a simpler and often preferred option.
より小さな住所スペースとより少ないクライアントを備えたホームネットワークや小規模企業などの小規模なネットワークでは、SLAACはよりシンプルで頻繁に好ましいオプションです。
One simple deployment model is to assign a dedicated prefix pool to each link. The prefixes from each link's pool are only issued to requesting clients on the link; if clients move to another link, they will obtain a prefix from the pool associated with the new link (see Section 9).
単純な展開モデルの1つは、各リンクに専用のプレフィックスプールを割り当てることです。各リンクのプールのプレフィックスは、リンク上のクライアントを要求するためにのみ発行されます。クライアントが別のリンクに移動すると、新しいリンクに関連付けられたプールからプレフィックスを取得します（セクション9を参照）。
This is very similar to how address pools are allocated when using DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of addresses, and clients on the link obtain addresses from the pool. In this model, the network can route the entire pool to the link's first-hop routers, and the routers do not need to advertise individual delegated prefixes into the network's dynamic routing protocol.
これは、DHCPを使用して個々のアドレス（DHCPV4またはDHCPV6 IA_NAなど）を割り当てる場合、アドレスプールが割り当てられる方法と非常によく似ています。各リンクにはアドレスの専用プールがあり、リンク上のクライアントはプールからアドレスを取得します。このモデルでは、ネットワークはプール全体をリンクの最初のホップルーターにルーティングでき、ルーターは個々の委任されたプレフィックスをネットワークの動的ルーティングプロトコルに宣伝する必要はありません。
Other deployment models, such as prefix pools shared over multiple links or routers, are possible but are not described in this document.
複数のリンクまたはルーターで共有されたプレフィックスプールなどの他の展開モデルは可能ですが、このドキュメントでは説明されていません。
In large networks, DHCPv6 servers are usually centralized and reached via DHCPv6 relays co-located with the first-hop routers. To delegate IPv6 prefixes to clients, the first hop routers need to implement DHCPv6 relay functions and meet the requirements defined in [RFC8987]. In particular, per Section 4.2 of [RFC8987], the first-hop router must maintain a local routing table that contains all prefixes delegated to clients.
大規模なネットワークでは、DHCPV6サーバーは通常集中化され、ファーストホップルーターと共同住宅されたDHCPV6リレーを介して到達します。IPv6プレフィックスをクライアントに委任するには、最初のホップルーターはDHCPV6リレー機能を実装し、[RFC8987]で定義されている要件を満たす必要があります。特に、[RFC8987]のセクション4.2に従って、最初のホップルーターは、クライアントに委任されたすべての接頭辞を含むローカルルーティングテーブルを維持する必要があります。
With the first-hop routers performing DHCPv6 relay functions, the proposed design neither requires any subsequent relays in the path nor introduces any requirements (e.g., snooping) for such subsequent relays, if they are deployed.
最初のホップルーターがDHCPV6リレー機能を実行するため、提案された設計では、パスで後続のリレーを必要とせず、展開されている場合、そのような後続のリレーの要件（例えば、スヌーピング）も導入しません。
To ensure that routes to the delegated prefixes are preserved even if a relay is rebooted or replaced, the operator MUST ensure that all relays in the network infrastructure support DHCPv6 Bulk Leasequery as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists keeping active prefix delegations in persistent storage as an alternative to DHCPv6 Bulk Leasequery, relying on persistent storage has the following drawbacks:
リレーが再起動または交換されていても、委任されたプレフィックスへのルートが保存されるようにするには、オペレーターは[RFC5460]で定義されているように、ネットワークインフラストラクチャ内のすべてのリレーがDHCPV6バルクリースクエリをサポートすることを確認する必要があります。[RFC8987]のセクション4.3には、DHCPV6バルクリースクリーに代わるものとして、アクティブなプレフィックス代表団を永続的なストレージに保持することを示していますが、永続的なストレージに依存することには次のような欠点があります。
* In a network with multiple relays, network state can change significantly while the relay is rebooting (new prefixes might be delegated or some prefixes might be expiring, etc).
* 複数のリレーを備えたネットワークでは、リレーが再起動している間、ネットワーク状態が大幅に変化する可能性があります（新しいプレフィックスが委任されるか、一部のプレフィックスが期限切れになっている可能性があります）。
* Persistent storage might not be preserved if the router is physically replaced.
* ルーターが物理的に交換されている場合、永続的なストレージは保存されない場合があります。
Another mechanism for first-hop routers to obtain information about delegated prefixes is by using Active Leasequery [RFC7653], though this is not yet widely supported.
委任されたプレフィックスに関する情報を取得するための最初のホップルーターのもう1つのメカニズムは、アクティブリースクリー[RFC7653]を使用することですが、これはまだ広くサポートされていません。
In a topology with redundant first-hop routers, all the routers need to relay DHCPv6 traffic, install the delegated prefixes into their routing tables and, if needed, advertise those prefixes to the network.
冗長な最初のホップルーターを備えたトポロジでは、すべてのルーターがDHCPV6トラフィックを中継し、委任されたプレフィックスをルーティングテーブルに取り付け、必要に応じてそれらのプレフィックスをネットワークに宣伝する必要があります。
If the first-hop routers obtain information about delegated prefixes by snooping DHCPv6 Reply messages sent by the server, then all the first-hop routers must be able to snoop these messages. This is possible if the client multicasts the DHCPv6 messages it sends to the server. The server will receive one copy of the client message through each first-hop relay, and will reply unicast to each of them via the relay (or chain of relays) from which it received the message. Thus, all first-hop relays will be able to snoop the replies. Per Section 14 of [RFC8415], clients always use multicast unless the server uses the Server Unicast option to explicitly allow unicast communication ([RFC8415], Section 21.12). Therefore, in topologies with multiple first-hop routers, the DHCPv6 servers MUST be configured not to use the Server Unicast option. It should be noted that [RFC8415bis] deprecates the Server Unicast option precisely because it is not compatible with topologies with multiple first-hop relays.
ファーストホップルーターがサーバーから送信されたDHCPV6応答メッセージをスヌーピングして委任されたプレフィックスに関する情報を取得した場合、すべての最初のホップルーターはこれらのメッセージをスヌープできる必要があります。これは、クライアントがサーバーに送信するDHCPV6メッセージをマルチキャストする場合に可能です。サーバーは、各ファーストホップリレーを介してクライアントメッセージの1つのコピーを受け取り、メッセージを受け取ったリレー（またはリレーのチェーン）を介して各ユニキャストに応答します。したがって、すべての最初のホップリレーは、返信をスヌープできます。[RFC8415]のセクション14ごとに、サーバーがサーバーユニキャストオプションを使用してユニキャスト通信を明示的に許可しない限り、クライアントは常にマルチキャストを使用します（[RFC8415]、セクション21.12）。したがって、複数の最初のホップルーターを備えたトポロジでは、DHCPV6サーバーをサーバーユニキャストオプションを使用しないように構成する必要があります。[RFC8415BIS]は、複数のファーストホップリレーを持つトポロジーと互換性がないため、サーバーユニキャストオプションを正確に廃止することに注意する必要があります。
To recover from crashes or reboots, relays can use Bulk Leasequery or Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the other relay(s), as configured by the operator. Additionally, some vendors provide vendor-specific mechanisms to synchronize state between DHCP relays.
クラッシュまたは再起動から回復するために、リレーは、オペレーターによって構成されているように、他のリレーのIDを使用して、バルクリースクリーまたはアクティブなリースクリーを使用してquery_by_relay_idを発行できます。さらに、一部のベンダーは、DHCPリレー間で状態を同期するためのベンダー固有のメカニズムを提供します。
For security reasons, some networks block on-link device-to-device traffic at Layer 2 to prevent communication between clients on the same link. In this case, delegating a prefix to each client doesn't affect traffic flows, as all traffic is sent to the first-hop router anyway. Depending on the network security policy, the router may allow or drop the traffic.
セキュリティ上の理由から、一部のネットワークは、レイヤー2のリンクオンデバイスからデバイスへのトラフィックをブロックして、同じリンク上のクライアント間の通信を防ぎます。この場合、すべてのトラフィックがとにかく最初のホップルーターに送信されるため、各クライアントにプレフィックスを委任することはトラフィックフローに影響しません。ネットワークセキュリティポリシーに応じて、ルーターはトラフィックを許可またはドロップする場合があります。
If the network does allow peer-to-peer communication, the PIO for the on-link prefix is usually advertised with the L-bit set to 1 [RFC4861]. As a result, all addresses from that prefix are considered on-link, and traffic to those destinations is sent directly (not via routers). If such a network delegates prefixes to clients (as described in this document), then each client will consider other client's destination addresses to be off-link, because those addresses are from the delegated prefixes and are no longer within the on-link prefix. When a client sends traffic to another client, packets will initially be sent to the default router. The router will respond with an ICMPv6 redirect message (Section 4.5 of [RFC4861]). If the client receives and accepts the redirect, then traffic can flow directly from device to device. Therefore, the administrator deploying the solution described in this document SHOULD ensure that the first-hop routers can send ICMPv6 redirects (the routers are configured to do so and the security policies permit those messages).
ネットワークがピアツーピア通信を許可している場合、オンリンクプレフィックス用のPIOは通常、1 [RFC4861]に設定されたLビットで宣伝されます。その結果、そのプレフィックスからのすべてのアドレスはリンクで見なされ、それらの宛先へのトラフィックは直接送信されます（ルーターを介してではありません）。このようなネットワークがクライアントにプレフィックスを委任する場合（このドキュメントで説明されているように）、各クライアントは他のクライアントの宛先アドレスがリンクオフと見なされます。これらのアドレスは委任されたプレフィックスからであり、リンクオンレフィックス内にないためです。クライアントがトラフィックを別のクライアントに送信すると、パケットは最初にデフォルトのルーターに送信されます。ルーターは、ICMPV6リダイレクトメッセージ（[RFC4861]のセクション4.5）で応答します。クライアントがリダイレクトを受信して受け入れると、トラフィックはデバイスからデバイスに直接流れる可能性があります。したがって、このドキュメントに記載されているソリューションを展開する管理者は、最初のホップルーターがICMPV6リダイレクトを送信できるようにする必要があります（ルーターはそうするように設定され、セキュリティポリシーはそれらのメッセージを許可します）。
This document does not introduce any changes to the DHCPv6 protocol itself. However, for the proposed solution to work correctly, the DHCPv6-PD server needs to be configured as follows:
このドキュメントでは、DHCPV6プロトコル自体に変更が導入されません。ただし、提案されたソリューションが正しく機能するには、DHCPV6-PDサーバーを次のように構成する必要があります。
* The server MUST follow recommendations from [RFC8168] on processing prefix-length hints.
* サーバーは、プレフィックス長のヒントを処理する際に[RFC8168]の推奨事項に従う必要があります。
* The server MUST provide a prefix short enough for the client to extend the network to at least one interface and allow nodes on that interface to obtain addresses via SLAAC. The server MAY provide more address space to clients that ask for it, either by delegating multiple such prefixes, or by delegating a single prefix of a shorter length. It should be noted that [RFC8168] allows the server to provide a prefix shorter than the prefix-length hint value received from the client.
* サーバーは、クライアントがネットワークを少なくとも1つのインターフェイスに拡張し、そのインターフェイス上のノードをSLAAC経由でアドレスを取得できるようにするのに十分な短いプレフィックスを提供する必要があります。サーバーは、複数のそのようなプレフィックスを委任するか、より短い長さの単一のプレフィックスを委任することにより、それを要求するクライアントにより多くのアドレススペースを提供する場合があります。[RFC8168]により、サーバーは、クライアントから受信したプレフィックス長ヒント値よりも短いプレフィックスを提供できるようにすることに注意してください。
* If the server receives the same Solicit message from the same client multiple times through multiple relays, it MUST reply to all of them with the same prefix(es). This ensures that all the relays will correctly configure routes to the delegated prefixes.
* サーバーが複数のリレーを通じて同じクライアントから同じクライアントから同じ勧誘メッセージを受信する場合、同じプレフィックス（ES）を使用してすべてのリレーに返信する必要があります。これにより、すべてのリレーが委任されたプレフィックスへのルートを正しく構成することが保証されます。
* The server MUST NOT send the Server Unicast option to the client unless the network topology guarantees that no client is connected to a link with multiple relays (see Section 6.3).
* ネットワークトポロジが複数のリレーでクライアントがリンクに接続されていないことを保証しない限り、サーバーはサーバーユニキャストオプションをクライアントに送信してはなりません（セクション6.3を参照）。
* In order to ensure uninterrupted connectivity when a first-hop router crashes or reboots, the server MUST support Bulk Leasequery or Active Leasequery.
* 最初のホップルーターがクラッシュまたは再起動するときに途切れない接続を確保するために、サーバーはバルクリースクリーまたはアクティブなリースクリーをサポートする必要があります。
As most operators have some experience with IPv4, they can use a similar approach for choosing the pool size and the timers (such as T1 and T2 timers). In particular, the following factors should be taken into account:
ほとんどのオペレーターはIPv4の経験があるため、プールサイズとタイマー（T1やT2タイマーなど）を選択するために同様のアプローチを使用できます。特に、次の要因を考慮する必要があります。
* the expected maximum number of clients;
* 予想される最大クライアント。
* the average duration of client connections;
* クライアント接続の平均期間。
* how mobile the clients are (a network where all clients are connected to a single wired VLAN might choose longer timers than a network where clients can switch between multiple wireless networks);
* クライアントのモバイル（すべてのクライアントが単一の有線VLANに接続されているネットワークは、クライアントが複数のワイヤレスネットワークを切り替えることができるネットワークよりも長いタイマーを選択できます）。
* how often clients are expected to reconnect to the network (for example, a corporate authenticated Wi-Fi network might be using longer timers than an open public Wi-Fi).
* クライアントがネットワークに再接続することが期待される頻度（たとえば、企業の認証されたWi-Fiネットワークは、公開されている公開Wi-Fiよりも長いタイマーを使用している可能性があります）。
DHCPv6 servers that delegate prefixes can interface with Dynamic DNS infrastructure to automatically populate reverse DNS using wildcard records, similarly to what is described in Section 2.2 of [RFC8501]. Networks that also wish to populate forward DNS cannot do so automatically based only on DHCPv6 prefix delegation transactions, but they can do so in other ways, such as by supporting DHCPv6 address registration as described in [ADDR-NOTIFICATION].
プレフィックスを委任するDHCPV6サーバーは、[RFC8501]のセクション2.2で説明されているものと同様に、ワイルドカードレコードを使用して逆DNSを自動的に設定するために、動的DNSインフラストラクチャとインターフェイスできます。また、フォワードDNSの設定を希望するネットワークは、DHCPV6プレフィックス委任トランザクションのみに基づいて自動的に行うことはできませんが、[addr-notification]に記載されているDHCPV6アドレス登録をサポートするなど、他の方法でそうすることができます。
Some additional recommendations driven by security and privacy considerations are discussed in Section 15 and Section 13.
セキュリティとプライバシーの考慮事項によって推進されるいくつかの追加の推奨事項については、セクション15およびセクション13で説明します。
Delegating a prefix of sufficient size to use SLAAC allows the client to extend the network, providing limitless addresses to IPv6 nodes connected to it (e.g., virtual machines or tethered devices), because all IPv6 hosts are required to support SLAAC [RFC8504]. Additionally, even clients that support other forms of address assignment require SLAAC for some functions, such as forming dedicated addresses for the use of 464XLAT (see Section 6.3 of [RFC6877]).
SLAACを使用するのに十分なサイズの接頭辞を委任すると、クライアントはネットワークを拡張でき、すべてのIPv6ホストがSLAAC [RFC8504]をサポートする必要があるため、それに接続されたIPv6ノード（仮想マシンやテザーデバイスなど）に無限のアドレスを提供できます。さらに、他の形式のアドレス割り当てをサポートするクライアントでさえ、464xLatを使用するための専用アドレスを形成するなど、いくつかの機能にSLAACが必要です（[RFC6877]のセクション6.3を参照）。
At the time of writing, the only prefix size that will allow devices to use SLAAC is 64 bits. Also, as noted in [RFC7421], using an interface identifier (IID) shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications. Choosing longer prefixes would require the client and any connected system to use other address assignment mechanisms. This would limit the applicability of the proposed solution, as other mechanisms are not currently supported by many hosts.
執筆時点では、デバイスがSLAACを使用できるようにする唯一のプレフィックスサイズは64ビットです。また、[RFC7421]に記載されているように、インターフェイス識別子（IID）を64ビットより短く使用して、64ビットより長いサブネットプレフィックスは現在のIPv6仕様の外側にあります。より長いプレフィックスを選択するには、クライアントと接続されたシステムが他のアドレス割り当てメカニズムを使用する必要があります。他のメカニズムは現在多くのホストによってサポートされていないため、これにより提案されたソリューションの適用性が制限されます。
For the same reasons, a prefix length of /64 or shorter is required to extend the network as described in [RFC7084] (see requirement L-2), and a prefix length of /64 is required to provide global connectivity for stub networks as per [SNAC-SIMPLE].
同じ理由で、[RFC7084]に記載されているようにネットワークを拡張するには、 /64以下のプレフィックスの長さが必要です（要件L-2を参照）。[SNAC-SIMPLE]ごと。
Assigning a prefix of sufficient size to support SLAAC is possible on large networks. In general, any network that numbers clients from an IPv4 prefix of length X (e.g., X=/18, X=/24) would require an IPv6 prefix of length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to every device. As an example, Section 9.2 of [RFC7934] suggests that even a very large network that assigns every single one of the 16 million IPv4 addresses in 10.0.0.0/8 would only need an IPv6 /40. A /40 prefix is a small amount of address space: there are 32 times more /40s in the current IPv6 unicast range 2000::/3 than there are IPv4 addresses. Existing sites that currently use a /48 prefix cannot support more than 64k clients in this model without renumbering, though many networks of such size have Local Internet Registry (LIR) status and can justify bigger address blocks.
SLAACをサポートするのに十分なサイズのプレフィックスを割り当てることは、大規模なネットワークで可能です。一般に、長さxのIPv4プレフィックス（x =/18、x =/24）のIPv4プレフィックスからクライアントを数字するネットワークには、長さx+32のIPv6プレフィックスが必要です（x =/40、x =/56）すべてのデバイスにA /64プレフィックスを提供します。例として、[RFC7934]のセクション9.2は、10.0.0.0/8の1600万のIPv4アドレスのすべてを割り当てる非常に大きなネットワークでさえ、IPv6 /40のみが必要であることを示唆しています。A /40プレフィックスは、少量のアドレススペースです。現在のIPv6ユニキャスト範囲2000 :: /3には、IPv4アドレスの32倍 /40倍 /40があります。現在A /48のプレフィックスを使用している既存のサイトは、このモデルでは64Kを超えるクライアントをサポートできませんが、このようなサイズの多くのネットワークにはローカルインターネットレジストリ（LIR）ステータスがあり、より大きなアドレスブロックを正当化できます。
Note that assigning a prefix of sufficient size to support SLAAC does not require that subtended nodes use SLAAC; they can use other address assignment mechanisms as well.
SLAACをサポートするために十分なサイズのプレフィックスを割り当てるには、抑制されたノードがSLAACを使用する必要はないことに注意してください。他のアドレス割り当てメカニズムも使用できます。
As per Section 18.2.12 of [RFC8415], when the client moves to a new link, it MUST initiate a Rebind/Reply message exchange. Therefore, when the client moves between network attachment points, it would refresh its delegated prefix the same way it refreshes addresses assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:
[RFC8415]のセクション18.2.12によると、クライアントが新しいリンクに移動すると、Rebind/Replyメッセージの交換を開始する必要があります。したがって、クライアントがネットワークアタッチメントポイント間を移動すると、共有オンリンクプレフィックスから（SLAACまたはDHCPV6 IA_NAを介して）割り当てられたアドレスを再表示するのと同じ方法で委任されたプレフィックスを更新します。
* When a client moves from between different attachment points on the same link (e.g., roams between two APs while connected to the same wireless network or moves between two switchports belonging to the same VLAN), the delegated prefix does not change, and the first-hop routers have a route for the prefix with the nexthop set to the client link-local address on that link. As per requirement S-2 in Section 4.3 of [RFC8987], the DHCPv6-relays (the first-hop routers) MUST retain the route for the delegating prefix until the route is released or removed due to expiring DHCP timers. Therefore, if the client reconnects to the same link, the prefix doesn't change.
* クライアントが同じリンク上の異なる添付ファイルポイントの間から移動すると（たとえば、同じワイヤレスネットワークに接続しているときに2つのAP間を回転したり、同じVLANに属する2つのスイッチポート間で移動したり）、委任されたプレフィックスは変更されず、ファースト -ホップルーターには、そのリンク上のクライアントリンクローカルアドレスにNexthopセットが設定されたプレフィックスのルートがあります。[RFC8987]のセクション4.3の要件S-2に従って、DHCPV6-RELAYS（最初のホップルーター）は、DHCPタイマーの期限が切れるため、ルートが解放または削除されるまで、委任プレフィックスのルートを保持する必要があります。したがって、クライアントが同じリンクに再接続する場合、プレフィックスは変更されません。
* When a client moves to a different link, the DHCPv6 server provides the client with a new prefix, so the behavior is consistent with SLAAC or DHCPv6-assigned addresses, which are also different on the new link.
* クライアントが別のリンクに移動すると、DHCPV6サーバーはクライアントに新しいプレフィックスを提供するため、動作はSLAACまたはDHCPV6が割り当てられたアドレスと一致します。これは、新しいリンクでも異なります。
In theory, DHCPv6 servers can delegate the same prefix to the same client even if the client changes the attachment points. However, while allowing the client to keep the same prefix while roaming between links might provide some benefits for the client, it is not feasible without changing DHCPv6 relay behavior: after the client moves to a new link, the DHCPv6 relays would retain the route pointing to the client's link-local address on the old link for the duration of DHCPv6 timers (see requirement S-2, Section 4.3 of [RFC8987]). As a result, the first-hop routers would have two routes for the same prefix pointing to different links, causing connectivity issues for the client.
理論的には、DHCPV6サーバーは、クライアントが添付ポイントを変更しても、同じプレフィックスを同じクライアントに委任できます。ただし、リンク間をローミング中にクライアントが同じプレフィックスを保持できるようにすると、クライアントに何らかの利点が得られる可能性がありますが、DHCPV6リレーの動作を変更せずに実行可能ではありません。クライアントが新しいリンクに移動した後、DHCPV6リレーはルートポイントを保持します。DHCPV6タイマーの期間中、古いリンクのクライアントのリンクローカルアドレスに（[RFC8987]の要件S-2、セクション4.3を参照）。その結果、最初のホップルーターには、異なるリンクを指すのと同じプレフィックスの2つのルートがあり、クライアントに接続性の問題を引き起こします。
It should be noted that addressing clients from a shared on-link prefix also does not allow clients to keep addresses while roaming between links, so the proposed solution is not different in that regard. In addition to that, different links often have different security policies applied (for example, corporate internal networks versus guest networks), hence clients on different links need to use different prefixes.
共有されたリンクプレフィックスからクライアントにアドレス指定することで、クライアントがリンク間をローミングしながらアドレスを維持することも許可されていないため、提案されたソリューションはその点で違いはありません。それに加えて、さまざまなリンクに異なるセキュリティポリシーが適用されることがよくあります（たとえば、企業の内部ネットワークとゲストネットワークなど）。したがって、異なるリンクのクライアントは、異なるプレフィックスを使用する必要があります。
Enabling unicast Reverse Path Forwarding (uRPF) [RFC3704] on the first-hop router interfaces towards clients provides the first layer of defense against spoofing. A spoofed packet sent by a malicious client would be dropped by the router unless the spoofed address belongs to a prefix delegated to another client on the same interface. Therefore the malicious client can only spoof addresses already delegated to another client on the same link or another client's link-local address.
ユニキャストリバースパス転送（URPF）[RFC3704]を最初のホップルーターインターフェイスでクライアントに向けて有効にすると、スプーフィングに対する防御の最初の層が得られます。スプーフィングされたアドレスが同じインターフェイスで別のクライアントに委任された接頭辞に属していない限り、悪意のあるクライアントから送信されたスプーフィングされたパケットは、ルーターによってドロップされます。したがって、悪意のあるクライアントは、同じリンクまたは別のクライアントのリンクローカルアドレスで既に別のクライアントに委任されたアドレスのみをスプーフィングすることができます。
Source Address Validation Improvement (SAVI) [RFC7039] provides more reliable protection against address spoofing. Administrators deploying the proposed solution on SAVI-enabled infrastructure SHOULD ensure that SAVI perimeter devices support DHCPv6-PD snooping to create the correct binding for the delegated prefixes (see [RFC7513]). Using FCFS SAVI [RFC6620] to protect link-local addresses and create SAVI bindings for DHCPv6-PD assigned prefixes would prevent spoofing.
ソースアドレスの検証改善（SAVI）[RFC7039]は、住所のスプーフィングに対するより信頼性の高い保護を提供します。SAVI対応インフラストラクチャに提案されたソリューションを展開する管理者は、SAVI境界デバイスがDHCPV6-PDスヌーピングをサポートして、委任されたプレフィックスの正しいバインディングを作成できるようにする必要があります（[RFC7513を参照]）。FCFS Savi [RFC6620]を使用して、Link-Localアドレスを保護し、DHCPV6-PDに割り当てられたプレフィックスのSAVIバインディングを作成すると、スプーフィングが防止されます。
Some infrastructure devices do not implement SAVI as defined in [RFC7039]; instead, they perform other forms of address tracking and snooping for security or performance improvement purposes (e.g., ND proxy). This is very common behavior for wireless devices (such as access points and controllers). Administrators SHOULD ensure that such devices are able to snoop DHCPv6-PD packets so the traffic from the delegated prefixes is not dropped.
一部のインフラストラクチャデバイスは、[RFC7039]で定義されているようにSAVIを実装していません。代わりに、セキュリティまたはパフォーマンスの改善の目的（NDプロキシなど）のために、他の形式のアドレストラッキングとスヌーピングを実行します。これは、ワイヤレスデバイス（アクセスポイントやコントローラーなど）の非常に一般的な動作です。管理者は、そのようなデバイスがDHCPV6-PDパケットをスヌープできるようにして、委任されたプレフィックスからのトラフィックが削除されないようにする必要があります。
It should be noted that using DHCPv6-PD makes it harder for an attacker to select the spoofed source address. When all clients are using the same shared link to form addresses, the attacker might learn addresses used by other clients by listening to multicast Neighbor Solicitations and Neighbor Advertisements. In DHCPv6-PD environments, however, the attacker can only learn about other clients' global addresses by listening to multicast DHCPv6 messages, which are not transmitted so often, and may not be received by the client at all because they are sent to multicast groups that are specific to DHCPv6 servers and relays.
DHCPV6-PDを使用すると、攻撃者がスプーフィングされたソースアドレスを選択することが難しくなることに注意してください。すべてのクライアントが同じ共有リンクを使用してアドレスをフォームに使用している場合、攻撃者は、マルチキャストの隣人の勧誘と近隣広告を聞くことで、他のクライアントが使用するアドレスを学ぶことができます。ただし、DHCPV6-PD環境では、攻撃者は、頻繁に送信されず、マルチキャストグループに送信されるためクライアントがまったく受信できないマルチキャストDHCPV6メッセージを聞くことによって、他のクライアントのグローバルアドレスについてのみ学習できます。これは、DHCPV6サーバーとリレーに固有です。
It would be beneficial for the network to explicitly indicate its support of DHCPv6-PD for connected clients.
ネットワークが、接続されたクライアントに対するDHCPV6-PDのサポートを明示的に示すことが有益です。
* In small networks (e.g., home networks), where the number of clients is not too high, the number of available prefixes becomes a limiting factor. If every phone or laptop in a home network were to request a unique prefix suitable for SLAAC, the home network might run out of prefixes, if the prefix allocated to the Customer Premises Equipment (CPE) by its ISP is too long. For example, if an ISP delegates a /60, the CPE would only be able to delegate fifteen /64 prefixes to clients. So while the enterprise network administrator might want all phones in the network to request a prefix, it would be highly undesirable for the same phone to request a prefix when connecting to a home network.
* クライアントの数が高すぎない小さなネットワーク（ホームネットワークなど）では、利用可能なプレフィックスの数が制限要因になります。ホームネットワーク内のすべての電話またはラップトップがSLAACに適した一意のプレフィックスを要求する場合、ISPによって顧客施設機器（CPE）に割り当てられた接頭辞が長すぎる場合、ホームネットワークはプレフィックスが不足している可能性があります。たとえば、ISPがA /60を代表する場合、CPEは15 /64のプレフィックスをクライアントに委任することができます。したがって、エンタープライズネットワーク管理者は、ネットワーク内のすべての電話にプレフィックスを要求することを望むかもしれませんが、同じ電話がホームネットワークに接続するときにプレフィックスを要求することは非常に望ましくありません。
* When the network supports both a unique prefix per client and a PIO with A=1 as address assignment methods, it's highly desirable for the client NOT to use the PIO prefix to form global addresses and instead only use the prefix delegated via DHCPv6-PD. Starting both SLAAC using the PIO prefix and DHCPv6-PD, and then deprecating the SLAAC addresses after receiving a delegated prefix would be very disruptive for applications. If the client continues to use addresses formed from the PIO prefix, it would not only undermine the benefits of the proposed solution (see Section 12), but it would also introduce complexity and unpredictability in the source address selection. Therefore, the client needs to know what address assignment method to use and whether or not to use the prefix in the PIO, if the network provides the PIO with the 'A' flag set.
* ネットワークがクライアントごとの一意のプレフィックスとアドレス割り当て方法としてA = 1のPIOの両方をサポートする場合、クライアントがPIOプレフィックスを使用してグローバルアドレスを形成しないことが非常に望ましい場合、代わりにDHCPV6-PDを介して委任されたプレフィックスを使用します。PIOプレフィックスとDHCPV6-PDを使用してSLAACの両方を起動し、委任されたプレフィックスを受信した後にSLAACアドレスを非難することは、アプリケーションにとって非常に破壊的です。クライアントがPIOプレフィックスから形成されたアドレスを引き続き使用している場合、提案されたソリューションの利点を損なうだけでなく（セクション12を参照）、ソースアドレスの選択に複雑さと予測不可能性も導入します。したがって、ネットワークに「A」フラグセットをPIOに提供する場合、クライアントは、使用するアドレス割り当て方法とPIOでプレフィックスを使用するかどうかを知る必要があります。
The deployment model described in this document does not require the network to signal support of DHCPv6-PD: for example, devices acting as compatible routers [RFC7084] will be able to receive prefixes via DHCPv6-PD even without such signaling. Also, some clients may decide to start DHCPv6-PD and acquire prefixes if they detect that the network does not provide addresses via SLAAC. To fully achieve the benefits described in this section, [PIO-PFLAG] defines a new PIO flag to signal that DHCPv6-PD is the preferred method of obtaining prefixes.
このドキュメントで説明されている展開モデルは、ネットワークがDHCPV6-PDのサポートを信号する必要はありません。たとえば、互換性のあるルーターとして機能するデバイス[RFC7084]は、そのようなシグナル伝達がなくてもDHCPV6-PDを介してプレフィックスを受信できます。また、一部のクライアントは、DHCPV6-PDを起動し、ネットワークがSLAACを介してアドレスを提供していないことを検出した場合、プレフィックスを取得することを決定する場合があります。このセクションで説明されている利点を完全に達成するために、[PIO-PFLAG]は、DHCPV6-PDがプレフィックスを取得する優先方法であることを示す新しいPIOフラグを定義します。
The proposed solution provides the following benefits:
提案されたソリューションは、次の利点を提供します。
* Network device resources (e.g., memory) need to scale to the number of devices, not the number of IPv6 addresses. The first-hop routers have a single route per device pointing to the device's link-local address. This can potentially enable hardware cost savings; for example, if hardware such as wireless LAN controllers is limited to supporting only a specific number of client addresses, or in VXLAN deployments where each client address consumes one routing table entry.
* ネットワークデバイスリソース（メモリなど）は、IPv6アドレスの数ではなく、デバイスの数にスケーリングする必要があります。ファーストホップルーターには、デバイスのリンクローカルアドレスを指すデバイスごとに単一のルートがあります。これにより、ハードウェアのコスト削減が可能になる可能性があります。たとえば、ワイヤレスLANコントローラーなどのハードウェアが、特定の数のクライアントアドレスのみをサポートすることに制限されている場合、または各クライアントアドレスが1つのルーティングテーブルエントリを消費するVXLAN展開に限定されている場合。
* The cost of having multiple addresses is offloaded to the clients. Hosts are free to create and use as many addresses as they need without imposing any additional costs onto the network.
* 複数のアドレスを持つコストは、クライアントにオフロードされます。ホストは、ネットワークに追加コストを課すことなく、必要な数のアドレスを無料で作成および使用できます。
* If all clients connected to the given link support this mode of operation and can generate addresses from the delegated prefixes, there is no reason to advertise a common prefix assigned to that link in the PIO with the 'A' flag set. Therefore, it is possible to remove the global shared prefix from that link and the router interface completely, so no global addresses are on-link for the link. This would lead to reducing the attack surface for Neighbor Discovery attacks described in [RFC6583].
* 指定されたリンクに接続されているすべてのクライアントがこの動作モードをサポートし、委任されたプレフィックスからアドレスを生成できる場合、PIOのリンクに割り当てられた共通のプレフィックスを「A」フラグセットで宣伝する理由はありません。したがって、そのリンクとルーターインターフェイスからグローバル共有プレフィックスを完全に削除することができるため、リンクにはグローバルアドレスがオンになりません。これにより、[RFC6583]に記載されている隣接発見攻撃の攻撃面を減らすことになります。
* DHCPv6-PD logs and routing tables obtained from first-hop routers provide complete information on IPv6 to MAC mapping, which can be used for forensics and troubleshooting. Such information is much less dynamic than the ND cache; therefore, it's much easier for an operator to collect and process it.
* 最初のホップルーターから取得したDHCPV6-PDログとルーティングテーブルは、IPv6からMacマッピングに関する完全な情報を提供します。これは、フォレンジックとトラブルシューティングに使用できます。このような情報は、NDキャッシュよりもはるかに動的ではありません。したがって、オペレーターがそれを収集して処理するのははるかに簡単です。
* A dedicated prefix per client allows the network administrator to create security policies per device (such as ACLs) even if the client is using temporary addresses. This mitigates one of the issues described in [IPv6-ADDRESS].
* クライアントごとに専用のプレフィックスを使用すると、ネットワーク管理者は、クライアントが一時アドレスを使用している場合でも、デバイスごと（ACLなど）ごとにセキュリティポリシーを作成できます。これにより、[IPv6-Address]で説明されている問題の1つが軽減されます。
* Fate sharing: all global addresses used by a given client are routed as a single prefix. Either all of them work or none of them work, which makes failures easier to diagnose and mitigate.
* 運命の共有：特定のクライアントが使用するすべてのグローバルアドレスは、単一のプレフィックスとしてルーティングされます。それらのすべてが機能するか、それらのどれも機能しないため、失敗は診断と軽減が容易になります。
* Lower level of multicast traffic: less Neighbor Discovery [RFC4861] multicast packets, as the routers need to resolve only the clients' link-local addresses. Also, there is no Duplicate Address Detection (DAD) traffic except for the clients' link-local addresses.
* マルチキャストトラフィックの低いレベル：近隣の発見が少ない[RFC4861]マルチキャストパケット。ルーターは、クライアントのリンクローカルアドレスのみを解決する必要があるためです。また、クライアントのLink-Localアドレスを除いて、重複するアドレス検出（DAD）トラフィックはありません。
* Ability to extend the network transparently. If the network delegates to the client a prefix of sufficient size to support SLAAC, the client can provide connectivity to other hosts, as is possible in IPv4 with NAT (e.g., by acting as an IPv6 Customer Edge (CE) router as described in [RFC7084]).
* ネットワークを透過的に拡張する能力。ネットワークがSLAACをサポートするのに十分なサイズの接頭辞をクライアントに委任する場合、クライアントは他のホストに接続することができます。RFC7084]）。
If an eavesdropper or information collector is aware that a given client is using the proposed mechanism, then they may be able to track the client based on its prefix. The privacy implications of this are equivalent to the privacy implications of networks using stateful DHCPv6 address assignment: in both cases, the IPv6 addresses are determined by the server, either because the server assigns a full 128-bit address in a shared prefix, or because the server determines what prefix is delegated to the client. Administrators deploying the proposed mechanism can use similar methods to mitigate the impact as the ones used today in networks that use stateful DHCPv6 address assignment.
盗聴者または情報コレクターが特定のクライアントが提案されたメカニズムを使用していることを認識している場合、そのプレフィックスに基づいてクライアントを追跡できる可能性があります。これのプライバシーへの影響は、Stateful DHCPV6アドレスの割り当てを使用したネットワークのプライバシーへの影響に相当します。どちらの場合も、IPv6アドレスはサーバーによって決定されます。サーバーは、どのプレフィックスがクライアントに委任されるかを決定します。提案されたメカニズムを展開する管理者は、同様の方法を使用して、Stateful DHCPV6アドレスの割り当てを使用するネットワークで今日使用されているものと同様の方法を軽減できます。
Except for networks (such as datacenter networks) where hosts do not need temporary addresses [RFC8981], the network SHOULD:
ホストが一時的なアドレスを必要としないネットワーク（データセンターネットワークなど）を除き[RFC8981]、ネットワークは次のようにする必要があります。
* Ensure that when a client requests a prefix, the prefix is randomly assigned and not allocated deterministically.
* クライアントがプレフィックスを要求したときに、プレフィックスがランダムに割り当てられ、決定論的に割り当てられていないことを確認します。
* Use short prefix lifetimes (e.g., hours) to ensure that when a client disconnects and reconnects it gets a different prefix.
* 短いプレフィックスの寿命（時間など）を使用して、クライアントが別の接頭辞を切断して再接続すると、別のプレフィックスが取得されるようにします。
* Allow the client to have more than one prefix at the same time. This allows the client to rotate prefixes using a mechanism similar to temporary addresses, but that operates on prefixes instead of on individual addresses. In this case, the prefix's lifetime MUST be short enough to allow the client to use a reasonable rotation interval without using too much address space. For example, if every 24 hours the client asks for a new prefix and stops renewing the old prefix, and the Valid Lifetime of delegated prefixes is one hour, then the client will consume two prefixes for one hour out of 24 hours, and thus will consume just under 1.05 prefixes on average.
* クライアントが同時に複数のプレフィックスを持つようにします。これにより、クライアントは一時的なアドレスと同様のメカニズムを使用してプレフィックスを回転させることができますが、個々のアドレスではなくプレフィックスで動作します。この場合、接頭辞の寿命は、クライアントがアドレススペースをあまり使用せずに合理的な回転間隔を使用できるようにするのに十分な短い必要があります。たとえば、24時間ごとにクライアントが新しいプレフィックスを要求し、古いプレフィックスの更新を停止し、委任されたプレフィックスの有効な寿命が1時間である場合、クライアントは24時間のうち1時間で2つのプレフィックスを消費します。平均で1.05以下の接頭辞を消費します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
A malicious (or just misbehaving) client might attempt to exhaust the DHCPv6-PD pool by sending a large number of requests with differing DHCP Unique Identifiers (DUIDs). To prevent a misbehaving client from denying service to other clients, the DHCPv6 server or relay MUST support limiting the number of prefixes delegated to a given client at any given time.
悪意のある（または単に不正な）クライアントは、DHCP一意の識別子が異なる多数の要求（DUID）を送信することにより、DHCPV6-PDプールを排出しようとする場合があります。誤動作するクライアントが他のクライアントへのサービスを拒否するのを防ぐために、DHCPV6サーバーまたはリレーは、特定のクライアントに委任されたプレフィックスの数をいつでも制限することをサポートする必要があります。
Networks can protect against malicious clients by authenticating devices using tokens that cannot be spoofed (e.g., 802.1x authentication) and limiting the number of link-local addresses or MAC addresses that each client is allowed to use. Note that this is not a new issue, as the same attack might be implemented using DHCPv4 or DHCPv6 IA_NA requests; in particular, while it is unlikely for clients to be able to exhaust an IA_NA address pool, clients using IA_NA can exhaust other resources such as DHCPv6 and routing infrastructure resources such as server RAM, ND cache entries, Ternary Content-Addressable Memory (TCAM) entries, SAVI entries, etc.
ネットワークは、スプーフィングできないトークン（802.1x認証など）を使用してデバイスを認証し、各クライアントが使用できるLink-LocalアドレスまたはMACアドレスの数を制限することにより、悪意のあるクライアントから保護できます。同じ攻撃がDHCPV4またはDHCPV6 IA_NA要求を使用して実装される可能性があるため、これは新しい問題ではないことに注意してください。特に、クライアントがIA_NAアドレスプールを使い果たすことはほとんどありませんが、IA_NAを使用してクライアントはDHCPV6やサーバーRAM、ndキャッシュエントリ、3次コンテンツアドレス可能なメモリ（TCAM）などのルーティングインフラストラクチャリソースなどの他のリソースを使い果たすことができます。エントリ、サビエントリなど
A malicious client might request a prefix and then release it very quickly, causing routing convergence events on the relays. The impact of this attack can be reduced if the network rate-limits the amount of broadcast and multicast messages from the client.
悪意のあるクライアントは、プレフィックスを要求してから非常に迅速にリリースし、リレーでルーティングコンバージェンスイベントを引き起こす場合があります。ネットワークレートがクライアントからのブロードキャストメッセージとマルチキャストメッセージの量を制限すると、この攻撃の影響を減らすことができます。
Delegating the same prefix for the same client introduces privacy concerns. The proposed mitigation is discussed in Section 13.
同じクライアントに同じプレフィックスを委任すると、プライバシーの懸念が導入されます。提案された緩和については、セクション13で説明します。
Spoofing scenarios and prevention mechanisms are discussed in Section 10.
スプーフィングシナリオと予防メカニズムについては、セクション10で説明します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
<https://www.rfc-editor.org/info/rfc8168>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson,
"DHCPv6 Prefix Delegating Relay Requirements", RFC 8987,
DOI 10.17487/RFC8987, February 2021,
<https://www.rfc-editor.org/info/rfc8987>.
[ADDR-NOTIFICATION]
Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova,
J., and S. Jiang, "Registering Self-generated IPv6
Addresses using DHCPv6", Work in Progress, Internet-Draft,
draft-ietf-dhc-addr-notification-13, 16 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
addr-notification-13>.
[IPv6-ADDRESS]
Gont, F. and G. Gont, "Implications of IPv6 Addressing on
Security Operations", Work in Progress, Internet-Draft,
draft-ietf-opsec-ipv6-addressing-00, 2 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ipv6-addressing-00>.
[PIO-PFLAG]
Colitti, L., Linkova, J., Ma, X., and D. Lamparter,
"Signaling DHCPv6 Prefix per Client Availability to
Hosts", Work in Progress, Internet-Draft, draft-ietf-6man-
pio-pflag-11, 4 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
pio-pflag-11>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[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,
<https://www.rfc-editor.org/info/rfc6459>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[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,
<https://www.rfc-editor.org/info/rfc7039>.
[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,
<https://www.rfc-editor.org/info/rfc7278>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[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,
<https://www.rfc-editor.org/info/rfc7421>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
October 2015, <https://www.rfc-editor.org/info/rfc7653>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8415bis]
Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", Work in Progress, Internet-Draft, draft-ietf-
dhc-rfc8415bis-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
rfc8415bis-05>.
[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
<https://www.rfc-editor.org/info/rfc8501>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[SNAC-SIMPLE]
Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-snac-
simple-05>.
While a typical IPv4 host normally has only one IPv4 address per interface, an IPv6 device almost always has multiple addresses assigned to its interface. At the very least, a host can be expected to have one link-local address, one temporary address, and, in most cases, one stable global address. On a network providing NAT64 service, an IPv6-only host running the 464XLAT customer-side translator (CLAT) [RFC6877] would use a dedicated 464XLAT address, configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the total number of addresses to four. Other common scenarios where the number of addresses per host interface might increase significantly include but are not limited to:
通常、典型的なIPv4ホストにはインターフェイスごとに1つのIPv4アドレスしかありませんが、IPv6デバイスにはほとんどの場合、インターフェイスに複数のアドレスが割り当てられています。少なくとも、ホストは、1つのリンクローカルアドレス、1つの一時的なアドレス、およびほとんどの場合、1つの安定したグローバルアドレスを持つことが期待できます。NAT64サービスを提供するネットワークでは、464xLatカスタマーサイド翻訳者（CLAT）[RFC6877]を実行するIPv6のみのホストが、SLAACを介して構成された専用の464xLatアドレスを使用します（[RFC6877]セクション6.3を参照）。4つのアドレスの。ホストインターフェイスごとのアドレスの数が大幅に増加する可能性がある他の一般的なシナリオには、以下が含まれますが、これらに限定されない他のシナリオ
* Devices running containers or namespaces: each container or namespace would have multiple addresses as described above. As a result, a device running just a few containers in a bridge mode can easily have 20 or more IPv6 addresses on the given link.
* コンテナまたは名前空間を実行するデバイス：各コンテナまたは名前空間には、上記のように複数のアドレスがあります。その結果、ブリッジモードでわずかなコンテナを実行するデバイスは、指定されたリンクに20以上のIPv6アドレスを簡単に持つことができます。
* Networks assigning multiple prefixes to a given link: multihomed networks, networks using Unique Local IPv6 Unicast Addresses (ULA, [RFC4193]) and non-ULA prefixes together, or networks performing a graceful renumbering from one prefix to another.
* 複数のプレフィックスを特定のリンクに割り当てるネットワーク：マルチホームネットワーク、一意のローカルIPv6ユニキャストアドレス（ULA、[RFC4193]）を使用したネットワーク、および非ulaのプレフィックス、またはあるプレフィックスから別のプレフィックスに優雅な変更を行うネットワーク。
[RFC7934] discusses this aspect and explicitly states that IPv6 deployments SHOULD NOT limit the number of IPv6 addresses a host can have. However, it has been observed that networks often do limit the number of on-link addresses per device, likely in an attempt to protect network resources and prevent DoS attacks.
[RFC7934]はこの側面について説明し、IPv6の展開はホストが持つことができるIPv6アドレスの数を制限すべきではないことを明示的に述べています。ただし、ネットワークは、ネットワークリソースを保護し、DOS攻撃を防ぐために、デバイスごとのオンリンクアドレスの数を制限することが多いことが観察されています。
The most common scenario of network-imposed limitations is ND proxy. Many enterprise-scale wireless solutions implement ND proxy to reduce the amount of broadcast and multicast downstream (AP to clients) traffic and provide SAVI functions. To perform ND proxy, a device usually maintains a table containing IPv6 and MAC addresses of connected clients. At least some implementations have hardcoded limits on how many IPv6 addresses per single MAC such a table can contain. When the limit is exceeded, the behavior is implementation dependent. Some vendors just fail to install an N+1 address to the table. Others delete the oldest entry for this MAC and replace it with the new address. In any case, the affected addresses lose network connectivity without receiving any implicit signal, with traffic being silently dropped.
ネットワークが課した制限の最も一般的なシナリオは、ndプロキシです。多くのエンタープライズスケールのワイヤレスソリューションは、NDプロキシを実装して、ダウンストリーム（APへのAP）トラフィックの量を減らし、SAVI機能を提供します。NDプロキシを実行するために、デバイスは通常、接続されたクライアントのIPv6とMacアドレスを含むテーブルを維持します。少なくとも一部の実装には、そのようなテーブルが含めることができる単一MacあたりのIPv6アドレスの数にハードコードされた制限があります。制限を超えると、動作は実装に依存します。一部のベンダーは、テーブルにN+1アドレスをインストールできません。その他は、このMacの最古のエントリを削除し、新しいアドレスに置き換えます。いずれにせよ、影響を受けるアドレスは、暗黙の信号を受信せずにネットワーク接続を失い、トラフィックは静かに削除されます。
Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke, Eduard Vasilenko, Timothy Winters, Chongfeng Xie, and Peter Yee for the discussions, their input, and all contributions.
ハラルド・アルベスランド、ニック・ブラーグリオ、ブライアン・カーペンター、ティム・チャウン、ロマン・ダニリウ、ゲルト・ドーリング、デビッド・ファーマー、フェルナンド・ゴント、ジョエル・ハルパーン、ニック・ヒリアード、ボブ・ヒンデン、マーティン・フネック、エリック・クライン、ウォーレン・クマリ、デイビッド・ランパーター、アンドリュー・マクロゲルTomek Mrugalski、Alexandre Petrescu、Jurgen Schonwalder、Pascal Thubert、Ole Troan、Eric Vyncke、Eduard Vasilenko、Timothy Winters、Chongfeng Xie、およびPeter Yeeの議論、彼らのインプット、すべての貢献。
Lorenzo Colitti
Google, LLC
Shibuya 3-21-3,
Japan
Email: lorenzo@google.com
Jen Linkova (editor)
Google
1 Darling Island Rd
Pyrmont New South Wales 2009
Australia
Email: furry13@gmail.com, furry@google.com
Xiao Ma (editor)
Google
Shibuya 3-21-3,
Japan
Email: xiaom@google.com