RFC 8981 - R. Draves Microsoft Research February 2021 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8981.html
タイトル : RFC 8981 - R. Draves Microsoft Research 2021年2月
翻訳編集 : 自動生成

[要約] RFC 8981は、IPv6ネットワークでのセグメントルーティングのための新しい手法を定義します。この文書の目的は、データパケットの経路をより効率的に制御し、ネットワークの柔軟性と性能を向上させることです。利用場面には、トラフィックエンジニアリング、フォールト回避、負荷分散が含まれます。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 8981                                  SI6 Networks
Obsoletes: 4941                                              S. Krishnan
Category: Standards Track                                         Kaloom
ISSN: 2070-1721                                                T. Narten

R. Draves Microsoft Research February 2021

R. Draves Microsoft Research 2021年2月

Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6

IPv6のステートレスアドレス自動設定のための一時アドレス拡張

Abstract

概要

This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.

このドキュメントでは、Autoconfigurationが有効になっているプレフィックスごとに、ホストにランダム化されたインターフェイス識別子を持つ一時アドレスを生成するためのIPv6ステートレスアドレスの自動設定を説明します。時間の経過とともにアドレスを変更すると、同じアドレスが同じホストによる複数のトランザクションに使用されている場合、盗聴者および他の情報コレクタがアドレスベースのネットワーク活動相関を実際的に実行できる時間のウィンドウを制限します。さらに、アクティブな通信の結果として明らかになるアドレスを介してアクセス可能なホストの露光ウィンドウを縮小する。この文書はRFC 4941を廃止します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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 Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8981.

この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8981で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Terminology
     1.2.  Problem Statement
   2.  Background
     2.1.  Extended Use of the Same Identifier
     2.2.  Possible Approaches
   3.  Protocol Description
     3.1.  Design Guidelines
     3.2.  Assumptions
     3.3.  Generation of Randomized IIDs
       3.3.1.  Simple Randomized IIDs
       3.3.2.  Generation of IIDs with Pseudorandom Functions
     3.4.  Generating Temporary Addresses
     3.5.  Expiration of Temporary Addresses
     3.6.  Regeneration of Temporary Addresses
     3.7.  Implementation Considerations
     3.8.  Defined Protocol Parameters and Configuration Variables
   4.  Implications of Changing IIDs
   5.  Significant Changes from RFC 4941
   6.  Future Work
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6, which typically results in hosts configuring one or more "stable" IPv6 addresses composed of a network prefix advertised by a local router and a locally generated interface identifier (IID). The security and privacy implications of such addresses have been discussed in detail in [RFC7721], [RFC7217], and [RFC7707]. This document specifies an extension to SLAAC for generating temporary addresses that can help mitigate some of the aforementioned issues. This document is a revision of RFC 4941 and formally obsoletes it. Section 5 describes the changes from [RFC4941].

[RFC4862] IPv6のステートレスアドレス自動設定（SLAAC）を指定します。これは、通常、ローカルルータによってアドバタイズされたネットワークプレフィックスとローカルで生成されたインターフェイス識別子（IID）で構成される1つ以上の「安定した」IPv6アドレスを設定します。そのようなアドレスのセキュリティとプライバシーの影響は[RFC7721]、[RFC7217]、[RFC7707]で詳細に説明しています。このドキュメントは、前述の問題のいくつかを軽減するのに役立つ一時アドレスを生成するためのSLAACへの拡張機能を指定します。この文書はRFC 4941の改訂であり、正式に廃止されます。セクション5は[RFC4941]からの変更を説明しています。

The default address selection for IPv6 has been specified in [RFC6724]. In some cases, the determination as to whether to use stable versus temporary addresses can only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. An Application Programming Interface (API) such as that specified in [RFC5014] can enable individual applications to indicate a preference for the use of temporary addresses.

IPv6のデフォルトのアドレス選択が[RFC6724]に指定されています。場合によっては、安定した対一時アドレスを使用するかどうかの判断は、アプリケーションによってのみ行うことができます。たとえば、一部のアプリケーションは常に一時アドレスを使用したいと思うかもしれませんが、他の状況でのみ使用したり、まったく使用したりすることもできます。[RFC5014]で指定されたアプリケーション・プログラミング・インターフェース（API）は、個々のアプリケーションが一時アドレスを使用するための好みを示すことができます。

Section 2 provides background information. Section 3 describes a procedure for generating temporary addresses. Section 4 discusses implications of changing IIDs. Section 5 describes the changes from [RFC4941].

セクション2は背景情報を提供します。セクション3に一時アドレスを生成するための手順を示します。セクション4は、IIDを変更することの意味を論じている。セクション5は[RFC4941]からの変更を説明しています。

1.1. Terminology

1.1. 用語

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.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

The terms "public address", "stable address", "temporary address", "constant IID", "stable IID", and "temporary IID" are to be interpreted as specified in [RFC7721].

「パブリックアドレス」、「安定アドレス」、「一時アドレス」、「定数IID」、「STABLE IID」、「仮IID」、「一時IID」は、[RFC7721]で指定されていると解釈されます。

The term "global-scope addresses" is used in this document to collectively refer to "Global unicast addresses" as defined in [RFC4291] and "Unique local addresses" as defined in [RFC4193], and not to "globally reachable addresses" as defined in [RFC8190].

「Global-Scope Addresses」という用語は、[RFC4291]で定義されている「Global Unicast Addresses」と[RFC4193]で定義されている「グローバルユニキャストアドレス」とは、「Globally Addresses」ではなく、「グローバルユニキャストアドレス」を参照しています。[RFC8190]で定義されています。

1.2. Problem Statement

1.2. 問題文

Addresses generated using SLAAC [RFC4862] contain an embedded interface identifier, which may remain stable over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier.

SLAAC [RFC4862]を使用して生成されたアドレスには、埋め込みインターフェイス識別子が含まれています。これは時間の経過とともに安定したままである可能性があります。固定識別子が複数のコンテキストで使用されている場合は、この識別子を使用して一見無関係なアクティビティを関連付けることが可能になります。

The correlation can be performed by:

相関は次のように実行できます。

* An attacker who is in the path between the host in question and the peer(s) to which it is communicating, who can view the IPv6 addresses present in the datagrams.

* 問題のホストと通信しているピア間のパスにある攻撃者は、データグラムに存在するIPv6アドレスを表示できます。

* An attacker who can access the communication logs of the peers with which the host has communicated.

* ホストが通信したピアの通信ログにアクセスできる攻撃者。

Since the identifier is embedded within the IPv6 address, it cannot be hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time.

識別子はIPv6アドレス内に埋め込まれているので、非表示にすることはできません。この文書は、時間とともに変化するインターフェイス識別子を生成することによって、この問題に対する解決策を提案します。

Note that an attacker, who is on path, may be able to perform significant correlation based on:

パス上にある攻撃者は、以下に基づいて重要な相関を実行できることに注意してください。

* The payload contents of unencrypted packets on the wire.

* ワイヤ上の未暗号化されていないパケットのペイロード内容。

* The characteristics of the packets, such as packet size and timing.

* パケットサイズやタイミングなどのパケットの特性。

