RFC 7943 - A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7943
タイトル : RFC 7943 - IPv6の動的ホスト構成プロトコル（DHCPv6）を使用して意味的に不透明なインターフェース識別子（IID）を生成する方法
翻訳編集 : 自動生成

[要約] RFC 7943は、IPv6のDHCPv6を使用して意味的に不透明なインターフェース識別子（IIDs）を生成するための方法を提案しています。このRFCの目的は、ネットワーク上のデバイスの識別を改善し、プライバシーとセキュリティを向上させることです。

Independent Submission                                           F. Gont
Request for Comments: 7943                        SI6 Networks / UTN-FRH
Category: Informational                                           W. Liu
ISSN: 2070-1721                                      Huawei Technologies
                                                          September 2016

A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

IPv6の動的ホスト構成プロトコル（DHCPv6）を使用して意味的に不透明なインターフェース識別子（IID）を生成する方法

Abstract

概要

This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.

このドキュメントでは、一時的でないIPv6アドレスをDHCPv6クライアントにリースするときに、IPv6の動的ホスト構成プロトコル（DHCPv6）サーバーで使用できるIPv6インターフェイス識別子を選択する方法について説明します。この方法は、既存のDHCPv6仕様を更新する必要のないDHCPv6サーバー側アルゴリズムです。前述の方法により、複数のDHCPv6サーバーまたはDHCPv6サーバーの再インストールがある場合でも、各サブネット内で安定したアドレスが得られます。これは、IPv6ステートレスアドレス自動構成用にRFC 7217で指定された方法のDHCPv6バリアントです。

IESG Note

A predecessor to this document was earlier a working group document in the DHC WG. The WG decided to stop further work in this area because such work was not considered useful.

この文書の前身は、以前はDHC WGのワーキンググループ文書でした。 WGは、このような作業が有用であるとは考えられなかったため、この分野でのさらなる作業を停止することを決定しました。

The proposal described in this document has an unaddressed failure case that makes it unsuitable for use as the mechanism to provide the claimed failover features for DHCPv6 servers. Specifically, when a DHCPv6 client DECLINEs a provided address there is no recovery mechanism described that will result in the DHCPv6 client obtaining a working IPv6 address.

このドキュメントで説明されている提案には、対処されていない障害事例が含まれているため、DHCPv6サーバーに要求されたフェイルオーバー機能を提供するメカニズムとしての使用は不適切です。具体的には、DHCPv6クライアントが提供されたアドレスを拒否する場合、DHCPv6クライアントが有効なIPv6アドレスを取得することになる回復メカニズムは説明されていません。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7943.

このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7943で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability and Design Goals  . . . . . . . . . . . . . . .   3
   3.  Method Specification  . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

The benefits of stable IPv6 addresses are discussed in [RFC7721]. Providing address stability across server reinstallations or when a database of previous DHCPv6 address leases is unavailable is of use not only when a DHCPv6 server must be reinstalled or the address-lease database becomes corrupted, but is also of use when implementation constraints (e.g., a DHCPv6 server implementation on an embedded device) make it impossible for a DHCPv6 server implementation to maintain a database of previous DHCPv6 address leases. Additionally, [RFC7031] describes scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability in case of server failures.

安定したIPv6アドレスの利点は[RFC7721]で議論されています。サーバーの再インストール後、または以前のDHCPv6アドレスリースのデータベースが利用できない場合にアドレスの安定性を提供することは、DHCPv6サーバーを再インストールする必要がある場合、またはアドレスリースデータベースが破損した場合だけでなく、実装の制約（たとえば、組み込みデバイスへのDHCPv6サーバーの実装）により、DHCPv6サーバーの実装では、以前のDHCPv6アドレスリースのデータベースを維持できなくなります。さらに、[RFC7031]は、サーバーに障害が発生した場合に可用性を高めるために、複数のDHCPv6サーバーを実行する必要があるシナリオについて説明しています。

This document describes a method for selecting IPv6 Interface Identifiers that can be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with IA_NA options). This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method has the following properties:

