[要約] RFC 8065は、IPv6適応層メカニズムのプライバシーに関する考慮事項についての要約です。このRFCの目的は、IPv6適応層メカニズムの設計と実装において、プライバシー保護を考慮することです。
Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 8065 Microsoft
Category: Informational February 2017
ISSN: 2070-1721
Privacy Considerations for IPv6 Adaptation-Layer Mechanisms
IPv6適応層メカニズムのプライバシーに関する考慮事項
Abstract
概要
This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.
このドキュメントでは、さまざまなリンク層プロトコルを介してIPv6用に設計されたテクノロジーに多くのプライバシーの脅威がどのように適用されるかについて説明し、そのようなリンクを介したIPv6のアダプテーション層仕様でそのような脅威に対処する方法についてプロトコル設計者にアドバイスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8065.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8065で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Amount of Entropy Needed in Global Addresses . . . . . . . . 3
3. Potential Approaches . . . . . . . . . . . . . . . . . . . . 4
3.1. IEEE-Identifier-Based Addresses . . . . . . . . . . . . . 5
3.2. Short Addresses . . . . . . . . . . . . . . . . . . . . . 5
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
RFC 6973 [RFC6973] discusses privacy considerations for Internet protocols, and Section 5.2 of that document covers a number of privacy-specific threats. In the context of IPv6 addresses, Section 3 of [RFC7721] provides further elaboration on the applicability of the privacy threats.
RFC 6973 [RFC6973]は、インターネットプロトコルのプライバシーに関する考慮事項を説明しており、そのドキュメントのセクション5.2は、プライバシー固有の脅威の数をカバーしています。 IPv6アドレスのコンテキストでは、[RFC7721]のセクション3で、プライバシーの脅威の適用性についてさらに詳しく説明しています。
When interface identifiers (IIDs) are generated without sufficient entropy compared to the link lifetime, devices and users can become vulnerable to the various threats discussed there, including:
リンクの有効期間と比較して十分なエントロピーなしにインターフェイス識別子（IID）が生成されると、デバイスとユーザーは、そこで説明されているさまざまな脅威に対して脆弱になる可能性があります。
o Correlation of activities over time, if the same identifier is used for traffic over period of time
o 一定の期間のトラフィックに同じ識別子が使用されている場合の、一定期間のアクティビティの相関関係
o Location tracking, if the same interface identifier is used with different prefixes as a device moves between different networks
o デバイスが異なるネットワーク間を移動するときに、同じインターフェース識別子が異なるプレフィックスで使用される場合の位置追跡
o Device-specific vulnerability exploitation, if the identifier helps identify a vendor or version or protocol and hence suggests what types of attacks to try
o デバイス固有の脆弱性の悪用（識別子がベンダー、バージョン、またはプロトコルの識別に役立ち、したがって試行する攻撃の種類を示唆する場合）
o Address scanning, which enables all of the above attacks by off-link attackers. (On some Non-Broadcast Multi-Access (NBMA) links where all nodes aren't already privy to all on-link addresses, address scans might also be done by on-link attackers; however, in most cases, address scans are not an interesting threat from on-link attackers and thus address scans generally apply only to routable addresses.)
o オフリンク攻撃者による上記のすべての攻撃を可能にするアドレススキャン。 （一部の非ブロードキャストマルチアクセス（NBMA）リンクでは、すべてのノードがまだすべてのオンリンクアドレスにアクセスできない場合、アドレススキャンはオンリンク攻撃者によっても行われる可能性がありますが、ほとんどの場合、アドレススキャンは行われませんリンク上の攻撃者からの興味深い脅威、つまりアドレススキャンは、一般にルーティング可能なアドレスにのみ適用されます。）
For example, for links that may last for years, "enough" bits of entropy means at least 46 or so bits (see Section 2 for why) in a routable address; ideally all 64 bits of the IID should be used, although historically some bits have been excluded for reasons discussed in [RFC7421]. Link-local addresses can also be susceptible to the same privacy threats from off-link attackers, since experience shows they are often leaked by upper-layer protocols such as SMTP, SIP, or DNS.
たとえば、何年も続く可能性のあるリンクの場合、エントロピーの「十分な」ビットは、ルーティング可能なアドレスで少なくとも46ビット程度（理由についてはセクション2を参照）を意味します。理想的には、IIDのすべての64ビットを使用する必要がありますが、歴史的に[RFC7421]で説明されている理由により、一部のビットは除外されています。リンクローカルアドレスは、SMTP、SIP、DNSなどの上位層プロトコルによってリークされることが多いため、リンク外の攻撃者からの同じプライバシーの脅威の影響を受ける可能性もあります。
For these reasons, [RFC8064] recommends using an address generation scheme in [RFC7217], rather than addresses generated from a fixed link-layer address.
これらの理由から、[RFC8064]は、固定リンク層アドレスから生成されたアドレスではなく、[RFC7217]のアドレス生成スキームを使用することを推奨しています。
Furthermore, to mitigate the threat of correlation of activities over time on long-lived links, [RFC4941] specifies the notion of a "temporary" address to be used for transport sessions (typically locally initiated outbound traffic to the Internet) that should not be linkable to a more permanent identifier such as a DNS name, user name, or fixed link-layer address. Indeed, the default address selection rules [RFC6724] now prefer temporary addresses by default for outgoing connections. If a device needs to simultaneously support unlinkable traffic as well as traffic that is linkable to such a stable identifier, supporting simultaneous use of multiple addresses per device is necessary.
さらに、長期間のリンクでのアクティビティの相関の脅威を緩和するために、[RFC4941]は、トランスポートセッション（通常はローカルで開始され、インターネットへの発信トラフィック）に使用されるべきではない「一時的な」アドレスの概念を指定しています。 DNS名、ユーザー名、固定リンク層アドレスなど、より永続的な識別子にリンクできます。実際、デフォルトのアドレス選択規則[RFC6724]は、発信接続に対してデフォルトで一時アドレスを優先するようになりました。デバイスがリンク不可能なトラフィックとそのような安定した識別子にリンク可能なトラフィックを同時にサポートする必要がある場合、デバイスごとに複数のアドレスの同時使用をサポートする必要があります。
In terms of privacy threats discussed in [RFC7721], the one with the need for the most entropy is address scans of routable addresses. To mitigate address scans, one needs enough entropy to make the probability of a successful address probe be negligible. Typically, this is measured in the length of time it would take to have a 50% probability of getting at least one hit. Address scans often rely on sending a packet such as a TCP SYN or ICMP Echo Request, then determining whether the reply is a) an ICMP unreachable error (if no host exists with that address), b) a TCP response or ICMP Echo Reply (if a host exists), or c) none of those, in which case nothing is known for certain.
[RFC7721]で説明されているプライバシーの脅威に関して、最もエントロピーを必要とするのは、ルーティング可能なアドレスのアドレススキャンです。アドレススキャンを軽減するには、アドレスプローブが成功する確率を無視できるほど十分なエントロピーが必要です。通常、これは、少なくとも1つのヒットを取得する確率が50％になるまでの時間で測定されます。多くの場合、アドレススキャンは、TCP SYNまたはICMPエコー要求などのパケットの送信に依存し、応答がa）ICMP到達不能エラー（そのアドレスのホストが存在しない場合）、b）TCP応答またはICMPエコー応答（ホストが存在する場合）、またはc）それらのいずれもない場合。その場合、何も特定されていません。
Many privacy-sensitive devices support a "stealth mode" as discussed in Section 5 of [RFC7288] or are behind a network firewall that will drop unsolicited inbound traffic (e.g., TCP SYNs, ICMP Echo Requests, etc.) and thus no TCP RST or ICMP Echo Reply will be sent. In such cases, and when the device does not listen on a well-known TCP or UDP port known to the scanner, the effectiveness of an address scan is limited by the ability to get ICMP unreachable errors, since the attacker can only infer the presence of a host based on the absence of an ICMP unreachable error.
[RFC7288]のセクション5で説明されているように、プライバシーに敏感な多くのデバイスは「ステルスモード」をサポートしているか、一方的な着信トラフィック（TCP SYN、ICMPエコー要求など）をドロップするネットワークファイアウォールの背後にあるため、TCP RSTはありませんまたはICMPエコー応答が送信されます。このような場合、およびデバイスがスキャナーに既知の既知のTCPまたはUDPポートをリッスンしない場合、攻撃者は存在を推測することしかできないため、ICMP到達不能エラーを取得できるため、アドレススキャンの効果が制限されます。 ICMP到達不能エラーの欠如に基づくホストの。
Generation of ICMP unreachable errors is typically rate limited to 2 per second (the default in routers such as Cisco routers running IOS 12.0 or later). Such a rate results in taking about a year to completely scan 26 bits of space.
ICMP到達不能エラーの生成は、通常、毎秒2に制限されています（IOS 12.0以降を実行しているCiscoルーターなどのルーターのデフォルト）。このような速度では、26ビットのスペースを完全にスキャンするのに約1年かかります。
The actual math is as follows. Let 2^N be the number of devices on the subnet. Let 2^M be the size of the space to scan (i.e., M bits of entropy). Let S be the number of scan attempts. The formula for a 50% chance of getting at least one hit in S attempts is: P(at least one success) = 1 - (1 - 2^N/2^M)^S = 1/2. Assuming 2^M >> S, this simplifies to: S * 2^N/2^M = 1/2, giving S = 2^(M-N-1), or M = N + 1 + log_2(S). Using a scan rate of 2 per second, this results in the following rule of thumb:
実際の計算は次のとおりです。サブネット上のデバイスの数を2 ^ Nとします。スキャンするスペースのサイズを2 ^ Mとします（つまり、Mビットのエントロピー）。スキャンの試行回数をSとします。 S回の試行で50％の確率でヒットする確率は、P（少なくとも1回の成功）= 1-（1-2 ^ N / 2 ^ M）^ S = 1/2です。 2 ^ M >> Sとすると、これは次のように単純化されます。S* 2 ^ N / 2 ^ M = 1/2、S = 2 ^（M-N-1）、またはM = N + 1 + log_2（S）になります。毎秒2のスキャンレートを使用すると、次の経験則になります。
Bits of entropy needed =
log_2(# devices per link) + log_2(seconds of link lifetime) + 2
For example, for a network with at most 2^16 devices on the same long-lived link, where the average lifetime of a link is 8 years (2^28 seconds) or less, this results in a need for at least 46 bits of entropy (16+28+2) so that an address scan would need to be sustained for longer than the lifetime of the link to have a 50% chance of getting a hit.
たとえば、リンクの平均寿命が8年（2 ^ 28秒）以下である、同じ長寿命のリンク上に最大2 ^ 16のデバイスがあるネットワークの場合、これにより少なくとも46ビットが必要になります。エントロピー（16 + 28 + 2）であり、アドレススキャンを50％の確率でヒットさせるには、リンクの存続期間よりも長く維持する必要があります。
Although 46 bits of entropy may be enough to provide privacy in such cases, 59 or more bits of entropy would be needed if addresses are used to provide security against attacks such as spoofing, as CGAs [RFC3972] and HBAs [RFC5535] do, since attacks are not limited by ICMP rate limiting but by the processing power of the attacker. See those RFCs for more discussion.
このような場合、46ビットのエントロピーでプライバシーを確保できますが、CGA [RFC3972]やHBA [RFC5535]のように、アドレスを使用してなりすましなどの攻撃に対するセキュリティを提供する場合は、59ビット以上のエントロピーが必要になります。攻撃は、ICMPレート制限によってではなく、攻撃者の処理能力によって制限されます。詳細については、これらのRFCを参照してください。
If, on the other hand, the devices being scanned for respond to unsolicited inbound packets, then the address scan is not limited by the ICMP unreachable rate limit in routers, since an adversary can determine the presence of a host without them. In such cases, more bits of entropy would be needed to provide the same level of protection.
一方、スキャン対象のデバイスが未承諾の受信パケットに応答する場合、攻撃者はそれらなしでホストの存在を判別できるため、ルーターのICMP到達不能レート制限によってアドレススキャンは制限されません。このような場合、同じレベルの保護を提供するには、さらに多くのエントロピーが必要になります。
The table below shows the number of bits of entropy currently available in various technologies:
以下の表は、さまざまなテクノロジーで現在利用可能なエントロピーのビット数を示しています。
+---------------+--------------------------+--------------------+
| Technology | Reference | Bits of Entropy |
+---------------+--------------------------+--------------------+
| 802.15.4 | [RFC4944] | 16+ or any EUI-64 |
| Bluetooth LE | [RFC7668] | 48 |
| DECT ULE | [DECT-ULE] | 40 or any EUI-48 |
| MS/TP | [IPv6-over-MSTP] | 7 or 64 |
| ITU-T G.9959 | [RFC7428] | 8 |
| NFC | [IPv6-over-NFC] | 5 |
+---------------+--------------------------+--------------------+
Such technologies generally support either IEEE identifiers or so called "Short Addresses", or both, as link-layer addresses. We discuss each in turn.
そのようなテクノロジーは、一般に、IEEE識別子またはいわゆる「ショートアドレス」、あるいはその両方をリンク層アドレスとしてサポートします。それぞれについて順に説明します。
Some technologies allow the use of IEEE EUI-48 or EUI-64 identifiers or allow the use of an arbitrary 64-bit identifier. Using such an identifier to construct IPv6 addresses makes it easy to use the normal LOWPAN_IPHC encoding [RFC6282] with stateless compression, which allows such IPv6 addresses to be fully elided in common cases.
一部のテクノロジでは、IEEE EUI-48またはEUI-64識別子の使用を許可するか、任意の64ビット識別子の使用を許可します。このような識別子を使用してIPv6アドレスを構築すると、通常のLOWPAN_IPHCエンコーディング[RFC6282]をステートレス圧縮で簡単に使用できるようになるため、このようなIPv6アドレスを一般的なケースで完全に除外できます。
Global addresses with interface identifiers formed from IEEE identifiers can have insufficient entropy to mitigate address scans unless the IEEE identifier itself has sufficient entropy and enough bits of entropy are carried over into the IPv6 address to sufficiently mitigate the threats. Privacy threats other than "Correlation over time" can be mitigated using per-network randomized link-layer addresses with enough entropy compared to the link lifetime. A number of such proposals can be found at <https://mentor.ieee.org/privecsg/documents>, and Section 10.8 of [BTCorev4.1] specifies one for Bluetooth. Using routable IPv6 addresses derived from such link-layer addresses would be roughly equivalent to those specified in [RFC7217].
IEEE識別子から形成されたインターフェイス識別子を持つグローバルアドレスは、IEEE識別子自体に十分なエントロピーがなく、脅威を十分に緩和するのに十分なエントロピーのビットがIPv6アドレスに引き継がれない限り、アドレススキャンを緩和するには不十分なエントロピーを持つ可能性があります。 「経時的な相関」以外のプライバシーの脅威は、リンクのライフタイムと比較して十分なエントロピーを持つネットワークごとのランダム化されたリンク層アドレスを使用して軽減できます。そのような提案の多くは<https://mentor.ieee.org/privecsg/documents>で見つけることができ、[BTCorev4.1]のセクション10.8はBluetoothの1つを指定しています。このようなリンク層アドレスから導出されたルーティング可能なIPv6アドレスを使用することは、[RFC7217]で指定されているアドレスとほぼ同等です。
Correlation over time (for all addresses, not just routable addresses) can be mitigated if the link-layer address itself changes often enough, such as each time the link is established, if the link lifetime is short. For further discussion, see [RANDOM-ADDR].
リンク層のアドレス自体が頻繁に変化する場合（リンクが確立されるたびなど）、リンクのライフタイムが短い場合など、（ルーティング可能なアドレスだけでなく、すべてのアドレスの）時間の相関関係を緩和できます。詳細については、[RANDOM-ADDR]を参照してください。
Another potential concern is that of efficiency, such as avoiding Duplicate Address Detection (DAD) altogether when IPv6 addresses are based on IEEE identifiers. Appendix A of [RFC4429] provides an analysis of address-collision probability based on the number of bits of entropy. A simple web search on "duplicate MAC addresses" will show that collisions do happen with MAC addresses; thus, based on the analysis in [RFC4429], using sufficient bits of entropy in random addresses can provide greater protection against collision than using MAC addresses.
別の潜在的な懸念は、IPv6アドレスがIEEE識別子に基づいている場合に重複アドレス検出（DAD）を完全に回避するなど、効率の問題です。 [RFC4429]の付録Aは、エントロピーのビット数に基づくアドレス衝突確率の分析を提供します。 「重複するMACアドレス」での単純なWeb検索では、MACアドレスとの衝突が発生することが示されます。したがって、[RFC4429]の分析に基づいて、ランダムアドレスで十分なエントロピービットを使用すると、MACアドレスを使用するよりも衝突に対する保護を強化できます。
A routable IPv6 address with an interface identifier formed from the combination of a "Short Address" and a set of well-known constant bits (such as padding with 0's) lacks sufficient entropy to mitigate address scanning unless the link lifetime is extremely short. Furthermore, an adversary could also use statistical methods to determine the size of the L2 address space and thereby make some inference regarding the underlying technology on a given link, and target further attacks accordingly.
「ショートアドレス」と一連の既知の定数ビット（0のパディングなど）の組み合わせから形成されたインターフェイス識別子を持つルーティング可能なIPv6アドレスは、リンクのライフタイムが極端に短い場合を除いて、アドレススキャンを緩和するのに十分なエントロピーがありません。さらに、攻撃者は統計的手法を使用してL2アドレススペースのサイズを決定し、特定のリンクの基盤となるテクノロジーに関する推論を行い、それに応じてさらなる攻撃を標的にすることもできます。
When Short Addresses are desired on links that are not guaranteed to have a short enough lifetime, the mechanism for constructing an IPv6 interface identifier from a Short Address could be designed to sufficiently mitigate the problem. For example, if all nodes on a given L2 network have a shared secret (such as the key needed to get on the layer-2 network), the 64-bit IID might be generated using a one-way hash that includes (at least) the shared secret together with the Short Address. The use of such a hash would result in the IIDs being spread out among the full range of IID address space, thus mitigating address scans while still allowing full stateless compression/elision.
有効期間が十分短いことが保証されていないリンクでショートアドレスが必要な場合、ショートアドレスからIPv6インターフェイス識別子を構築するメカニズムを設計して、問題を十分に緩和できます。たとえば、特定のL2ネットワーク上のすべてのノードが共有シークレット（レイヤー2ネットワークにアクセスするために必要なキーなど）を持っている場合、64ビットIIDは、（少なくとも）共有秘密と短縮アドレス。そのようなハッシュを使用すると、IIDアドレススペースの全範囲にIIDが分散され、アドレススキャンが軽減され、ステートレスな圧縮/削除が可能になります。
For long-lived links, "temporary" addresses might even be generated in the same way by (for example) also including in the hash the Version Number from the Authoritative Border Router Option (Section 4.3 of [RFC6775]), if any. This would allow changing temporary addresses whenever the Version Number is changed, even if the set of prefix or context information is unchanged.
存続期間の長いリンクの場合、「一時的な」アドレスは、たとえば、信頼できる境界ルーターオプションからのバージョン番号（[RFC6775]のセクション4.3）がある場合、ハッシュに含めることによっても同じように生成される可能性があります。これにより、プレフィックスまたはコンテキスト情報のセットが変更されていなくても、バージョン番号が変更されるたびに一時アドレスを変更できます。
In summary, any specification using Short Addresses should carefully construct an IID generation mechanism so as to provide sufficient entropy compared to the link lifetime.
要約すると、ショートアドレスを使用する仕様では、リンク生成期間と比較して十分なエントロピーを提供できるように、IID生成メカニズムを慎重に構築する必要があります。
The following are recommended for adaptation-layer specifications:
アダプテーションレイヤの仕様については、以下が推奨されます。
o Security (privacy) sections should say how address scans are mitigated. An address scan might be mitigated by having a link always be short-lived, by having a large number of bits of entropy in routable addresses, or by some combination thereof. Thus, a specification should explain what the maximum lifetime of a link is in practice and show how the number of bits of entropy is sufficient given that lifetime.
o セキュリティ（プライバシー）セクションでは、アドレススキャンを軽減する方法を説明する必要があります。アドレススキャンは、リンクの存続期間を常に短くするか、ルーティング可能なアドレスにエントロピーの多数のビットを持たせるか、またはこれらの組み合わせによって軽減できます。したがって、仕様では、実際のリンクの最大存続期間を説明し、その存続期間でエントロピーのビット数がどの程度十分であるかを示す必要があります。
o Technologies should define a way to include sufficient bits of entropy in the IPv6 interface identifier, based on the maximum link lifetime. Specifying that randomized link-layer addresses can be used is one easy way to do so, for technologies that support such identifiers.
o テクノロジでは、最大リンクライフタイムに基づいて、IPv6インターフェイス識別子にエントロピーの十分なビットを含める方法を定義する必要があります。ランダム化されたリンク層アドレスを使用できるように指定することは、そのような識別子をサポートするテクノロジにとって、そのための1つの簡単な方法です。
o Specifications should not simply construct an IPv6 interface identifier by padding a Short Address with a set of other well-known constant bits, unless the link lifetime is guaranteed to be extremely short or the Short Address is allocated by the network (rather than being constant in the node). This also applies to link-local addresses if the same Short Address is used independent of network and is unique enough to allow location tracking.
o リンクライフタイムが極端に短いことが保証されていないか、またはネットワークでショートアドレスが割り当てられていない限り、仕様では、ショートアドレスに他の既知の定数ビットのセットを埋め込んでIPv6インターフェイス識別子を単純に構築しないでください（ノード）。これは、同じローカルアドレスがネットワークとは無関係に使用され、位置追跡を可能にするのに十分一意である場合、リンクローカルアドレスにも適用されます。
o Specifications should make sure that an IPv6 address can change over long periods of time. For example, the interface identifier might change each time a device connects to the network (if connections are short) or might change each day (if connections can be long). This is necessary to mitigate correlation over time.
o 仕様では、IPv6アドレスが長期間にわたって変更できることを確認する必要があります。たとえば、デバイスがネットワークに接続するたびに（接続が短い場合）、または毎日（接続が長くなる可能性がある場合）に、インターフェイス識別子が変わる可能性があります。これは、時間の経過に伴う相関を緩和するために必要です。
o If a device can roam between networks and more than a few bits of entropy exist in the IPv6 interface identifier, then make sure that the interface identifier can vary per network as the device roams. This is necessary to mitigate location tracking.
o デバイスがネットワーク間をローミングでき、IPv6インターフェイス識別子に数ビットを超えるエントロピーが存在する場合は、デバイスがローミングするときにインターフェイス識別子がネットワークごとに異なることを確認してください。これは、位置追跡を軽減するために必要です。
This entire document is about security considerations and how to specify possible mitigations.
このドキュメント全体は、セキュリティに関する考慮事項と、考えられる軽減策を指定する方法に関するものです。
[BTCorev4.1] Bluetooth, "Specification of the Bluetooth System", Covered Core Package version: 4.1, December 2013, <https://www.bluetooth.org/DocMan/handlers/ DownloadDoc.ashx?doc_id=282159>.
[BTCorev4.1] Bluetooth、「Bluetoothシステムの仕様」、対象コアパッケージバージョン：4.1、2013年12月、<https://www.bluetooth.org/DocMan/handlers/ DownloadDoc.ashx？doc_id = 282159>。
[DECT-ULE] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Energy", draft-ietf-6lo-dect-ule-09, Work in Progress, December 2016.
[DECT-ULE] Mariager、P.、Petersen、J.、Ed。、Shelby、Z.、Van de Logt、M。、およびD. Barthel、「DECT超低エネルギーでのIPv6パケットの送信」、draft-ietf -6lo-dect-ule-09、Work in Progress、2016年12月。
[IPv6-over-MSTP] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", draft-ietf-6lo-6lobac-06, Work in Progress, October 2016.
[IPv6-over-MSTP] Lynn、K.、Ed。、Martocci、J.、Neilson、C。、およびS. Donaldson、「Transmission of IPv6 over MS / TP Networks」、draft-ietf-6lo-6lobac-06 、Work in Progress、2016年10月。
[IPv6-over-NFC] Choi, Y-H., Hong, Y-G., Youn, J-S., Kim, D-K., and J-H. Choi, "Transmission of IPv6 Packets over Near Field Communication", draft-ietf-6lo-nfc-05, Work in Progress, October 2016.
[IPv6-over-NFC]チェ、Y-H。、ホン、Y-G。、ユン、J-S。、キム、D-K。、J-H。チェ、「近距離無線通信によるIPv6パケットの送信」、draft-ietf-6lo-nfc-05、Work in Progress、2016年10月。
[RANDOM-ADDR] Huitema, C., "Implications of Randomized Link Layers Addresses for IPv6 Address Assignment", draft-huitema-6man-random-addresses-03, Work in Progress, March 2016.
[RANDOM-ADDR] Huitema、C。、「IPv6アドレス割り当てのためのランダムリンクレイヤーアドレスの影響」、draft-huitema-6man-random-addresses-03、Work in Progress、2016年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<http://www.rfc-editor.org/info/rfc3972>。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>.
[RFC4429] Moore、N。、「IPv6の楽観的重複アドレス検出（DAD）」、RFC 4429、DOI 10.17487 / RFC4429、2006年4月、<http://www.rfc-editor.org/info/rfc4429>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<http：//www.rfc-editor .org / info / rfc4941>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>.
[RFC5535] Bagnulo、M。、「ハッシュベースアドレス（HBA）」、RFC 5535、DOI 10.17487 / RFC5535、2009年6月、<http://www.rfc-editor.org/info/rfc5535>。
[RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282] Hui、J.、Ed。、およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http：// www。 rfc-editor.org/info/rfc6282>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<http://www.rfc-editor.org/info/rfc6775>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[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>。
[RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, <http://www.rfc-editor.org/info/rfc7288>.
[RFC7288] Thaler、D。、「Reflections on Host Firewalls」、RFC 7288、DOI 10.17487 / RFC7288、2014年6月、<http://www.rfc-editor.org/info/rfc7288>。
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421] Carpenter、B.、Ed。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。、およびA. Yourtchenko、「IPv6アドレッシングの64ビット境界の分析」、RFC 7421、DOI 10.17487 / RFC7421、2015年1月、<http://www.rfc-editor.org/info/rfc7421>。
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <http://www.rfc-editor.org/info/rfc7428>.
[RFC7428] Brandt、A。およびJ. Buron、「ITU-T G.9959ネットワークを介したIPv6パケットの送信」、RFC 7428、DOI 10.17487 / RFC7428、2015年2月、<http://www.rfc-editor.org / info / rfc7428>。
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <http://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「IPv6 over BLUETOOTH（R）Low Energy」、RFC 7668、DOI 10.17487 / RFC7668、2015年10月、<http://www.rfc-editor.org/info/rfc7668>。
[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>。
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, February 2017, <http://www.rfc-editor.org/info/rfc8064>.
[RFC8064] Gont、F.、Cooper、A.、Thaler、D。、およびW. Liu、「Recommendation on Stable IPv6 Interface Identifiers」、RFC 8064、2017年2月、<http://www.rfc-editor.org / info / rfc8064>。
Author's Address
著者のアドレス
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 United States of America
デイブターラーマイクロソフトワンマイクロソフトウェイレドモンド、ワシントン州98052アメリカ合衆国
Email: dthaler@microsoft.com