Use of temporary addresses will not prevent such correlation, nor will it prevent an on-link observer (e.g., the host's default router) from tracking all the host's addresses.

一時アドレスの使用はそのような相関関係を妨げることもなく、リンクオンリンクオブザーバ（ホストのデフォルトルータ）がすべてのホストのアドレスを追跡するのを妨げることもありません。

2. Background

2. バックグラウンド

This section discusses the problem in more detail, provides context for evaluating the significance of the concerns in specific environments, and makes comparisons with existing practices.

このセクションでは、問題をより詳細に説明し、特定の環境における懸念の重要性を評価するためのコンテキストを提供し、既存の慣行と比較します。

2.1. Extended Use of the Same Identifier

2.1. 同じ識別子の拡張使用

The use of a non-changing IID to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. For example, a network sniffer placed strategically on a link traversed by all traffic to/ from a particular host could keep track of which destinations a host communicated with and at what times. In some cases, such information can be used to infer things, such as what hours an employee was active, when someone is at home, etc. Although it might appear that changing an address regularly in such environments would be desirable to lessen privacy concerns, it should be noted that the network-prefix portion of an address also serves as a constant identifier. All hosts at, say, a home would have the same network prefix, which identifies the topological location of those hosts. This has implications for privacy, though not at the same granularity as the concern that this document addresses. Specifically, all hosts within a home could be grouped together for the purposes of collecting information. If the network contains a very small number of hosts -- say, just one -- changing just the IID will not enhance privacy, since the prefix serves as a constant identifier.

変更されていないIIDを形成するためにアドレスを形成することは、定数識別子が長期間にわたって再利用され、複数の独立した活動で再利用される特定の例の特定のインスタンスです。同じ識別子が複数のコンテキストで使用されている場合は、一見無関係なアクティビティを関連付けるためにその識別子を使用することが可能になります。例えば、特定のホストへの/からの全てのトラフィックがトラバースされたリンク上に戦略的に配置されたネットワークスニファが、ホストがどの宛先に通信するかを追跡することができる。場合によっては、そのような情報を使用して、誰かが自宅にいるときなど、何時間も推測することができます。アドレスのネットワークプレフィックス部分も定数識別子として機能することに留意されたい。すべてのホストは、ホームが同じネットワークプレフィックスを持つことになります。これはそれらのホストのトポロジの位置を識別します。これは、このドキュメントのアドレスの関心事と同じ粒状性ではありませんが、プライバシーに影響を与えます。具体的には、家内のすべてのホストを収集する目的で一緒にグループ化できます。ネットワークに非常に少数のホストが含まれている場合、Prefixは定数識別子として機能するため、IIDだけがプライバシーを強化することはありません。

One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. IP addresses provide one obvious example, but there are more. For example:

一見無関係の活動を相関させるための要件の1つは、さまざまなコンテキスト内で時間が経つにつれて認識可能な識別子の使用（および再利用）です。IPアドレスは1つの明らかな例を提供しますが、もっとあります。例えば：

* Many hosts also have DNS names associated with their addresses, in which case, the DNS name serves as a similar identifier. Although the DNS name associated with an address is more work to obtain (it may require a DNS query), the information is often readily available. In such cases, changing the address on a host over time would do little to address the concerns raised in this document, unless the DNS name is also changed at the same time (see Section 4).

* 多くのホストにはアドレスに関連付けられているDNS名もあります。その場合、DNS名は同様の識別子として機能します。アドレスに関連付けられているDNS名は、取得するためのより多くの作業ですが（DNSクエリが必要になる場合があります）、情報はしばしば容易に利用可能です。そのような場合、DNS名も同時に変更されていない限り、ホスト上のアドレスを時間の経過とともに変更することはほとんどありません（セクション4を参照）。

* Web browsers and servers typically exchange "cookies" with each other [RFC6265]. Cookies allow web servers to correlate a current activity with a previous activity. One common usage is to send back targeted advertising to a user by using the cookie supplied by the browser to identify what earlier queries had been made (e.g., for what type of information). Based on the earlier queries, advertisements can be targeted to match the (assumed) interests of the end user.

* Webブラウザとサーバーは通常、「Cookie」を互いに交換します[RFC6265]。Cookieは、Webサーバーが現在のアクティビティと以前のアクティビティを相関させることを可能にします。1つの一般的な使用法は、ブラウザによって提供されたCookieを使用して（例えば、どのような種類の情報について）識別されたクッキーを使用することによって、ターゲットアドバタイズをユーザに送信することである。以前のクエリに基づいて、アドバタイズメントはエンドユーザーの（仮定）利益を一致させるようにターゲティングすることができます。

The use of a constant identifier within an address is of special concern, because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper-layer payloads were encrypted.

アドレス内の定数識別子の使用は特別な問題であり、アドレスは通信の基本的な要件であり、盗聴者や他の当事者から簡単に隠されることはできません。より高いレイヤーがペイロードを暗号化しても、パケットヘッダー内のアドレスが明確に表示されます。その結果、モバイルホスト（例えば、ノートパソコン）がいくつかの異なる場所からネットワークにアクセスした場合、上位層のペイロードが暗号化されていても、盗聴者はその移動ホストの移動を場所に追従することができます。

Changing addresses over time limits the time window over which eavesdroppers and other information collectors may trivially correlate network activity when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure during which a host is accessible via an address that becomes revealed as a result of active communication.

時間経過の変更は、同じアドレスが同じホストによる複数のトランザクションに対して使用されるときに、盗聴者および他の情報収集機がネットワークアクティビティを自明に相関させる可能性がある時間枠を制限します。さらに、アクティブな通信の結果として明らかになるアドレスを介してホストがアクセス可能になる露光ウィンドウを減らす。

The security and privacy implications of IPv6 addresses are discussed in detail in [RFC7721], [RFC7707], and [RFC7217].

IPv6アドレスのセキュリティとプライバシーの影響については、[RFC7721]、[RFC7707]、[RFC7217]で詳しく説明しています。

2.2. Possible Approaches

2.2. 考えられるアプローチ

One approach, compatible with the SLAAC architecture, would be to change the IID portion of an address over time. Changing the IID can make it more difficult to look at the IP addresses in independent transactions and identify which ones actually correspond to the same host, both in the case where the routing-prefix portion of an address changes and when it does not.

SLAACアーキテクチャと互換性のある1つのアプローチは、アドレスのIID部分を時間の経過とともに変更することです。IIDを変更すると、IPアドレスを独立したトランザクションのIPアドレスを調べて、アドレスのルーティングプレフィックス部分が変更されたときとそれがそうでない場合と同様に、同じホストに対応するものを識別することが困難になります。

Many hosts function as both clients and servers. In such cases, the host would need a name (e.g., a DNS domain name) for its use as a server. Whether the address stays fixed or changes has little impact on privacy, since the name remains constant and serves as a constant identifier. However, when acting as a client (e.g., initiating communication), such a host may want to vary the addresses it uses. In such environments, one may need multiple addresses: a stable address associated with the name, which is used to accept incoming connection requests from other hosts, and a temporary address used to shield the identity of the client when it initiates communication.

多くのホストがクライアントとサーバーの両方として機能します。そのような場合、ホストはサーバーとしての使用のための名前（例えば、DNSドメイン名）が必要です。名前が一定のままであり、定数識別子として機能するため、アドレスが固定されているか変更に影響を与えるかどうかはプライバシーに影響を与えません。しかしながら、クライアントとして機能するとき（例えば、通信を開始する）、そのようなホストはそれが使用するアドレスを変えることを望むことがある。そのような環境では、複数のアドレスが必要になる場合があります。この名前に関連する安定アドレスは、他のホストからの着信接続要求を受け入れるために使用され、通信を開始するときにクライアントの識別情報を保護するために使用される一時アドレスです。

On the other hand, a host that functions only as a client may want to employ only temporary addresses for public communication.

一方、クライアントとしてのみ機能するホストは、公衆通信のための一時アドレスのみを採用することができます。

To make it difficult to make educated guesses as to whether two different IIDs belong to the same host, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities that are collecting information.

2つの異なるIIDが同じホストに属しているかどうかについて教育を受けた推測をすることを困難にするためには、代替識別子を生成するためのアルゴリズムには、情報を収集している外部エンティティの観点から予測不可能なコンポーネントを持つ入力が含まれていなければなりません。

3. Protocol Description

3. プロトコルの説明

The following subsections define the procedures for the generation of IPv6 temporary addresses.

次のサブセクションでは、IPv6一時アドレスの生成手順を定義します。

3.1. Design Guidelines

3.1. デザインガイドライン

Temporary addresses observe the following properties:

一時アドレス以下のプロパティを確認してください。

1. Temporary addresses are typically employed for initiating outgoing sessions.

1. 一時アドレスは通常、発信セッションを開始するために使用されます。

2. Temporary addresses are used for a short period of time (typically hours to days) and are subsequently deprecated. Deprecated addresses can continue to be used for established connections but are not used to initiate new connections.

2. 一時アドレスは短時間（通常は数日）に使用され、その後推奨されていません。廃止予定のアドレスは、確立された接続に使用され続けることができますが、新しい接続を開始するためには使用されません。

3. New temporary addresses are generated over time to replace temporary addresses that expire (i.e., become deprecated and eventually invalidated).

3. 期限切れの一時アドレスを経時的に新しい一時アドレスが生成されます（すなわち、推奨されて最終的に無効化された）。

4. Temporary addresses must have a limited lifetime (limited "valid lifetime" and "preferred lifetime" from [RFC4862]). The lifetime of an address should be further reduced when privacy-meaningful events (such as a host attaching to a different network, or the regeneration of a new randomized Media Access Control (MAC) address) take place. The lifetime of temporary addresses must be statistically different for different addresses, such that it is hard to predict or infer when a new temporary address is generated or correlate a newly generated address with an existing one.

4. 一時アドレスには、[RFC4862]から、制限された存続期間（有効なライフタイム "と優先寿命"）が必要です。プライバシーという意味のイベント（異なるネットワークに接続されている、または新しいランダム化されたメディアアクセス制御（MAC）アドレスの再生など）が発生すると、アドレスの存続期間をさらに短縮する必要があります。一時アドレスの寿命は、アドレスが異なると統計的に異なる必要があります。これにより、新しい一時アドレスが生成されたとき、または新しく生成されたアドレスを既存のアドレスと関連付けることができないか、または新しいアドレスを相関させる必要があります。

5. By default, one address is generated for each prefix advertised by SLAAC. The resulting interface identifiers must be statistically different when addresses are configured for different prefixes or different network interfaces. This means that, given two addresses, it must be difficult for an outside entity to infer whether the addresses correspond to the same host or network interface.

5. デフォルトでは、SLAACによってアドバタイズされたプレフィックスごとに1つのアドレスが生成されます。さまざまなプレフィックスまたは異なるネットワークインターフェイスに対してアドレスが設定されている場合、結果のインターフェイス識別子は統計的に異なる必要があります。つまり、2つのアドレスを指定して、外部エンティティがアドレスが同じホストインタフェースまたはネットワークインターフェイスに対応するかどうかを推測するのは困難である必要があります。

6. It must be difficult for an outside entity to predict the interface identifiers that will be employed for temporary addresses, even with knowledge of the algorithm/method employed to generate them and/or knowledge of the IIDs previously employed for other temporary addresses. These IIDs must be semantically opaque [RFC7136] and must not follow any specific patterns.

6. 他の一時アドレスに以前に採用されているIIDの知識を生成するために、外部エンティティが一時アドレスに使用されるインターフェース識別子を予測することは困難でなければならない。これらのIIDは意味的に不透明な[RFC7136]でなければならず、特定のパターンに従わないでください。

3.2. Assumptions

3.2. 仮定

The following algorithm assumes that, for a given temporary address, an implementation can determine the prefix from which it was generated. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address are dependent on the corresponding lifetime values set for the prefix from which it was generated.

次のアルゴリズムは、特定の一時アドレスについて、実装が生成されたプレフィックスを決定することができると仮定します。一時アドレスが推奨されていない場合は、新しい一時アドレスが生成されます。新しいアドレスの特定の有効かつ優先寿命は、それが生成されたプレフィックスに設定された対応する寿命値に依存します。

Finally, this document assumes that, when a host initiates outgoing communications, temporary addresses can be given preference over stable addresses (if available), when the device is configured to do so. [RFC6724] mandates that implementations provide a mechanism that allows an application to configure its preference for temporary addresses over stable addresses. It also allows an implementation to prefer temporary addresses by default, so that the connections initiated by the host can use temporary addresses without requiring application-specific enablement. This document also assumes that an API will exist that allows individual applications to indicate whether they prefer to use temporary or stable addresses and override the system defaults (see, for example, [RFC5014]).

最後に、この文書は、ホストが通信を開始すると、一時アドレスを安定したアドレス（使用可能な場合）に設定され、デバイスがそうするように設定されていることを前提としています。[RFC6724]実装は、アプリケーションが安定したアドレスを介して一時アドレスの設定を設定できるようにするメカニズムを提供することを義務付けています。また、実装ではデフォルトで一時アドレスを好むこともできます。そのため、ホストによって開始された接続は、アプリケーション固有の有効化を必要とせずに一時アドレスを使用できます。このドキュメントはまた、個々のアプリケーションが一時的または安定アドレスを使用し、システムのデフォルトを上書きすることを好むかどうかを示すことができるAPIが存在すると仮定します（たとえば、[RFC5014]を参照）。

3.3. Generation of Randomized IIDs

3.3. 無作為化IIDの生成

The following subsections specify example algorithms for generating temporary IIDs that follow the guidelines in Section 3.1 of this document. The algorithm specified in Section 3.3.1 assumes a pseudorandom number generator (PRNG) is available on the system. The algorithm specified in Section 3.3.2 allows for code reuse by hosts that implement [RFC7217].

次のサブセクションでは、この文書の3.1項のガイドラインに従う一時的なIIDを生成するためのアルゴリズムの例を指定します。セクション3.3.1で指定されたアルゴリズムは、システム上で疑似ランダム数ジェネレータ（PRNG）を使用可能にします。セクション3.3.2で指定されたアルゴリズムは、[RFC7217]を実装するホストによるコード再利用を可能にします。

3.3.1. Simple Randomized IIDs

3.3.1. 単純なランダム化されたIID

One approach is to select a pseudorandom number of the appropriate length. A host employing this algorithm should generate IIDs as follows:

1つのアプローチは、適切な長さの疑似乱数を選択することです。このアルゴリズムを使用するホストは、IIDを次のように生成する必要があります。

1. Obtain a random number from a PRNG that can produce random numbers of at least as many bits as required for the IID (please see the next step). [RFC4086] specifies randomness requirements for security.

1. 少なくともIIDに必要な数のビットの乱数を生成できるPRNGから乱数を取得します（次のステップを参照してください）。[RFC4086]セキュリティのためのランダム性要件を指定します。

2. The IID is obtained by taking as many bits from the random number obtained in the previous step as necessary. See [RFC7136] for the necessary number of bits (i.e., the length of the IID). See also [RFC7421] for a discussion of the privacy implications of the IID length. Note: there are no special bits in an IID [RFC7136].

2. IIDは、必要に応じて前のステップで得られた乱数から数ビットを取ることによって得られる。必要なビット数（すなわち、IIDの長さ）については、[RFC7136]を参照してください。IID長のプライバシーの影響については、[RFC7421]も参照してください。注：IIDの特別なビットはありません[RFC7136]。

3. The resulting IID MUST be compared against the reserved IPv6 IIDs [RFC5453] [IANA-RESERVED-IID] and against those IIDs already employed in an address of the same network interface and the same network prefix. In the event that an unacceptable identifier has been generated, a new IID should be generated by repeating the algorithm from the first step.

3. 結果のIIDは、予約されたIPv6 IID [RFC5453] [IANA-Reserved-IID]と比較する必要があります。また、同じネットワークインターフェイスのアドレスと同じネットワークプレフィックスのアドレスにすでに採用されているIIDに対して比較する必要があります。許容できない識別子が生成された場合、最初のステップからアルゴリズムを繰り返すことによって新しいIIDを生成する必要があります。

3.3.2. Generation of IIDs with Pseudorandom Functions

3.3.2. 擬似乱数関数を有するIIDの生成

The algorithm in [RFC7217] can be augmented for the generation of temporary addresses. The benefit of this is that a host could employ a single algorithm for generating stable and temporary addresses by employing appropriate parameters.

[RFC7217]のアルゴリズムは一時アドレスの生成のために拡張することができます。この利点は、ホストが適切なパラメータを使用することによって安定したアドレスと一時的なアドレスを生成するための単一のアルゴリズムを使用できることです。

Hosts would employ the following algorithm for generating the temporary IID:

ホストは、一時的なIIDを生成するために次のアルゴリズムを使用します。

1. Compute a random identifier with the expression:

1. 式でランダムな識別子を計算します。

RID = F(Prefix, Net_Iface, Network_ID, Time, DAD_Counter, secret_key)

RID = f（プレフィックス、net_iface、network_id、time、dad_counter、secret_key）

Where:

ただし：

RID: Random 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 as many bits as required for the IID. BLAKE3 (256-bit key, arbitrary-length output) [BLAKE3] is one possible option for F(). Alternatively, F() could be implemented with a keyed-hash message authentication code (HMAC) [RFC2104]. HMAC-SHA-256 [FIPS-SHS] is one possible option for such an implementation alternative. Note: use of HMAC-MD5 [RFC1321] is considered unacceptable for F() [RFC6151].

f（）：外部から計算可能でなければならない疑似ランダム関数（PRF）。f（）の出力のサンプルと他の入力パラメータの知識または制御のサンプルを与えられていても、逆になるようにF（）も逆にするのが難しい必要があります。f（）は、IIDに必要な少なくとも数のビットの出力を生成する必要があります。Blake3（256ビットキー、任意の長さ出力）[Blake3]はf（）の場合の1つのオプションです。あるいは、f（）は、キー付きハッシュメッセージ認証コード（HMAC）[RFC2104]で実装することができます。HMAC-SHA-256 [FIPS-SHS]そのような実装の代替案の1つの可能な選択肢です。注：HMAC-MD5 [RFC1321]を使用することは、f（）[RFC6151]では受け入れられないと見なされます。

Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message.

prefix：ICMPv6ルータ広告メッセージから学習されたSLAACに使用されるプレフィックス。

Net_Iface: The MAC address corresponding to the underlying network-interface card, in the case the link uses IEEE 802 link-layer identifiers. Employing the MAC address for this parameter (over the other suggested options in [RFC7217]) means that the regeneration of a randomized MAC address will result in a different temporary address.

net_iface：リンクがIEEE 802リンク層識別子を使用する場合、基礎となるネットワークインタフェースカードに対応するMACアドレス。このパラメータのMACアドレスを使用する（[RFC7217]の他の推奨オプションを介して）ランダム化されたMACアドレスの再生成は異なる一時アドレスをもたらすことを意味します。

Network_ID: Some network-specific data that identifies the subnet to which this interface is attached -- for example, the IEEE 802.11 Service Set Identifier (SSID) corresponding to the network to which this interface is associated. Additionally, "Simple Procedures for Detecting Network Attachment in IPv6" ("Simple DNA") [RFC6059] describes ideas that could be leveraged to generate a Network_ID parameter. This parameter SHOULD be employed if some form of "Network_ID" is available.

network_id：このインタフェースが添付されているサブネットを識別するネットワーク固有のデータ（たとえば、このインタフェースが関連付けられているネットワークに対応するIEEE 802.11サービスセット識別子（SSID）。また、「IPv6のネットワーク添付ファイルを検出するための簡単な手順」（「単純なDNA」）[RFC6059]は、Network_IDパラメータを生成するために活用できるアイデアを記述しています。いくつかの形式の「Network_ID」が利用可能である場合にこのパラメータを採用する必要があります。

Time: An implementation-dependent representation of time. One possible example is the representation in UNIX-like systems [OPEN-GROUP], which measure time in terms of the number of seconds elapsed since the Epoch (00:00:00 Coordinated Universal Time (UTC), 1 January 1970). The addition of the "Time" argument results in (statistically) different IIDs over time.

時間：時間の実装依存表現。1つの可能な例はUNIX様システム[Open-Group]での表現です。これは、Epoch（00:00:00 Cordinated Universal Time（UTC）、1970年1月1日）以降の秒数の観点から時間を測定します。「時間」引数の追加は、時間の経過とともに（統計的に）異なるIIDになります。

DAD_Counter: A counter that is employed to resolve the conflict where an unacceptable identifier has been generated. This can be result of Duplicate Address Detection (DAD), or step 3 below.

DAD_COUNTER：許容できない識別子が生成された競合を解決するために採用されているカウンタ。これは、重複アドレス検出（DAD）、または下記のステップ3の結果であり得る。

secret_key: A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits. It MUST be initialized to a pseudorandom number (see [RFC4086] for randomness requirements for security) when the operating system is "bootstrapped". The secret_key MUST NOT be employed for any other purpose than the one discussed in this section. For example, implementations MUST NOT employ the same secret_key for the generation of stable addresses [RFC7217] and the generation of temporary addresses via this algorithm.

secret_key：攻撃者が知られていない秘密鍵。秘密鍵は少なくとも128ビットであるべきです。オペレーティングシステムが「ブートストラップ」の場合は、疑似ランダム番号（セキュリティのランダム性要件については[RFC4086]を参照）に初期化する必要があります。secret_keyは、このセクションで説明したものよりも他の目的に採用されてはならない。たとえば、実装は、安定したアドレスの生成とこのアルゴリズムを介した一時アドレスの生成に同じSecret_Keyを使用してはなりません。

2. The IID is finally obtained by taking as many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit. See [RFC7136] for the necessary number of bits (i.e., the length of the IID). See also [RFC7421] for a discussion of the privacy implications of the IID length. Note: there are no special bits in an IID [RFC7136].

2. IIDは、最下位ビットから始めて、必要に応じてリッス値（前のステップで計算された）からの数のビットを取ることによって最終的に得られます。必要なビット数（すなわち、IIDの長さ）については、[RFC7136]を参照してください。IID長のプライバシーの影響については、[RFC7421]も参照してください。注：IIDの特別なビットはありません[RFC7136]。

3. The resulting IID MUST be compared against the reserved IPv6 IIDs [RFC5453] [IANA-RESERVED-IID] and against those IIDs already employed in an address of the same network interface and the same network prefix. In the event that an unacceptable identifier has been generated, the DAD_Counter should be incremented by 1, and the algorithm should be restarted from the first step.

3. 結果のIIDは、予約されたIPv6 IID [RFC5453] [IANA-Reserved-IID]と比較する必要があります。また、同じネットワークインターフェイスのアドレスと同じネットワークプレフィックスのアドレスにすでに採用されているIIDに対して比較する必要があります。許容できない識別子が生成された場合、DAD_COUNTERは1だけインクリメントされ、アルゴリズムは最初のステップから再起動されるべきです。

3.4. Generating Temporary Addresses

3.4. 一時アドレスの生成

[RFC4862] describes the steps for generating a link-local address when an interface becomes enabled, as well as the steps for generating addresses for other scopes. This document extends [RFC4862] as follows. When processing a Router Advertisement with a Prefix Information option carrying a prefix for the purposes of address autoconfiguration (i.e., the A bit is set), the host MUST perform the following steps:

[RFC4862]は、インターフェイスが有効になったとき、および他のスコープのアドレスを生成するためのステップとともに、リンクローカルアドレスを生成するための手順を説明しています。この文書は次のように[RFC4862]を拡張します。アドレス自動設定の目的のための接頭辞を持つプレフィックス情報オプションを使用してルータアドバタイズメントを処理する場合（すなわち、Aビットが設定されている）、ホストは次のステップを実行する必要があります。

1. Process the Prefix Information option as specified in [RFC4862], adjusting the lifetimes of existing temporary addresses, with the overall constraint that no temporary addresses should ever remain "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to the maximum valid lifetime and the maximum preferred lifetime of temporary addresses, respectively.

1. [RFC4862]で指定されているプレフィックス情報オプションをプロセスし、既存の一時アドレスの寿命を調整し、一時アドレスが「有効な」または「推奨」（TEMP_VALID_LIFETIME）または（TEMP_PREFERRED_LIFETIME - ）のままであることを示します。desync_factor）。構成変数TEMP_VALID_LIFETIMEおよびTEMP_PREFERRED_LIFETIMEは、それぞれ最大有効寿命と一時アドレスの最大好みの寿命に対応しています。

Note: DESYNC_FACTOR is the value computed when the address was created (see step 4 below).

注：desync_factorは、アドレスが作成されたときに計算された値です（下記の手順4を参照）。

2. One way an implementation can satisfy the above constraints is to associate with each temporary address a creation time (called CREATION_TIME) that indicates the time at which the address was created. When updating the preferred lifetime of an existing temporary address, it would be set to expire at whichever time is earlier: the time indicated by the received lifetime or (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A similar approach can be used with the valid lifetime.

2. 実装が上記の制約を満たすことができる1つの方法は、アドレスが作成された時刻を示す作成時刻（Creation_Timeと呼ばれる）を各一時アドレスに関連付けることです。既存の一時アドレスの優先寿命を更新する場合は、早い時期に期限切れになるように設定されます。受信されたライフタイムまたは（creation_time temp_preferred_lifetime - desync_factor）が示す時間有効な寿命と同様の方法を使用することができます。

Note: DESYNC_FACTOR is the value computed when the address was created (see step 4 below).

注：desync_factorは、アドレスが作成されたときに計算された値です（下記の手順4を参照）。

3. If the host has not configured any temporary address for the corresponding prefix, the host SHOULD create a new temporary address for such prefix.

3. ホストが対応するプレフィックスの一時アドレスを設定していない場合、ホストはそのようなプレフィックスの新しい一時アドレスを作成する必要があります。

Note: For example, a host might implement prefix-specific policies such as not configuring temporary addresses for the Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] prefix.

注：たとえば、ホストは、一意のローカルIPv6ユニキャストアドレス（ULAS）[RFC4193]プレフィックスの一時アドレスを設定しないなど、プレフィックス固有のポリシーを実装することがあります。

4. When creating a temporary address, DESYNC_FACTOR MUST be computed and associated with the newly created address, and the address lifetime values MUST be derived from the corresponding prefix as follows:

4. 一時アドレスを作成するときは、Desync_factorを計算して新しく作成されたアドレスに関連付けておく必要があり、アドレスの有効期間の値は次のように対応するプレフィックスから派生する必要があります。

* Its valid lifetime is the lower of the Valid Lifetime of the prefix and TEMP_VALID_LIFETIME.

* その有効な有効期間は、プレフィックスとTEMP_VALID_LIFETIMEの有効な有効期間の遅いです。

* Its preferred lifetime is the lower of the Preferred Lifetime of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.

* その優先寿命は、プレフィックスとTEMP_PREFERRED_LIFETIME - desync_factorの優先寿命の低い方です。

5. A temporary address is created only if this calculated preferred lifetime is greater than REGEN_ADVANCE time units. In particular, an implementation MUST NOT create a temporary address with a zero preferred lifetime.

5. 一時アドレスは、この計算された優先寿命がREGEN_ADVANCE時間単位より大きい場合にのみ作成されます。特に、実装は、ゼロ優先寿命を持つ一時アドレスを作成してはなりません。

6. New temporary addresses MUST be created by appending a randomized IID to the prefix that was received. Section 3.3 of this document specifies some sample algorithms for generating the randomized IID.

6. 新しい一時アドレスは、受信されたプレフィックスにランダム化されたIIDを追加することによって作成する必要があります。このドキュメントのセクション3.3は、ランダム化されたIIDを生成するためのいくつかのサンプルアルゴリズムを指定します。

7. The host MUST perform DAD on the generated temporary address. If DAD indicates the address is already in use, the host MUST generate a new randomized IID and repeat the previous steps as appropriate (starting from step 4), up to TEMP_IDGEN_RETRIES times. If, after TEMP_IDGEN_RETRIES consecutive attempts, the host is unable to generate a unique temporary address, the host MUST log a system error and SHOULD NOT attempt to generate a temporary address for the given prefix for the duration of the host's attachment to the network via this interface. This allows hosts to recover from occasional DAD failures or otherwise log the recurrent address collisions.

7. 生成された一時アドレスにホストはDADを実行する必要があります。DADがアドレスがすでに使用されていることを示す場合、ホストは新しいランダム化されたIIDを生成し、最適な（ステップ4からの開始）、temp_idgen_retries時間まで、前の手順を繰り返す必要があります。TEMP_IDGEN_RETRIESの連続した試行の後に、ホストは一意の一時アドレスを生成できない場合、ホストはシステムエラーを記録する必要があり、これを介してネットワークへのホストの添付ファイルの持続期間について特定のプレフィックスの一時アドレスを生成しようとしないでください。インターフェース。これにより、ホストは時折DADの障害から回復するか、またはその他の場合は繰り返しアドレスの衝突を記録できます。

3.5. Expiration of Temporary Addresses

3.5. 一時住所の有効期限

When a temporary address becomes deprecated, a new one MUST be generated. This is done by repeating the actions described in Section 3.4, starting at step 4). Note that, in normal operation, except for the transient period when a temporary address is being regenerated, at most one temporary address per prefix should be in a nondeprecated state at any given time on a given interface. Note that if a temporary address becomes deprecated as result of processing a Prefix Information option with a zero preferred lifetime, then a new temporary address MUST NOT be generated (in response to the same Prefix Information option). To ensure that a preferred temporary address is always available, a new temporary address SHOULD be regenerated slightly before its predecessor is deprecated. This is to allow sufficient time to avoid race conditions in the case where generating a new temporary address is not instantaneous, such as when DAD must be performed. The host SHOULD start the process of address regeneration REGEN_ADVANCE time units before a temporary address is deprecated.