このドキュメントでは、一時的でないIPv6アドレスをDHCPv6クライアントにリースするときにDHCPv6サーバーで使用できるIPv6インターフェース識別子を選択する方法について説明します（つまり、IA_NAオプションで使用します）。この方法は、既存のDHCPv6仕様を更新する必要のないDHCPv6サーバー側アルゴリズムです。前述のメソッドには、次のプロパティがあります。

o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client, even when different DHCPv6 servers (implementing this specification) are employed.

o 結果のIPv6アドレスは、異なるDHCPv6サーバー（この仕様を実装）が使用されている場合でも、同じクライアントの同じネットワークインターフェイスの各サブネット内で安定したままです。

o Predicting the IPv6 addresses that will be generated by the method specified in this document, even with knowledge of the IPv6 addresses generated for other nodes within the same network, becomes very difficult.

o このドキュメントで指定された方法で生成されるIPv6アドレスを予測することは、同じネットワーク内の他のノードに対して生成されたIPv6アドレスの知識があっても、非常に困難になります。

The method specified in this document achieves the aforementioned properties by means of a calculated technique as opposed to, e.g., state sharing among DHCPv6 servers. This approach has already been suggested in [RFC7031]. We note that the method described in this document is essentially a DHCPv6 version of the "Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].

このドキュメントで指定されている方法は、DHCPv6サーバー間の状態共有などとは対照的に、計算された手法によって前述のプロパティを実現します。このアプローチはすでに[RFC7031]で提案されています。このドキュメントで説明されている方法は、本質的には[RFC7217]で指定されている「IPv6ステートレスアドレス自動構成（SLAAC）でセマンティックに不透明なインターフェース識別子を生成する方法」のDHCPv6バージョンであることに注意してください。

2. Applicability and Design Goals

2. 適用性と設計目標

This document simply describes one possible approach for selecting IPv6 Interface Identifiers to be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients, with the following properties:

このドキュメントでは、一時的でないIPv6アドレスをDHCPv6クライアントにリースするときにDHCPv6サーバーが使用するIPv6インターフェース識別子を選択するための1つの可能なアプローチを簡単に説明します。

o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client.

o 結果のIPv6アドレスは、同じクライアントの同じネットワークインターフェイスの各サブネット内で安定したままです。

o The resulting IPv6 addresses cannot be predicted by an attacker without knowledge of a secret key.

o 結果のIPv6アドレスは、秘密鍵を知らない限り、攻撃者が予測することはできません。

o The resulting IPv6 addresses remain stable across DHCPv6 server reinstallations, or even if a database of previous DHCPv6 address leases is not available.

o 結果のIPv6アドレスは、DHCPv6サーバーの再インストール後、または以前のDHCPv6アドレスリースのデータベースが利用できない場合でも安定したままです。

o The resulting IPv6 addresses remain stable when different DHCPv6 servers (implementing this specification) are employed on the same network.

o 異なるDHCPv6サーバー（この仕様を実装）が同じネットワークで使用されている場合、結果のIPv6アドレスは安定したままです。

We note that the algorithm specified in this document employs a (lightweight) calculated technique (as opposed to, e.g., state sharing among DHCPv6 servers) to achieve address stability in scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability, without the need of an additional protocol to synchronize the lease databases of DHCPv6 servers.

このドキュメントで指定されているアルゴリズムは、（たとえば、DHCPv6サーバー間の状態共有とは対照的に）計算された（軽量の）手法を使用して、複数のDHCPv6サーバーがDHCPv6サーバーのリースデータベースを同期するための追加のプロトコルを必要とせずに、可用性が向上します。

Finally, we note that the algorithm in this document is only meant to mitigate IPv6 address-based location tracking, device-specific vulnerability exploitation, and host scanning (please see [RFC7721]). There are a number of ways in which DHCPv6 affects user privacy, which the algorithm specified in this document does not mitigate (and does not intend to). Please see [RFC7844] for a comprehensive discussion of how DHCPv6 may affect user privacy.

最後に、このドキュメントのアルゴリズムは、IPv6アドレスベースのロケーショントラッキング、デバイス固有の脆弱性の悪用、およびホストスキャン（[RFC7721]を参照）を軽減することのみを目的としていることに注意してください。 DHCPv6がユーザーのプライバシーに影響を与える方法はいくつかありますが、このドキュメントで指定されているアルゴリズムでは軽減されません（意図されていません）。 DHCPv6がユーザーのプライバシーに与える影響の包括的な説明については、[RFC7844]を参照してください。