一時アドレスが推奨されなくなると、新しいものを生成する必要があります。これは、ステップ4からのセクション3.4で説明されているアクションを繰り返すことによって行われます。なお、通常の動作では、一時アドレスが再生成されている過渡期間を除いて、プレフィックスごとに1つの一時アドレスが、特定のインタフェース上の任意の時間に非推奨状態にあるはずです。プレフィックス情報オプションをゼロゼロの有効期間で処理した結果として一時アドレスが推奨されている場合は、（同じ接頭辞情報オプションに応答して）新しい一時アドレスを生成しないでください。好ましい一時アドレスが常に利用可能であることを確認するために、その前任者が非推奨の前に新しい一時アドレスを少し再生成する必要があります。これは、DADを実行する必要がある場合など、新しい一時アドレスを瞬時に生成しない場合に、レース条件を回避するのに十分な時間を避けることです。一時アドレスが推奨される前に、ホストはアドレス再生REGEN_ADVANCE時間単位のプロセスを開始する必要があります。

As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper layers, as detailed in Section 6.

オプションの最適化として、実装は、セクション6に詳述されているように、アプリケーションまたは上位レイヤによって使用されていない廃止予定の一時アドレスを削除することができます。

3.6. Regeneration of Temporary Addresses

3.6. 一時住所の再生

The frequency at which temporary addresses change depends on how a device is being used (e.g., how frequently it initiates new communication) and the concerns of the end user. The most egregious privacy concerns appear to involve addresses used for long periods of time (from weeks to years). The more frequently an address changes, the less feasible collecting or coordinating information keyed on IIDs becomes. Moreover, the cost of collecting information and attempting to correlate it based on IIDs will only be justified if enough addresses contain non-changing identifiers to make it worthwhile. Thus, having large numbers of clients change their address on a daily or weekly basis is likely to be sufficient to alleviate most privacy concerns.

一時アドレスが変化する周波数は、デバイスがどのように使用されているか（例えば、どの程度の頻度が頻繁に開始される）およびエンドユーザの懸念によって異なる。最も大きな優れたプライバシーの懸念は、長期間使用されているアドレスを含むようです（数週間から年）。アドレスが変わるほど、IIDにキーが付与されていない可能性の低い収集または調整が少なくなる。さらに、情報を収集し、IIDに基づいて相関することを試みるコストは、十分なアドレスに変化しない識別子がある場合にのみ正当化されます。したがって、多数のクライアントが毎日または毎週の基準で住所を変更することは、ほとんどのプライバシーに関する懸念を軽減するのに十分である可能性があります。

There are also client costs associated with having a large number of addresses associated with a host (e.g., in doing address lookups, the need to join many multicast groups, etc.). Thus, changing addresses frequently (e.g., every few minutes) may have performance implications.