3. Method Specification

3. メソッド仕様

Implementations should provide the means for a system administrator to enable or disable the use of this algorithm for generating IPv6 addresses.

実装は、システム管理者がIPv6アドレスを生成するためのこのアルゴリズムの使用を有効または無効にする手段を提供する必要があります。

A DHCPv6 server implementing this specification must select the IPv6 addresses to be leased with the following algorithm:

この仕様を実装するDHCPv6サーバーは、次のアルゴリズムでリースするIPv6アドレスを選択する必要があります。

1. Compute a random (but stable) identifier with the expression:

1. 次の式でランダムな（ただし安定した）識別子を計算します。

RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)

RID = F（プレフィックス| Client_DUID | IAID |カウンター| secret_key）

Where:

ただし：

RID: Random (but stable) Identifier

RID：ランダム（ただし安定した）識別子

F(): A Pseudorandom Function (PRF) that must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least 64 bits. F() could be implemented as a cryptographic hash of the concatenation of each of the function parameters. The default algorithm to be employed for F() should be SHA-256 [FIPS-SHS]. An implementation may provide the means for selecting other algorithms. Note: Message Digest 5 (MD5) [RFC1321] is considered unacceptable for F() [RFC6151].

F()：（秘密鍵の知識なしで）外部から計算可能であってはならない擬似ランダム関数（PRF）。 F()は、F()の出力のサンプルと他の入力パラメーターの知識または制御が与えられた場合でも、秘密鍵を取得しようとする試みに抵抗するように、逆にするのが困難でなければなりません。 F()は、少なくとも64ビットの出力を生成する必要があります。 F()は、各関数パラメーターの連結の暗号化ハッシュとして実装できます。 F()に使用されるデフォルトのアルゴリズムはSHA-256 [FIPS-SHS]である必要があります。実装は、他のアルゴリズムを選択する手段を提供します。注：メッセージダイジェスト5（MD5）[RFC1321]は、F()[RFC6151]では受け入れられないと見なされます。

Prefix: The prefix employed for the local subnet, as a 128-bit unsigned integer in network byte order (with the unused bits set to 0). If multiple servers operate on the same network to provide increased availability, all such DHCPv6 servers must be configured with the same Prefix. It is the administrator's responsibility that the aforementioned requirement is met.

プレフィックス：ローカルサブネットに使用されるプレフィックス。ネットワークバイトオーダーの128ビットの符号なし整数（未使用ビットは0に設定）。複数のサーバーが同じネットワーク上で動作して可用性を向上させる場合、そのようなすべてのDHCPv6サーバーは同じプレフィックスで構成する必要があります。前述の要件が満たされるのは、管理者の責任です。

|: An operator representing "concatenation".

|：「連結」を表す演算子。

Client_DUID: The DHCPv6 Unique Identifier (DUID) value contained in the Client Identifier option received in the DHCPv6 client message. The DUID can be treated as an array of 8-bit unsigned integers.

Client_DUID：DHCPv6クライアントメッセージで受信したクライアント識別子オプションに含まれるDHCPv6一意識別子（DUID）値。 DUIDは、8ビットの符号なし整数の配列として扱うことができます。

IAID: The Identity Association Identifier (IAID) value contained in the IA_NA option received in the client message. It must be interpreted as a 32-bit unsigned integer in network byte order.

IAID：クライアントメッセージで受信されたIA_NAオプションに含まれるIDアソシエーション識別子（IAID）値。ネットワークバイトオーダーの32ビット符号なし整数として解釈する必要があります。

secret_key: A secret key configured by the DHCPv6 server administrator, which must not be known by the attacker. It must be encoded as an array of 8-bit unsigned integers. An implementation of this specification must provide an interface for viewing and changing the secret key. All DHCPv6 servers leasing addresses from the same address range must employ the same secret key.