ホストに関連する多数のアドレスを有することに関連するクライアントコストも関連付けられている（例えば、アドレス検索を行うために、多くのマルチキャストグループに参加する必要性など）。したがって、アドレスを頻繁に（例えば、数分ごとに）変更すると、性能の影響があり得る。

Hosts following this specification SHOULD generate new temporary addresses over time. This can be achieved by generating a new temporary address REGEN_ADVANCE time units before a temporary address becomes deprecated. As described above, this produces addresses with a preferred lifetime no larger than TEMP_PREFERRED_LIFETIME. The value DESYNC_FACTOR is a random value computed when a temporary address is generated; it ensures that clients do not generate new addresses at a fixed frequency and that clients do not synchronize with each other and generate new addresses at exactly the same time. When the preferred lifetime expires, a new temporary address MUST be generated using the algorithm specified in Section 3.4 (starting at step 4).

この仕様に続くホストは、時間の経過とともに新しい一時アドレスを生成する必要があります。これは、一時アドレスが推奨される前に新しい一時アドレスREGEN_ADVANCE時間単位を生成することによって達成することができる。上述のように、これは、TEMP_PREFERRED_LIFETIMEよりも大きい好ましい寿命を有するアドレスを生成する。値desync_factorは、一時アドレスが生成されたときに計算された乱数値です。クライアントが固定頻度で新しいアドレスを生成しないこと、およびクライアントが互いに同期していないことを保証し、まったく同時に新しいアドレスを生成します。優先寿命が期限切れになると、セクション3.4（ステップ4から開始）で指定されたアルゴリズムを使用して新しい一時アドレスを生成する必要があります。

Because the frequency at which it is appropriate to generate new addresses varies from one environment to another, implementations SHOULD provide end users with the ability to change the frequency at which addresses are regenerated. The default value is given in TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time at which to invalidate a temporary address depends on how applications are used by end users. Thus, the suggested default value of two days (TEMP_VALID_LIFETIME) may not be appropriate in all environments. Implementations SHOULD provide end users with the ability to override both of these default values.

新しいアドレスを生成するのに適した頻度は、1つの環境から別の環境に異なるため、アドレスが再生成される周波数を変更する機能を持つエンドユーザーを提供する必要があります。デフォルト値はtemp_preferred_lifetimeで指定されており、1日です。さらに、一時アドレスを無効にするための正確な時間は、エンドユーザーによってアプリケーションがどのように使用されるかによって異なります。したがって、2日間の推奨されるデフォルト値（temp_valid_lifetime）は、すべての環境では適切ではない可能性があります。実装は、これらのデフォルト値の両方を上書きする機能を持つエンドユーザーを提供する必要があります。

Finally, when an interface connects to a new (different) link, existing temporary addresses for the corresponding interface MUST be removed, and new temporary addresses MUST be generated for use on the new link, using the algorithm in Section 3.4. If a device moves from one link to another, generating new temporary addresses ensures that the device uses different randomized IIDs for the temporary addresses associated with the two links, making it more difficult to correlate addresses from the two different links as being from the same host. The host MAY follow any process available to it to determine that the link change has occurred. One such process is described by "Simple DNA" [RFC6059]. Detecting link changes would prevent link down/up events from causing temporary addresses to be (unnecessarily) regenerated.

最後に、インターフェイスが新しい（別の）リンクに接続すると、対応するインターフェイスの既存の一時アドレスを削除する必要があり、セクション3.4のアルゴリズムを使用して、新しいリンクで新しい一時アドレスを使用する必要があります。デバイスがあるリンクから別のリンクに移動すると、新しい一時アドレスを生成すると、デバイスが2つのリンクに関連付けられている一時アドレスに異なるランダム化されたIIDを使用しているため、2つの異なるリンクからのアドレスを同じホストからのものとして相関させることが難しくなります。。ホストは、リンク変更が発生したと判断するために利用可能なプロセスに従うことができる。そのような方法の1つは、「単純なDNA」[RFC6059]によって記載されている。リンクの変更を検出すると、リンクダウン/アップイベントが一時アドレスを（不必要に）再生成されるのを防ぐことができます。

3.7. Implementation Considerations

3.7. 実装に関する考慮事項

Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. In addition, a site might wish to disable the use of temporary addresses in order to simplify network debugging and operations. Consequently, implementations SHOULD provide a way for trusted system administrators to enable or disable the use of temporary addresses.

この仕様を実装するデバイスは、エンドユーザーが一時アドレスの使用を明示的に有効または無効にする方法を提供する必要があります。さらに、サイトは、ネットワークデバッグと操作を簡素化するために一時アドレスの使用を無効にしたい場合があります。したがって、実装は、信頼できるシステム管理者が一時アドレスの使用を有効または無効にする方法を提供する必要があります。

Additionally, sites might wish to selectively enable or disable the use of temporary addresses for some prefixes. For example, a site might wish to disable temporary-address generation for ULA [RFC4193] prefixes while still generating temporary addresses for all other prefixes advertised via PIOs for address configuration. Another site might wish to enable temporary-address generation only for the prefixes 2001:db8:1::/48 and 2001:db8:2::/48 while disabling it for all other prefixes. To support this behavior, implementations SHOULD provide a way to enable and disable generation of temporary addresses for specific prefix subranges. This per-prefix setting SHOULD override the global settings on the host with respect to the specified prefix subranges. Note that the per-prefix setting can be applied at any granularity, and not necessarily on a per-subnet basis.

さらに、サイトは、いくつかの接頭辞の一時アドレスの使用を選択的に有効または無効にしたいと思うかもしれません。たとえば、Siteは、Address構成のPIOSでアドバタイズされた他のすべてのプレフィックスの一時アドレスを生成している間に、ULA [RFC4193]のプレフィックスの一時アドレス生成を無効にしたい場合があります。他のサイトは、他のすべてのプレフィックスの場合は、Prefixes 2001：DB8：1 :: / 48および2001：DB8：2 :: / 48にのみ一時アドレスの生成を有効にしたい場合があります。この動作をサポートするために、実装は特定のプレフィックスサブレンジの一時アドレスの生成を有効および無効にする方法を提供する必要があります。このプレフィックスごとの設定は、指定されたプレフィックスサブレンジに関してホスト上のグローバル設定をオーバーライドする必要があります。プレフィックスごとの設定は、必ずしもサブネットごとには必ずしも適用できません。

3.8. Defined Protocol Parameters and Configuration Variables

3.8. 定義されたプロトコルパラメータと構成変数

Protocol parameters and configuration variables defined in this document include:

このドキュメントで定義されているプロトコルパラメータと構成変数は次のとおりです。

TEMP_VALID_LIFETIME Default value: 2 days. Users should be able to override the default value.

TEMP_VALID_LIFETIMEのデフォルト値：2日。ユーザーはデフォルト値を上書きできるはずです。

TEMP_PREFERRED_LIFETIME Default value: 1 day. Users should be able to override the default value. Note: The TEMP_PREFERRED_LIFETIME value MUST be smaller than the TEMP_VALID_LIFETIME value, to avoid the pathological case where an address is employed for new communications but becomes invalid in less than 1 second, disrupting those communications.