secret_key：DHCPv6サーバー管理者が設定した秘密キー。攻撃者に知られてはいけません。 8ビットの符号なし整数の配列としてエンコードする必要があります。この仕様の実装は、秘密鍵を表示および変更するためのインターフェースを提供する必要があります。同じアドレス範囲からアドレスをリースするすべてのDHCPv6サーバーは、同じ秘密鍵を使用する必要があります。

Counter: A 32-bit unsigned integer in network byte order that is employed to resolve address conflicts. It must be initialized to 0.

カウンター：アドレスの競合を解決するために使用されるネットワークバイトオーダーの32ビット符号なし整数。 0に初期化する必要があります。

2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by concatenating as many bits as necessary from the RID value computed in the previous step (starting from the least significant bit) to the Prefix employed in the equation above, as follows:

2. リースされるIPv6アドレス（IPV6_ADDR）の候補は、前の手順で計算されたRID値から（最下位ビットから開始して）必要な数のビットを上記の式で使用されるプレフィックスに次のように連結することによって取得されます。

        IPV6_ADDR = IPV6_ADDR_LOW +
                    RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)

where:

ただし：

IPV6_ADDR: The candidate IPv6 address to be leased.

IPV6_ADDR：リースされる候補IPv6アドレス。

IPV6_ADDR_HI: An IPv6 address specifying the upper boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_HI must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 1.

IPV6_ADDR_HI：DHCPv6サーバーがIPv6アドレスをリースするIPv6アドレスプールの上限を指定するIPv6アドレス。アドレス範囲が明示的に選択されていない場合、IPV6_ADDR_HIは、インターフェイス識別子のすべてのビットが1に設定されているプレフィックス（上記の式を参照）からのIPv6アドレスに設定する必要があります。

IPV6_ADDR_LOW: An IPv6 address specifying the lower boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 0.

IPV6_ADDR_LOW：DHCPv6サーバーがIPv6アドレスをリースするIPv6アドレスプールの下限を指定するIPv6アドレス。アドレス範囲が明示的に選択されていない場合、IPV6_ADDR_LOWは、インターフェイス識別子のすべてのビットが0に設定されているプレフィックス（上記の式を参照）からのIPv6アドレスに設定する必要があります。

3. The Interface Identifier of the selected IPv6 address must be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable identifier has been generated, the Counter variable should be incremented by 1, and a new IPv6 address should be computed with the updated Counter value.

3. 選択したIPv6アドレスのインターフェース識別子は、予約済みのIPv6インターフェース識別子[RFC5453] [IANA-RESERVED-IID]と比較する必要があります。許容できない識別子が生成された場合、Counter変数を1増やし、新しいIPv6アドレスを更新されたCounter値で計算する必要があります。

4. If the resulting address is not available (e.g., there is a conflicting binding), the DHCPv6 server should increment the Counter variable, and a new Interface Identifier and IPv6 address should be computed with the updated Counter value.

4. 結果のアドレスが使用できない場合（たとえば、バインディングが競合している場合）、DHCPv6サーバーはCounter変数をインクリメントし、新しいインターフェイス識別子とIPv6アドレスを更新されたCounter値で計算する必要があります。

This document requires that SHA-256 be the default function to be used for F(), such that (all other configuration parameters being the same) different implementations of this specification result in the same IPv6 addresses.

このドキュメントでは、SHA-256がF()に使用されるデフォルト関数であることを要求しています。そのため、（他のすべての構成パラメーターは同じですが）この仕様の異なる実装は同じIPv6アドレスになります。

Including the Prefix in the PRF computation causes the Interface Identifier to be different for each address from a different prefix leased to the same client. This mitigates the correlation of activities of multihomed nodes (since each of the corresponding addresses will employ a different Interface Identifier), host tracking (since the network prefix, and therefore the resulting Interface Identifier, will change as the node moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers [RFC7721].

PRF計算にプレフィックスを含めると、同じクライアントにリースされる異なるプレフィックスからのアドレスごとにインターフェイス識別子が異なります。これにより、マルチホームノードのアクティビティの相関が緩和されます（対応するアドレスごとに異なるインターフェイス識別子が使用されるため）、ホストトラッキング（ネットワークプレフィックス、したがって結果のインターフェイス識別子がノードがネットワーク間を移動するにつれて変化するため））、および予測可能なインターフェース識別子[RFC7721]の恩恵を受けるその他の攻撃。

As required by [RFC3315], an IAID is associated with each of the client's network interfaces and is consistent across restarts of the DHCPv6 client.

[RFC3315]で要求されているように、IAIDは各クライアントのネットワークインターフェイスに関連付けられており、DHCPv6クライアントの再起動間で一貫しています。

The Counter parameter provides the means to intentionally cause this algorithm to produce different IPv6 addresses (all other parameters being the same). This can be of use to resolve address conflicts (e.g., the resulting address having a conflicting binding).

Counterパラメータは、このアルゴリズムに意図的に異なるIPv6アドレスを生成させる手段を提供します（他のすべてのパラメータは同じです）。これは、アドレスの競合を解決するのに役立ちます（たとえば、結果として生じるアドレスに競合するバインディングがあります）。

Note that the result of F() in the algorithm above is no more secure than the secret key. If an attacker is aware of the PRF that is being used by the DHCPv6 server (which we should expect), and the attacker can obtain enough material (i.e., addresses generated by the DHCPv6 server), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of at least 128 bits. Key lengths of at least 128 bits should be adequate.

上記のアルゴリズムのF()の結果は、秘密鍵と同じくらい安全ではないことに注意してください。攻撃者がDHCPv6サーバーで使用されているPRF（これは予想されるはずです）を知っていて、攻撃者が十分な資料（つまり、DHCPv6サーバーによって生成されたアドレス）を取得できる場合、攻撃者は単にシークレット全体を検索する可能性があります。一致を見つけるためのキースペース。これを防ぐために、秘密鍵は少なくとも128ビットでなければなりません。鍵の長さは128ビット以上で十分です。

Providing a mechanism to display and change the secret_key is crucial for having different DHCPv6 servers produce the same IPv6 addresses and for causing a replacement system to generate the same IPv6 addresses as the system being replaced. We note that since the privacy of the scheme specified in this document relies on the secrecy of the secret_key parameter, implementations should constrain access to the secret_key parameter to the extent practicable (e.g., require superuser privileges to access it). Furthermore, in order to prevent leakages of the secret_key parameter, it should not be used for any other purposes than being a parameter to the scheme specified in this document.

異なるDHCPv6サーバーに同じIPv6アドレスを生成させ、交換するシステムに交換されるシステムと同じIPv6アドレスを生成させるには、secret_keyを表示および変更するメカニズムを提供することが重要です。このドキュメントで指定されているスキームのプライバシーはsecret_keyパラメータの機密性に依存しているため、実装では、secret_keyパラメータへのアクセスを実行可能な範囲で制限する必要があります（たとえば、アクセスするにはスーパーユーザー権限が必要です）。さらに、secret_keyパラメータの漏洩を防ぐために、このドキュメントで指定されているスキームのパラメータ以外の目的で使用しないでください。

We note that all of the bits in the resulting Interface Identifiers are treated as "opaque" bits [RFC7136]. For example, the universal/ local bit of Modified EUI-64 format identifiers is treated as any other bit of such identifier.

結果として得られるインターフェイス識別子のすべてのビットは、「不透明な」ビットとして扱われることに注意してください[RFC7136]。たとえば、Modified EUI-64形式の識別子のユニバーサル/ローカルビットは、そのような識別子の他のビットとして扱われます。

4. Security Considerations

4. セキュリティに関する考慮事項

The method specified in this document results in IPv6 Interface Identifiers (and hence IPv6 addresses) that do not follow any specific pattern. Thus, attacks that rely on predictable Interface Identifiers (such as [RFC7707]) are mitigated.

このドキュメントで指定されている方法では、特定のパターンに従わないIPv6インターフェース識別子（したがってIPv6アドレス）が生成されます。したがって、予測可能なインターフェイス識別子（[RFC7707]など）に依存する攻撃は軽減されます。

The method specified in this document neither mitigates nor exacerbates the security considerations for DHCPv6 discussed in [RFC3315] and does not mitigate a range of other privacy implications associated with DHCPv6. Please read [RFC7844] for a comprehensive assessment of the privacy implications of DHCPv6.

このドキュメントで指定されている方法は、[RFC3315]で説明されているDHCPv6のセキュリティに関する考慮事項を緩和または悪化させることはなく、DHCPv6に関連するその他のプライバシーへの影響を軽減することもありません。 DHCPv6のプライバシーへの影響の包括的な評価については、[RFC7844]を読んでください。

Finally, we note that an attacker that is able to attach to each of the links to which the victim attaches would still be able to correlate the activities of the victim across networks.

最後に、被害者が接続している各リンクに接続できる攻撃者は、ネットワーク全体で被害者のアクティビティを関連付けることができることに注意してください。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[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>。

[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <http://www.rfc-editor.org/info/rfc5453>.

[RFC5453] Krishnan、S。、「Reserved IPv6 Interface Identifiers」、RFC 5453、DOI 10.17487 / RFC5453、2009年2月、<http://www.rfc-editor.org/info/rfc5453>。

[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.

[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<http://www.rfc-editor.org/info/rfc7136>。

5.2. Informative References

5.2. 参考引用

[FIPS-SHS] Federal Information Processing Standards (FIPS), "Secure Hash Standard (SHS)", FIPS 180-4, August 2015, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.

[FIPS-SHS]連邦情報処理標準（FIPS）、「Secure Hash Standard（SHS）」、FIPS 180-4、2015年8月、<http://csrc.nist.gov/publications/fips/fips180-4/ fips -180-4.pdf>。

[IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <http://www.iana.org/assignments/ipv6-interface-ids>.

[IANA-RESERVED-IID] IANA、「予約済みIPv6インターフェース識別子」、<http://www.iana.org/assignments/ipv6-interface-ids>。

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <http://www.rfc-editor.org/info/rfc6151>.

[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<http：//www.rfc- editor.org/info/rfc6151>。

[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", RFC 7031, DOI 10.17487/RFC7031, September 2013, <http://www.rfc-editor.org/info/rfc7031>.

[RFC7031] Mrugalski、T。およびK. Kinnear、「DHCPv6フェイルオーバー要件」、RFC 7031、DOI 10.17487 / RFC7031、2013年9月、<http://www.rfc-editor.org/info/rfc7031>。

[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>。

[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <http://www.rfc-editor.org/info/rfc7707>.

[RFC7707] Gont、F。およびT. Chown、「IPv6ネットワークでのネットワーク偵察」、RFC 7707、DOI 10.17487 / RFC7707、2016年3月、<http://www.rfc-editor.org/info/rfc7707>。

[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.

[RFC7721]クーパー、A。、ゴント、F。、およびD.ターラー、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<http：//www.rfc- editor.org/info/rfc7721>。

[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>。

Acknowledgements

謝辞

This document is based on [RFC7217], authored by Fernando Gont.

このドキュメントは、Fernando Gontによって作成された[RFC7217]に基づいています。

The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for providing valuable comments on earlier draft versions of this documents.

このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくれたMarc Blanchet、Stephane Bortzmeyer、Tatuya Jinmei、Andre Kostur、Tomek Mrugalski、Hosnieh Rafiee、Jim Schaad、Jean-Francois Tremblay、Tina Tsou、およびBernie Volzに感謝します。

The authors would like to thank Ted Lemon, who kindly answered some DHCPv6-related questions, and Nevil Brownlee for his guidance while pursuing this document.

著者は、DHCPv6関連のいくつかの質問に親切に回答してくれたTed Lemonと、このドキュメントを追求している間のガイダンスを提供してくれたNevil Brownleeに感謝します。

Fernando Gont would like to thank Nelida Garcia and Guillermo Gont for their love and support, and Diego Armando Maradona for his magic and inspiration.

フェルナンドゴントは、ネリダガルシアとギジェルモゴントの愛とサポート、そしてディエゴアルマンドマラドーナの魔法とインスピレーションに感謝します。

Authors' Addresses

著者のアドレス

Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China

will（Shu成）l IU hu Aはテクノロジー禁止の日であり、長いだけの地区は非常に現実的です518129中国

   Email: liushucheng@huawei.com