TEMP_PREFERRED_LIFETIMEのデフォルト値：1日。ユーザーはデフォルト値を上書きできるはずです。注：TEMP_PREFERRED_LIFETIME値は、アドレスが新しい通信に使用されているが1秒未満で無効で、それらの通信を中断しても無効になるという意味を避けるために、TEMP_VALID_LIFETIME値より小さくなければなりません。

REGEN_ADVANCE 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits * RetransTimer / 1000)

REGEN_ADVANCE 2（TEMP_IDGEN_RETRIES * DUPADDRDETECTTRANSMITS * RETRANSTIMER / 1000）

      |  Rationale: This parameter is specified as a function of other
      |  protocol parameters, to account for the time possibly spent in
      |  DAD in the worst-case scenario of TEMP_IDGEN_RETRIES.  This
      |  prevents the pathological case where the generation of a new
      |  temporary address is not started with enough anticipation, such
      |  that a new preferred address is generated before the currently
      |  preferred temporary address becomes deprecated.
      |
      |  RetransTimer is specified in [RFC4861], while
      |  DupAddrDetectTransmits is specified in [RFC4862].  Since
      |  RetransTimer is specified in units of milliseconds, this
      |  expression employs the constant "1000", such that REGEN_ADVANCE
      |  is expressed in seconds.

MAX_DESYNC_FACTOR 0.4 * TEMP_PREFERRED_LIFETIME. Upper bound on DESYNC_FACTOR.

MAX_DESYNC_FACTOR 0.4 * TEMP_PREFERRED_LIFETIME。desync_factorの上限。

      |  Rationale: Setting MAX_DESYNC_FACTOR to 0.4
      |  TEMP_PREFERRED_LIFETIME results in addresses that have
      |  statistically different lifetimes, and a maximum of three
      |  concurrent temporary addresses when the default values
      |  specified in this section are employed.

DESYNC_FACTOR A random value within the range 0 - MAX_DESYNC_FACTOR. It is computed each time a temporary address is generated, and is associated with the corresponding address. It MUST be smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).

desysc_factor範囲0 - max_desync_factorの範囲内のランダム値。一時アドレスが生成されるたびに計算され、対応するアドレスに関連付けられています。（temp_preferred_lifetime - regen_advance）より小さくなければなりません。

TEMP_IDGEN_RETRIES Default value: 3

temp_idgen_retriesデフォルト値：3

4. Implications of Changing IIDs

4. 変更IIDSの意味

The desire to protect individual privacy can conflict with the desire to effectively maintain and debug a network. Having clients use addresses that change over time will make it more difficult to track down and isolate operational problems. For example, when looking at packet traces, it could become more difficult to determine whether one is seeing behavior caused by a single errant host or a number of them.

個々のプライバシーを保護したいという願望は、ネットワークを効果的に維持してデバッグするという要望と競合する可能性があります。クライアントを使用すると、時間が経過するアドレスを使用すると、運用上の問題を追跡して分離することがより困難になります。たとえば、パケットトレースを見ると、単一の誤ったホストまたはそれらの数によって引き起こされる動作が発生しているかどうかを判断することがより困難になる可能性があります。

It is currently recommended that network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts [RFC7934]. However, in some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that need to maintain entries for each IPv6 address in some data structures (e.g., SAVI [RFC7039]). For example, concurrent active use of multiple IPv6 addresses will increase Neighbor Discovery traffic if Neighbor Caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (see e.g., [MCAST-PROBLEMS]). Additionally, some network-security devices might incorrectly infer IPv6 address forging if temporary addresses are regenerated at a high rate.

現在、ネットワーク展開は各接頭辞から汎用ホストへの複数のIPv6アドレスを提供することをお勧めします[RFC7934]。ただし、いくつかのシナリオでは、多数のIPv6アドレスを使用すると、データ構造（例えば、Savi [RFC7039]）で各IPv6アドレスのエントリを維持する必要があるネットワークデバイスに否定的な影響があります。たとえば、ネットワークデバイス内のネイバーキャッシュがすべてのアドレスを保存するのに十分な大きさでない場合、複数のIPv6アドレスを同時にアクティブに使用すると、ネイバーディスカバリトラフィックが増加します。これは、マルチキャストが高価であるネットワーク上でパフォーマンスとエネルギー効率に影響を与える可能性があります（例えば、[MCAST-DOWASS）。さらに、一部のネットワークセキュリティデバイスは、一時アドレスが高いレートで再生成されている場合、IPv6アドレス鍛造を誤って推測する可能性があります。

The use of temporary addresses may cause unexpected difficulties with some applications. For example, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. That is, they perform a DNS PTR query to determine the DNS name corresponding to an IPv6 address, and may then also perform a AAAA query on the returned name to verify it maps back into the same address. Consequently, clients not properly registered in the DNS may be unable to access some services. However, a host's DNS name (if non-changing) would serve as a constant identifier. The wide deployment of the extension described in this document could challenge the practice of inverse-DNS-based "validation", which has little validity, though it is widely implemented. In order to meet server challenges, hosts could register temporary addresses in the DNS using random names (for example, a string version of the random address itself), albeit at the expense of increased complexity.

一時アドレスの使用は、いくつかのアプリケーションで予期しない困難を引き起こす可能性があります。たとえば、一部のサーバーは、IPアドレスをDNS名にマップできないクライアントからの通信を受け入れることを拒否します。すなわち、それらは、IPv6アドレスに対応するDNS名を決定するためにDNS PTRクエリを実行し、それが同じアドレスにマップされることを確認するために返された名前でAAAAクエリを実行することもできる。その結果、DNSに正しく登録されていないクライアントは、一部のサービスにアクセスできない場合があります。ただし、ホストのDNS名（変更されていない場合）は定数識別子として機能します。この文書に記載されている延長部の広い展開は、広く実装されていますが、妥当性はほとんどありません。サーバーの課題を満たすために、ホストは、複雑さの向上を犠牲にして、ランダムな名前（たとえば、ランダムアドレス自体の文字列バージョン）を使用してDNSに一時アドレスを登録できます。

In addition, some applications may not behave robustly if an address becomes invalid while it is still in use by the application or if the application opens multiple sessions and expects them to all use the same address.

さらに、アプリケーションがまだ使用されていない間、またはアプリケーションが複数のセッションを開いても同じアドレスを使用している場合は、アドレスが無効になっている場合、アプリケーションによっては堅牢に動作しない可能性があります。

[RFC4941] employed a randomized temporary IID for generating a set of temporary addresses, such that temporary addresses configured at a given time for multiple SLAAC prefixes would employ the same IID. Sharing the same IID among multiple addresses allowed a host to join only one solicited-node multicast group per temporary address set.

[RFC4941]一組の一時アドレスを生成するためのランダム化された一時的なIIDを使用して、複数のSLAACプレフィックスのために所与の時間に設定された一時アドレスが同じIIDを使用するであろう。複数のアドレスの間で同じIIDを共有することで、一時アドレスセットごとにホストが1つの要求ノードマルチキャストグループのみに参加できるようになりました。

This document requires that the IIDs of all temporary addresses on a host are statistically different from each other. This means that when a network employs multiple prefixes, each temporary address of a set will result in a different solicited-node multicast address, and, thus, the number of multicast groups that a host must join becomes a function of the number of SLAAC prefixes employed for generating temporary addresses.

この文書では、ホスト上のすべての一時アドレスのIIDが互いに統計的に異なることが必要です。つまり、ネットワークが複数のプレフィックスを採用している場合、セットの各一時アドレスは異なる要求ノードマルチキャストアドレスをもたらし、したがってホストが参加しなければならないマルチキャストグループの数がSLAACプレフィックスの数の関数になります。一時アドレスを生成するために採用されています。

Thus, a network that employs multiple prefixes may require hosts to join more multicast groups than in the case of implementations of RFC 4941. If the number of multicast groups were large enough, a host might need to resort to setting the network interface card to promiscuous mode. This could cause the host to process more packets than strictly necessary and might have a negative impact on battery life and system performance in general.

したがって、複数のプレフィックスを使用するネットワークでは、RFC 4941の実装の場合よりも多くのマルチキャストグループを結合する必要があるかもしれません。マルチキャストグループの数が十分に大きい場合、ホストはネットワークインタフェースカードの設定を無差別に設定する必要があるかもしれません。モード。これにより、ホストが厳密に必要なよりも多くのパケットを処理する可能性があり、一般的なバッテリ寿命とシステム性能に悪影響を及ぼします。

We note that since this document reduces the default TEMP_VALID_LIFETIME from 7 days (in [RFC4941]) to 2 days, the number of concurrent temporary addresses per SLAAC prefix will be smaller than for RFC 4941 implementations; thus, the number of multicast groups for a network that employs, say, between 1 and 3 prefixes, will be similar to the number of such groups for RFC 4941 implementations.

この文書は7日から2日までのデフォルトのtemp_valid_lifetimeを減少させるため、SLAACプレフィックスごとの同時一時アドレスの数はRFC 4941実装よりも小さくなります。したがって、1~3のプレフィックスを使用するネットワークのマルチキャストグループの数は、RFC 4941実装のためのそのようなグループの数と同様になります。

Implementations concerned with the maximum number of multicast groups that would be required to join as a result of configured addresses, or the overall number of configured addresses, should consider enforcing implementation-specific limits on, e.g., the maximum number of configured addresses, the maximum number of SLAAC prefixes that are employed for autoconfiguration, and/or the maximum ratio for TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (which ultimately controls the approximate number of concurrent temporary addresses per SLAAC prefix). Many of these configuration limits are readily available in SLAAC and RFC 4941 implementations. We note that these configurable limits are meant to prevent pathological behaviors (as opposed to simply limiting the usage of IPv6 addresses), since IPv6 implementations are expected to leverage the usage of multiple addresses [RFC7934].

設定されたアドレスの結果として結合する必要があるマルチキャストグループの最大数、または設定されたアドレスの全体数は、実装固有の制限を強制することを検討する必要があります。自動設定に使用されるSLAACプレフィックスの数、および/またはTEMP_VALID_LIFETIME / TEMP_PREFERRED_LIFETIMEの最大値（最終的には、SLAACプレフィックスごとの並行時一時アドレスのおおよそ）を制御します。これらの構成の制限の多くは、SLAACおよびRFC 4941の実装では容易に入手できます。これらの設定可能な制限は、IPv6の実装が複数のアドレスの使用法を活用することが期待されるため、（IPv6アドレスの使用とは対照的に）病理学的動作を防ぐことを目的としています。

5. Significant Changes from RFC 4941

5. RFC 4941からの有意な変化

This section summarizes the substantive changes in this document relative to RFC 4941.

このセクションでは、RFC 4941に対するこの文書の実質的な変更をまとめたものです。

Broadly speaking, this document introduces the following changes:

大まかに言って、この文書は次の変更を紹介します。

* Addresses a number of flaws in the algorithm for generating temporary addresses. The aforementioned flaws include the use of MD5 for computing the temporary IIDs, and reusing the same IID for multiple prefixes (see [RAID2015] and [RFC7721] for further details).

* 一時アドレスを生成するためのアルゴリズム内のいくつかの欠陥を取り扱っています。前述の欠陥は、一時的なIIDを計算するためのMD5の使用を含み、複数の接頭辞のために同じIIDを再利用すること（さらなる詳細については[RAID2015]および[RFC7721]を参照）。

* Allows hosts to employ only temporary addresses. [RFC4941] assumed that temporary addresses were configured in addition to stable addresses. This document does not imply or require the configuration of stable addresses; thus, implementations can now configure both stable and temporary addresses or temporary addresses only.

* ホストが一時アドレスのみを使用できるようにします。[RFC4941]安定したアドレスに加えて一時アドレスが構成されていると仮定しました。この文書は安定したアドレスの構成を意味するか、または必要としていません。したがって、実装は安定したアドレスと一時アドレスのみを設定できるようになりました。

* Removes the recommendation that temporary addresses be disabled by default. This is in line with BCP 188 ([RFC7258]) and also with BCP 204 ([RFC7934]).

* デフォルトで一時アドレスを無効にする推奨を削除します。これはBCP 188（[RFC7258]）とBCP 204（[RFC7934]）と並んでいます。

* Reduces the default maximum valid lifetime for temporary addresses (TEMP_VALID_LIFETIME). TEMP_VALID_LIFETIME has been reduced from 1 week to 2 days, decreasing the typical number of concurrent temporary addresses from 7 to 3. This reduces the possible stress on network elements (see Section 4 for further details).

* 一時アドレス（TEMP_VALID_LIFETIME）のデフォルトの最大有効な有効期間を短縮します。TEMP_VALID_LIFETIMEは1週間から2日まで減少し、7から3の同時の一時アドレスの典型的な数を減らしました。これにより、ネットワーク要素に起こり得る応力が減少します（詳細についてはセクション4を参照）。

* DESYNC_FACTOR is computed each time a temporary address is generated and is associated with the corresponding temporary address, such that each temporary address has a statistically different preferred lifetime, and thus temporary addresses are not generated at any specific frequency.

* desync_factorは、一時アドレスが生成されるたびに計算され、各一時アドレスが統計的に異なる優先寿命を持ち、したがって一時アドレスが特定の周波数では生成されないように、対応する一時アドレスに関連付けられます。

* Changes the requirement to not try to regenerate temporary addresses upon TEMP_IDGEN_RETRIES consecutive DAD failures from "MUST NOT" to "SHOULD NOT".

* TEMP_IDGEN_RETRIESの一時アドレスを再生成しようとしないという条件を変更してください。

* The discussion about the security and privacy implications of different address generation techniques has been replaced with references to recent work in this area ([RFC7707], [RFC7721], and [RFC7217]).

* さまざまなアドレス生成技術のセキュリティとプライバシーの影響についての議論は、この分野での最近の作業への参照に置き換えられました（[RFC7707]、[RFC7721]、[RFC7217]）。

* This document incorporates errata submitted (at the time of writing) for [RFC4941] by Jiri Bohac and Alfred Hoenes.

* この文書には、Jiri BohacとAlfred Hoenesによって[RFC4941]の場合（書き込み時に）エラータが投入されました。

6. Future Work

6. 将来の仕事

An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper-layer protocols are using it (but not before). This is in contrast to current approaches, where addresses are removed from an interface when they become invalid [RFC4862], independent of whether or not upper-layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when an address is no longer in use.

実装は、上位データ構造から廃止予定の一時アドレスを使用することができるようにして、上位層のプロトコルが使用されていない（以前はそうではない）、どのアドレスを上位層で使用するかを追跡することをお勧めします。これは現在のアプローチとは対照的です。ここで、上位層プロトコルがまだ使用されているかどうかに関係なく、無効な[RFC4862]になるとアドレスがインタフェースから削除されます。TCP接続の場合、そのような情報は制御ブロックで利用可能です。UDPベースのアプリケーションの場合、アプリケーションのみが実際にどのアドレスが使用されているかについての知識がある場合があります。その結果、実装は一般的にアドレスが使用されなくなったときに決定する際にヒューリスティックを使用する必要があるでしょう。

7. IANA Considerations

7. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

8. Security Considerations

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

If a very small number of hosts (say, only one) use a given prefix for extended periods of time, just changing the interface-identifier part of the address may not be sufficient to mitigate address-based network-activity correlation, since the prefix acts as a constant identifier. The procedures described in this document are most effective when the prefix is reasonably nonstatic or used by a fairly large number of hosts. Additionally, if a temporary address is used in a session where the user authenticates, any notion of "privacy" for that address is compromised for the party or parties that receive the authentication information.

非常に少数のホスト（あるいは1つだけ）が長期間にわたって指定されたプレフィックスを使用する場合、アドレスのインタフェース識別子部分を変更するだけでは、プレフィックス以降、アドレスベースのネットワークアクティビティ相関を軽減するのに十分ではない可能性があります。定数識別子として機能します。この文書に記載されている手順は、接頭辞がかなり非堅調であるか、かなり多数のホストによって使用されている場合に最も効果的です。さらに、ユーザが認証するセッションで一時アドレスが使用されている場合、そのアドレスに対する「プライバシー」の概念は、認証情報を受信するパーティーまたはパーティーのために妥協されています。

While this document discusses ways to limit the lifetime of interface identifiers to reduce the ability of attackers to perform address-based network-activity correlation, the method described is believed to be ineffective against sophisticated forms of traffic analysis. To increase effectiveness, one may need to consider the use of more advanced techniques, such as onion routing [ONION].

この文書では、攻撃者がアドレスベースのネットワーク活動相関を実行する能力を低減するためのインタフェース識別子の寿命を制限する方法について説明していますが、記載された方法は、洗練された形態のトラフィック分析に対して無効であると考えられています。有効性を高めるためには、タマネギルーティング[玉ねぎ]のようなより高度な技術の使用を考慮する必要があるかもしれません。

Ingress filtering has been and is being deployed as a means of preventing the use of spoofed source addresses in Distributed Denial of Service (DDoS) attacks. In a network with a large number of hosts, new temporary addresses are created at a fairly high rate. This might make it difficult for ingress-/egress-filtering mechanisms to distinguish between legitimately changing temporary addresses and spoofed source addresses, which are "in-prefix" (using a topologically correct prefix and nonexistent interface identifier). This can be addressed by using access-control mechanisms on a per-address basis on the network ingress point -- though, as noted in Section 4, there are corresponding costs for doing so.

入力フィルタリングは、分散サービス拒否（DDOS）攻撃における偽装された送信元アドレスの使用を防止する手段として展開されています。多数のホストを持つネットワークでは、新しい一時アドレスがかなり高いレートで作成されます。これにより、入力 - /出力フィルタリングメカニズムに「プレフィックス内」（トポロジ的に正しいプレフィックスと存在しないインターフェース識別子を使用して）が合法的に変更された、または偽装された送信元アドレスを区別することが困難になる可能性があります。これは、ネットワーク入力ポイントでアドレスごとにアクセス制御メカニズムを使用することで対処できます。ただし、セクション4に記載されているように、そうするための対応するコストがあります。

9. References

9. 参考文献

9.1. Normative References

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, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。

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

[RFC4193] Hinden、R.およびB.B.Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https：//www.rfc-editor.org/info/rfc4193>。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。

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

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<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>.

[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。

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

[RFC5453] Krishnan、S。、「予約IPv6インタフェース識別子」、RFC 5453、DOI 10.17487 / RFC5453、2009年2月、<https：//www.rfc-editor.org/info/rfc5453>。

[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.

[RFC6724] Thaler、D.、ED。、Draves、R.、Matsumoto、A.、T. Chown、「インターネットプロトコルバージョン6のデフォルトアドレス選択（IPv6）」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月<https：//www.rfc-editor.org/info/rfc6724>。

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

[RFC7136] Carpenter、B.およびS. Jiang、「IPv6インタフェース識別子の有意性」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<https：//www.rfc-editor.org/info/rfc7136>。

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

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

9.2. Informative References

9.2. 参考引用

[BLAKE3] O'Connor, J., Aumasson, J. P., Neves, S., and Z. Wilcox-O'Hearn, "BLAKE3: one function, fast everywhere", 2020, <https://blake3.io/>.

[Blake3] O'Connor、J.、Aumasson、JP、Neves、S.、およびZ.Wilcox-O'Hearn、 "Blake3：1つの機能、Fast Every Anerywhere"、2020、<https://blake3.io/>。

[FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

[FIPS-SHS] NIST、「セキュアハッシュスタンダード（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https：//nvlpubs.nist.gov/nistpubs/fips/ nist.fips.180-4.pdf>。

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

[IANA-Resiver-IID] IANA、「予約IPv6インターフェイス識別子」、<https：//www.iana.org/ashignments/ipv6-Interface -ids>。

[MCAST-PROBLEMS] Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and J. C. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, Internet-Draft, draft-ietf-mboned-ieee802-mcast-problems-13, 4 February 2021, <https://tools.ietf.org/html/draft-ietf-mboned-ieee802- mcast-problems-13>.

[MCAST-課題] Perkins、CE、McBride、M.、Stanley、D.、Kumari、W.およびJC Zuniga、「IEEE 802無線メディアに対するマルチキャスト検討」、進行中の作業、インターネットドラフト、ドラフトIETF-mboned-ieee802-mcast-ions-13,13,4,4,4,4,4,14,14,14,14、<https：//tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-ageso-13>。

[ONION] Reed, M.G., Syverson, P.F., and D.M. Goldschlag, "Proxies for Anonymous Routing", Proceedings of the 12th Annual Computer Security Applications Conference, DOI 10.1109/CSAC.1996.569678, December 1996, <https://doi.org/10.1109/CSAC.1996.569678>.

【玉石】リード、m。、Syserson、P.F.およびD.M.Goldschlag、「匿名ルーティングのプロキシ」、第12回コンピュータセキュリティアプリケーション会議、DOI 10.1109 / CSAC.1996.569678、1996年12月、<https：//doi.org/10.1109/csac.1996.569678>。

[OPEN-GROUP] The Open Group, "The Open Group Base Specifications Issue 7", Section 4.16 Seconds Since the Epoch, IEEE Std 1003.1, 2016, <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ contents.html>.

[Open-Group]オープングループ「オープングループベース仕様発行7」、エポック、IEEE STD 1003.1,2016、<http://pubs.opengroup.org/onlinepubs/9699919799 / basedefs/内容.html>。

[RAID2015] Ullrich, J. and E.R. Weippl, "Privacy is Not an Option: Attacking the IPv6 Privacy Extension", International Symposium on Recent Advances in Intrusion Detection (RAID), 2015, <https://publications.sba-research.org/publications/Ullrich2015Privacy.pdf>.

[RAID2015] Ullrich、J.およびER Weippl、「プライバシーは、IPv6プライバシー拡張の攻撃」、侵入検知（RAID）、2015、<HTTPS：//publications.sba-research。ORG /出版物/ ullrich2015privacy.pdf>。

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

[RFC1321] RIVEST、R。、「MD5メッセージ - ダイジェストアルゴリズム」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<https：//www.rfc-editor.org/info/rfc1321>。

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2104] Krawczyk、H.、Bellare、M.、およびR. Canetti、 "HMAC：メッセージ認証用keyed-hashing"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

[RFC4941] Narten、T.、Draves、R.およびS.Krishnan、「IPv6のステートレスアドレス自動設定のためのプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：///www.rfc-編集者.ORG / INFO / RFC4941>。

[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, <https://www.rfc-editor.org/info/rfc5014>.

[RFC5014] Nordmark、E.、Chakrabarti、S.、J.Laganier、「Source Address Selection for Source Address Selection for Source Address Selection for Source Socket API」、RFC 5014、DOI 10.17487 / RFC5014、2007年9月、<https：///www.rfc-editor。ORG / INFO / RFC5014>。

[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <https://www.rfc-editor.org/info/rfc6059>.

[RFC6059] Krishnan、S.およびG. Daley、「IPv6のネットワークアタッチメントを検出するための簡単な手順」、RFC 6059、DOI 10.17487 / RFC6059、2010年11月、<https：//www.rfc-editor.org/info/rfc6059>。

[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, <https://www.rfc-editor.org/info/rfc6151>.

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

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[RFC6265] BARTH、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<https：//www.rfc-editor.org/info/rfc6265>。

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

[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F.、およびC. Vogt、Ed。、「Source Address検証改善（SAVI）フレームワーク」、RFC 7039、DOI 10.17487 / RFC7039、2013年10月、<https://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, <https://www.rfc-editor.org/info/rfc7217>.

[RFC7217] Gont、F. "IPv6ステートレスアドレス自動設定（SLAAC）"、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<https://ww.rfc-editor.org/ info / rfc7217>。

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7258] Farrell、S.およびH.Tschofenig、「Pervasive Monitoringは攻撃」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https：//www.rfc-editor.org/info/rfc7258>。

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

[RFC7421]大工、B.、ED。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。yourtchenko、「IPv6アドレス指定における64ビット境界の解析」、RFC7421、DOI 10.17487 / RFC7421、2015年1月、<https：//www.rfc-editor.org/info/rfc7421>。

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

[RFC7707] Gont、F.およびT. Chown、「IPv6ネットワークにおけるネットワーク偵察」、RFC 7707、DOI 10.17487 / RFC7707、2016年3月、<https：//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, <https://www.rfc-editor.org/info/rfc7721>.

[RFC7721] Cooper、A.、Gont、F.、およびD.Thaler、「IPv6アドレス生成メカニズムのためのセキュリティとプライバシーに関する考察」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：///www.rfc-Editor.org/info/rfc7721>。

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

[RFC7934] Colitti、L.、Cerf、V.、Cheshire、S.、およびD.Schinazi、「ホストアドレス在庫状況推奨事項」、BCP 204、RFC 7934、DOI 10.17487 / RFC7934、2016年7月、<HTTPS：// WWW.rfc-editor.org / info / rfc7934>。

[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, <https://www.rfc-editor.org/info/rfc8190>.

[RFC8190]ボニャ、R.、綿、M.、Haberman、B.、およびL. Vegoda、「特殊目的IPアドレス登録への更新」、BCP 153、RFC 8190、DOI 10.17487 / RFC8190、2017年6月、<https://www.rfc-editor.org/info/rfc8190>。

Acknowledgments

謝辞

Fernando Gont was the sole author of this document (a revision of RFC 4941). He would like to thank (in alphabetical order) Fred Baker, Brian Carpenter, Tim Chown, Lorenzo Colitti, Roman Danyliw, David Farmer, Tom Herbert, Bob Hinden, Christian Huitema, Benjamin Kaduk, Erik Kline, Gyan Mishra, Dave Plonka, Alvaro Retana, Michael Richardson, Mark Smith, Dave Thaler, Pascal Thubert, Ole Troan, Johanna Ullrich, Eric Vyncke, Timothy Winters, and Christopher Wood for providing valuable comments on earlier draft versions of this document.

Fernandoはこの文書の唯一の著者でした（RFC 4941の改訂）。彼はありがとうございました（アルファベット順に）フレッドベイカー、ブライアン大工、ローマンジョウン、ローマのダニーリ、デビッド農家、トムハーバート、ボブ・ハンダー、クリスチャン・ハイテマ、ベンジャミン・カドゥク、レイク・クライン、Gyan Mishra、Dave Plonka、Alvaroretana、Michael Richardson、Mark Smith、Dave Thaler、Pascal Thubert、Ole Troan、Johanna Ullrich、Eric Vyncke、Timothy Winters、およびChristopher Woodがこのドキュメントの以前のドラフトバージョンについて貴重なコメントを提供します。

This document incorporates errata submitted for RFC 4941 by Jiri Bohac and Alfred Hoenes (at the time of writing).

この文書には、JIRI BohacとAlfred Hoenes（書面時）によってRFC 4941に提出された正誤表が組み込まれています。

Suresh Krishnan was the sole author of RFC 4941 (a revision of RFC 3041). He would like to acknowledge the contributions of the IPv6 Working Group and, in particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their detailed comments.

Suresh KrishnanはRFC 4941の唯一の著者でした（RFC 3041の改訂）。彼は、IPv6ワーキンググループ、特にJari Arkko、Pekka Nikander、Pekka Savola、Francis Dupont、Brian Haberman、Tatuya Jinmei、およびMargaret Wassermanの貢献をご了承ください。

Rich Draves and Thomas Narten were the authors of RFC 3041. They would like to acknowledge the contributions of the IPv6 Working Group and, in particular, Ran Atkinson, Matt Crawford, Steve Deering, Allison Mankin, and Peter Bieringer.

RFC 3041の著者である。

Authors' Addresses

著者の住所

Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autonoma de Buenos Aires Argentina

Fernando Gont Si 6 Networks Segurola y Habana 4310,7mo Piso Villa Devoto Ciudad Autoloma de Buenos Airesアルゼンチン

   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com

Suresh Krishnan Kaloom

   Email: suresh@kaloom.com

Thomas Narten

   Email: narten@cs.duke.edu

Richard Draves Microsoft Research One Microsoft Way Redmond, WA United States of America

Richard Draves Microsoft Research One Microsoft Way Redmond、WAアメリカ合衆国

   Email: richdr@microsoft.com