IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項

英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。

日本語訳

Internet Engineering Task Force (IETF)                         A. Cooper
Request for Comments: 7721                                         Cisco
Category: Informational                                          F. Gont
ISSN: 2070-1721                                      Huawei Technologies
                                                               D. Thaler
                                                               Microsoft
                                                              March 2016


                Security and Privacy Considerations for
                   IPv6 Address Generation Mechanisms

IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項


Abstract

概要


   This document discusses privacy and security considerations for
   several IPv6 address generation mechanisms, both standardized and
   non-standardized.  It evaluates how different mechanisms mitigate
   different threats and the trade-offs that implementors, developers,
   and users face in choosing different addresses or address generation
   mechanisms.

このドキュメントでは、標準化および非標準化された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 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7721.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7721で入手できます。
















Cooper, et al.                Informational                     [Page 1]

RFC 7721             IPv6 Address Generation Privacy          March 2016


Copyright Notice

著作権表示


   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。 全著作権所有。


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Weaknesses in IEEE-Identifier-Based IIDs  . . . . . . . . . .   5
     3.1.  Correlation of Activities over Time . . . . . . . . . . .   5
     3.2.  Location Tracking . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Address Scanning  . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Device-Specific Vulnerability Exploitation  . . . . . . .   7
   4.  Privacy and Security Properties of Address Generation
       Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  IEEE-Identifier-Based IIDs  . . . . . . . . . . . . . . .  10
     4.2.  Static, Manually Configured IIDs  . . . . . . . . . . . .  10
     4.3.  Constant, Semantically Opaque IIDs  . . . . . . . . . . .  10
     4.4.  Cryptographically Generated IIDs  . . . . . . . . . . . .  10
     4.5.  Stable, Semantically Opaque IIDs  . . . . . . . . . . . .  11
     4.6.  Temporary IIDs  . . . . . . . . . . . . . . . . . . . . .  11
     4.7.  DHCPv6 Generation of IIDs . . . . . . . . . . . . . . . .  12
     4.8.  Transition and Coexistence Technologies . . . . . . . . .  12
   5.  Miscellaneous Issues with IPv6 Addressing . . . . . . . . . .  13
     5.1.  Network Operation . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Compliance  . . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Intellectual Property Rights (IPRs) . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
   1.はじめに. . . . . . . . . . . . . . . . . . . . . . . . 3
   2.用語. . . . . . . . . . . . . . . . . . . . . . . . . 4
   3. IEEE識別子ベースのIIDの弱点. . . . . . . . . . 5
     3.1.時間の経過に伴うアクティビティの相関関係. . . . . . . . . . . 5
     3.2.位置追跡. . . . . . . . . . . . . . . . . . . . 6
     3.3.アドレススキャン. . . . . . . . . . . . . . . . . . . . 7
     3.4.デバイス固有の脆弱性の悪用. . . . . . . 7
   4.アドレス生成のプライバシーとセキュリティのプロパティ
       メカニズム. . . . . . . . . . . . . . . . . . . . . . . . . 7
     4.1. IEEE識別子ベースのIID. . . . . . . . . . . . . . . 10
     4.2.静的、手動で構成されたIID. . . . . . . . . . . . 10
     4.3.定数、意味的に不透明なIID. . . . . . . . . . . 10
     4.4.暗号で生成されたIID. . . . . . . . . . . . 10
     4.5.安定した、意味的に不透明なIID. . . . . . . . . . . . 11
     4.6一時的なIID. . . . . . . . . . . . . . . . . . . . . 11
     4.7. DHCPv6によるIIDの生成. . . . . . . . . . . . . . . . 12
     4.8.移行と共存テクノロジー. . . . . . . . . 12
   5. IPv6アドレッシングに関するその他の問題. . . . . . . . . . 13
     5.1.ネットワークオペレーション. . . . . . . . . . . . . . . . . . . . 13
     5.2.コンプライアンス. . . . . . . . . . . . . . . . . . . . . . . 13
     5.3.知的財産権(IPR). . . . . . . . . . . 13
   6.セキュリティに関する考慮事項. . . . . . . . . . . . . . . . . . . 13
   7.参考資料. . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.規範的参照. . . . . . . . . . . . . . . . . . 14
     7.2.有益な参照. . . . . . . . . . . . . . . . . 15
   謝辞. . . . . . . . . . . . . . . . . . . . . . . . 18
   著者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 18







Cooper, et al.                Informational                     [Page 2]

RFC 7721             IPv6 Address Generation Privacy          March 2016


1.  Introduction

1.はじめに


   IPv6 was designed to improve upon IPv4 in many respects, and
   mechanisms for address assignment were one such area for improvement.
   In addition to static address assignment and DHCP, stateless
   autoconfiguration was developed as a less intensive, fate-shared
   means of performing address assignment.  With stateless
   autoconfiguration, routers advertise on-link prefixes and hosts
   generate their own Interface Identifiers (IIDs) to complete their
   addresses.  [RFC7136] clarifies that the IID should be treated as an
   opaque value, while [RFC7421] provides an analysis of the 64-bit
   boundary in IPv6 addressing (e.g., the implications of the IID length
   on security and privacy).  Over the years, many IID generation
   techniques have been defined, both standardized and non-standardized:

IPv6は多くの点でIPv4を改善するように設計されており、アドレス割り当てのメカニズムは改善のそのような領域の1つでした。 静的アドレス割り当てとDHCPに加えて、ステートレス自動構成は、アドレス割り当てを実行する、それほど集中的ではない運命共有手段として開発されました。 ステートレス自動構成では、ルーターはオンリンクプレフィックスをアドバタイズし、ホストは独自のインターフェイス識別子(IID)を生成してアドレスを完成させます。 [RFC7136]は、IIDを不透明な値として扱う必要があることを明確にしますが、[RFC7421]は、IPv6アドレッシングの64ビット境界の分析を提供します(たとえば、セキュリティとプライバシーに対するIID長の影響)。 長年にわたり、標準化および非標準化の両方で、多くのIID生成手法が定義されてきました。


   o  Manual configuration [RFC7707]

手動設定[RFC7707]


      *  IPv4 address

IPv4アドレス


      *  Service port

サービスポート


      *  Wordy

言葉っぽい


      *  Low-byte

低バイト


   o  Stateless Address Autoconfiguration (SLAAC)

ステートレスアドレス自動構成(SLAAC)


      *  IEEE 802 48-bit Media Access Control (MAC) or IEEE 64-bit
         Extended Unique Identifier (EUI-64) [RFC2464]

IEEE 802 48ビットメディアアクセスコントロール(MAC)またはIEEE 64ビット拡張一意識別子(EUI-64)[RFC2464]


      *  Cryptographically generated [RFC3972]

暗号的に生成された[RFC3972]


      *  Temporary (also known as "privacy addresses") [RFC4941]

一時的(別名「プライバシーアドレス」)[RFC4941]


      *  Constant, semantically opaque (also known as "random")
         [Microsoft]

一定、意味的に不透明(「ランダム」とも呼ばれる)[Microsoft]


      *  Stable, semantically opaque [RFC7217]

安定した、意味的に不透明な[RFC7217]


   o  DHCPv6 based [RFC3315]

DHCPv6ベース[RFC3315]


   o  Specified by transition/co-existence technologies

移行/共存テクノロジによって指定


      *  Derived from an IPv4 address (e.g., [RFC5214], [RFC6052])

IPv4アドレスから派生(例:[RFC5214]、[RFC6052])


      *  Derived from an IPv4 address and port set ID (e.g., [RFC7596],
         [RFC7597], [RFC7599])

IPv4アドレスとポートセットIDから派生(例:[RFC7596]、[RFC7597]、[RFC7599])





Cooper, et al.                Informational                     [Page 3]

RFC 7721             IPv6 Address Generation Privacy          March 2016


      *  Derived from an IPv4 address and port (e.g., [RFC4380])

IPv4アドレスとポートから派生(例:[RFC4380])


   Deriving the IID from a globally unique IEEE identifier [RFC2464]
   [RFC4862] was one of the earliest mechanisms developed (and
   originally specified in [RFC1971] and [RFC1972]).  A number of
   privacy and security issues related to the IIDs derived from IEEE
   identifiers were discovered after their standardization, and many of
   the mechanisms developed later aimed to mitigate some or all of these
   weaknesses.  This document identifies four types of attacks against
   IEEE-identifier-based IIDs and discusses how other existing
   techniques for generating IIDs do or do not mitigate those attacks.

グローバルに一意のIEEE識別子[RFC2464] [RFC4862]からIIDを導出することは、開発された最も初期のメカニズムの1つでした(そして、元々[RFC1971]および[RFC1972]で指定されていました)。 IEEE識別子から派生したIIDに関連するプライバシーとセキュリティの問題の多くは、標準化後に発見されました。後に開発されたメカニズムの多くは、これらの弱点の一部またはすべてを軽減することを目的としています。 このドキュメントでは、IEEE識別子ベースのIIDに対する4種類の攻撃を特定し、IIDを生成する他の既存の手法がこれらの攻撃をどのように軽減するかについて説明します。


2.  Terminology

2.用語


   This section clarifies the terminology used throughout this document.

このセクションでは、このドキュメント全体で使用される用語を明確にします。


   Public address:

公開アドレス:

      An address that has been published in a directory or other public
      location, such as the DNS, a SIP proxy [RFC3261], an application-
      specific Distributed Hash Table (DHT), or a publicly available
      URI.  A host's public addresses are intended to be discoverable by
      third parties.

ディレクトリ、またはDNS、SIPプロキシ[RFC3261]、アプリケーション固有の分散ハッシュテーブル(DHT)、または公的に利用可能なURIなどのその他のパブリックロケーションで公開されているアドレス。 ホストのパブリックアドレスは、サードパーティが検出できるようになっています。


   Stable address:

安定したアドレス:

      An address that does not vary over time within the same IPv6 link.
      Note that [RFC4941] refers to these as "public" addresses, but
      "stable" is used here for reasons explained in Section 4.

同じIPv6リンク内で時間とともに変化しないアドレス。 [RFC4941]はこれらを「パブリック」アドレスと呼びますが、ここでは「安定」がセクション4で説明されている理由のために使用されていることに注意してください。


   Temporary address:

一時アドレス:

      An address that varies over time within the same IPv6 link.

同じIPv6リンク内で時間とともに変化するアドレス。


   Constant IID:

定数IID:

      An IPv6 interface identifier that is globally stable.  That is,
      the Interface ID will remain constant even if the node moves from
      one IPv6 link to another.

グローバルに安定しているIPv6インターフェースID。 つまり、ノードがあるIPv6リンクから別のIPv6リンクに移動しても、インターフェイスIDは一定のままです。


   Stable IID:

安定したIID:

      An IPv6 interface identifier that is stable within some specified
      context.  For example, an Interface ID can be globally stable
      (constant) or could be stable per IPv6 link (meaning that the
      Interface ID will remain unchanged as long as the node stays on
      the same IPv6 link but may change when the node moves from one
      IPv6 link to another).

特定のコンテキスト内で安定しているIPv6インターフェースID。 たとえば、インターフェースIDはグローバルに安定(一定)であるか、IPv6リンクごとに安定している可能性があります(つまり、ノードが同じIPv6リンクにとどまっている限り、インターフェースIDは変更されませんが、ノードが1つのIPv6から移動すると変更される可能性があります 別のものへのリンク)。


   Temporary IID:

一時的なIID:

      An IPv6 interface identifier that varies over time.

時間とともに変化するIPv6インターフェースID。






Cooper, et al.                Informational                     [Page 4]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   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
   [RFC2119].  These words take their normative meanings only when they
   are presented in ALL UPPERCASE.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL このドキュメントの "は、[RFC2119]で説明されているように解釈されます。 これらの単語は、すべて大文字で表記されている場合にのみ、その規範的な意味を持ちます。


3.  Weaknesses in IEEE-Identifier-Based IIDs

3. IEEE識別子ベースのIIDの弱点


   There are a number of privacy and security implications that exist
   for hosts that use IEEE-identifier-based IIDs.  This section
   discusses four generic attack types: correlation of activities over
   time, location tracking, address scanning, and device-specific
   vulnerability exploitation.  The first three of these rely on the
   attacker first gaining knowledge of the IID of the target host.  This
   could be achieved by a number of different entities: the operator of
   a server to which the host connects, such as a web server or a peer-
   to-peer server; an entity that connects to the same IPv6 link as the
   target (such as a conference network or any public network); a
   passive observer of traffic that the host broadcasts; or an entity
   that is on path to the destinations with which the host communicates,
   such as a network operator.

IEEE識別子ベースのIIDを使用するホストには、プライバシーとセキュリティに関する多くの影響があります。 このセクションでは、4つの一般的な攻撃タイプについて説明します。時間の経過に伴うアクティビティの相関、位置追跡、アドレススキャン、デバイス固有の脆弱性の悪用です。 これらの最初の3つは、攻撃者が最初にターゲットホストのIIDの知識を取得することに依存しています。 これは、さまざまなエンティティによって実現できます。Webサーバーやピアツーピアサーバーなど、ホストが接続するサーバーのオペレーター。 ターゲットと同じIPv6リンクに接続するエンティティ(会議ネットワークやパブリックネットワークなど)。 ホストがブロードキャストするトラフィックのパッシブオブザーバー。 または、ネットワークオペレーターなど、ホストが通信する宛先へのパス上にあるエンティティ。


3.1.  Correlation of Activities over Time

3.1。 時間の経過に伴うアクティビティの相関関係


   As with other identifiers, an IPv6 address can be used to correlate
   the activities of a host for at least as long as the lifetime of the
   address.  The correlation made possible by IEEE-identifier-based IIDs
   is of particular concern since they last roughly for the lifetime of
   a device's network interface, allowing correlation on the order of
   years.

他の識別子と同様に、IPv6アドレスを使用して、少なくともアドレスのライフタイムと同じ長さのホストのアクティビティを関連付けることができます。 IEEE識別子ベースのIIDによって可能になった相関関係は、デバイスのネットワークインターフェイスの寿命がほぼ続くため、特に懸念されます。


   As [RFC4941] explains,

[RFC4941]が説明するように、


      [t]he use of a non-changing interface identifier 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. ... 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.

変化しないインターフェース識別子を使用してアドレスを形成することは、一定の識別子が長期間にわたって複数の独立したアクティビティで再利用される、より一般的なケースの特定のインスタンスです。 同じ識別子が複数のコンテキストで使用されるときはいつでも、その識別子を使用して、一見無関係なアクティビティを関連付けることが可能になります。 ... アドレスは通信の基本的な要件であり、盗聴者や他の関係者から簡単に隠すことはできないため、アドレス内での定数識別子の使用は特に懸念されます。 上位層がペイロードを暗号化しても、パケットヘッダーのアドレスはクリアテキストで表示されます。


   IP addresses are just one example of information that can be used to
   correlate activities over time.  DNS names, cookies [RFC6265],
   browser fingerprints [Panopticlick], and application-layer usernames



Cooper, et al.                Informational                     [Page 5]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   can all be used to link a host's activities together.  Although IEEE-
   identifier-based IIDs are likely to last at least as long or longer
   than these other identifiers, IIDs generated in other ways may have
   shorter or longer lifetimes than these identifiers depending on how
   they are generated.  Therefore, the extent to which a host's
   activities can be correlated depends on whether the host uses
   multiple identifiers together and the lifetimes of all of those
   identifiers.  Frequently refreshing an IPv6 address may not mitigate
   correlation if an attacker has access to other longer-lived
   identifiers for a particular host.  This is an important caveat to
   keep in mind throughout the discussion of correlation in this
   document.  For further discussion of correlation, see Section 5.2.1
   of [RFC6973].

IPアドレスは、時間の経過とともにアクティビティを関連付けるために使用できる情報の一例にすぎません。 DNS名、Cookie [RFC6265]、ブラウザーの指紋[Panopticlick]、およびアプリケーション層のユーザー名はすべて、ホストのアクティビティをリンクするために使用できます。 IEEE識別子ベースのIIDは、少なくともこれらの他の識別子と同じかそれ以上長く続く可能性がありますが、他の方法で生成されたIIDは、生成方法に応じて、これらの識別子よりも短いまたは長いライフタイムを持っています。 したがって、ホストのアクティビティを関連付けることができる範囲は、ホストが複数の識別子を一緒に使用するかどうか、およびそれらの識別子すべての寿命に依存します。 攻撃者が特定のホストの他の寿命の長い識別子にアクセスできる場合、IPv6アドレスを頻繁に更新しても相関を緩和できない可能性があります。 これは、このドキュメントでの相関関係の説明全体を通して覚えておくべき重要な警告です。 相関の詳細については、[RFC6973]のセクション5.2.1を参照してください。


   As noted in [RFC4941], in some cases correlation is just as feasible
   for a host using an IPv4 address as for a host using an IEEE
   identifier to generate its IID in its IPv6 address.  Hosts that use
   static IPv4 addressing or who are consistently allocated the same
   address via DHCPv4 can be tracked as described above.  However, the
   widespread use of both NAT and DHCPv4 implementations that assign the
   same host a different address upon lease expiration mitigates this
   threat in the IPv4 case as compared to the IEEE identifier case in
   IPv6.

[RFC4941]に記載されているように、IPv4アドレスを使用するホストと、IPv6アドレスでIIDを生成するためにIEEE識別子を使用するホストでは、相関が同じように実行できる場合があります。 静的IPv4アドレスを使用するホスト、またはDHCPv4を介して常に同じアドレスが割り当てられているホストは、上記のように追跡できます。 ただし、リースの満了時に同じホストに異なるアドレスを割り当てるNATとDHCPv4の両方の実装が広く使用されているため、IPv6のIEEE識別子の場合と比較して、IPv4の場合はこの脅威が緩和されます。


3.2.  Location Tracking

3.2。 位置追跡


   Because the IPv6 address structure is divided between a topological
   portion and an interface identifier portion, an interface identifier
   that remains constant when a host connects to different IPv6 links
   (as an IEEE-identifier-based IID does) provides a way for observers
   to track the movements of that host.  In a passive attack on a mobile
   host, a server that receives connections from the same host over time
   would be able to determine the host's movements as its prefix
   changes.

IPv6アドレス構造はトポロジー部分とインターフェイス識別子部分に分かれているため、ホストが別のIPv6リンクに接続したときに(IEEE識別子ベースのIIDが行うように)一定のインターフェイス識別子は、オブザーバーが そのホストの動き。 モバイルホストに対するパッシブ攻撃では、時間の経過とともに同じホストから接続を受信するサーバーは、プレフィックスが変化したときのホストの動きを判別できます。


   Active attacks are also possible.  An attacker that first learns the
   host's interface identifier by being connected to the same IPv6 link,
   running a server that the host connects to, or being on path to the
   host's communications could subsequently probe other networks for the
   presence of the same interface identifier by sending a probe packet
   (e.g., ICMPv6 Echo Request, or any other probe packet).  Even if the
   host does not respond, the first-hop router will usually respond with
   an ICMP Destination Unreachable/Address Unreachable (type 1, code 3)
   when the host is not present and be silent when the host is present.

アクティブな攻撃も可能です。 同じIPv6リンクに接続され、ホストが接続するサーバーを実行し、またはホストの通信へのパス上にいることにより、ホストのインターフェース識別子を最初に学習する攻撃者は、その後、送信することにより、同じインターフェース識別子の存在について他のネットワークをプローブする可能性があります。 プローブパケット(ICMPv6エコー要求、その他のプローブパケットなど)。 ホストが応答しない場合でも、通常、ファーストホップルーターは、ホストが存在しない場合はICMP宛先到達不能/アドレス到達不能(タイプ1、コード3)で応答し、ホストが存在する場合は応答しません。


   Location tracking based on IP address is generally not possible in
   IPv4 since hosts get assigned wholly new addresses when they change
   networks.

ホストがネットワークを変更すると完全に新しいアドレスが割り当てられるため、IPv4ではIPアドレスに基づく位置追跡は一般に不可能です。




Cooper, et al.                Informational                     [Page 6]

RFC 7721             IPv6 Address Generation Privacy          March 2016


3.3.  Address Scanning

3.3。 アドレススキャン


   The structure of IEEE-based identifiers used for address generation
   can be leveraged by an attacker to reduce the target search space
   [RFC7707].  The 24-bit Organizationally Unique Identifier (OUI) of
   MAC addresses, together with the fixed value (0xff, 0xfe) used to
   form a Modified EUI-64 interface identifier, greatly help to reduce
   the search space, making it easier for an attacker to scan for
   individual addresses using widely known popular OUIs.  This erases
   much of the protection against address scanning that the larger IPv6
   address space could provide as compared to IPv4.

攻撃者は、アドレス生成に使用されるIEEEベースの識別子の構造を利用して、ターゲット検索スペースを削減できます[RFC7707]。 MACアドレスの24ビットの組織固有識別子(OUI)と、Modified EUI-64インターフェイス識別子の形成に使用される固定値(0xff、0xfe)により、検索スペースを大幅に削減し、攻撃者が簡単に 広く知られている一般的なOUIを使用して個々のアドレスをスキャンします。 これにより、IPv4と比較してより大きなIPv6アドレス空間が提供できるアドレススキャンに対する保護の多くが失われます。


3.4.  Device-Specific Vulnerability Exploitation

3.4。 デバイス固有の脆弱性の悪用


   IPv6 addresses that embed IEEE identifiers leak information about the
   device (e.g., Network Interface Card vendor, or even Operating System
   and/or software type), which could be leveraged by an attacker with
   knowledge of device- or software-specific vulnerabilities to quickly
   find possible targets.  Attackers can exploit vulnerabilities in
   hosts whose IIDs they have previously obtained or scan an address
   space to find potential targets.

IEEE識別子を埋め込んだIPv6アドレスは、デバイス(ネットワークインターフェイスカードベンダー、オペレーティングシステムやソフトウェアの種類など)に関する情報を漏らします。これは、デバイスまたはソフトウェア固有の脆弱性の知識を持つ攻撃者が悪用して、すばやく見つけることができます。 可能なターゲット。 攻撃者は、以前に入手したIIDを持つホストの脆弱性を悪用するか、アドレス空間をスキャンして潜在的なターゲットを見つけることができます。


4.  Privacy and Security Properties of Address Generation Mechanisms

4.アドレス生成メカニズムのプライバシーとセキュリティのプロパティ


   Analysis of the extent to which a particular host is protected
   against the attacks described in Section 3 depends on how each of a
   host's addresses is generated and used.  In some scenarios, a host
   configures a single global address and uses it for all
   communications.  In other scenarios, a host configures multiple
   addresses using different mechanisms and may use any or all of them.

特定のホストがセクション3で説明した攻撃から保護されている範囲の分析は、各ホストのアドレスがどのように生成および使用されるかに依存します。 一部のシナリオでは、ホストが単一のグローバルアドレスを構成し、それをすべての通信に使用します。 他のシナリオでは、ホストは異なるメカニズムを使用して複数のアドレスを構成し、それらのいずれかまたはすべてを使用する場合があります。


   [RFC3041] (later obsoleted by [RFC4941]) sought to address some of
   the problems described in Section 3 by defining "temporary addresses"
   for outbound connections.  Temporary addresses are meant to
   supplement the other addresses that a device might use, not to
   replace them.  They use IIDs that are randomly generated and change
   daily by default.  The idea was for temporary addresses to be used
   for outgoing connections (e.g., web browsing) while maintaining the
   ability to use a stable address when more address stability is
   desired (e.g., for IPv6 addresses published in the DNS).

[RFC3041](後で[RFC4941]で廃止)は、アウトバウンド接続の「一時アドレス」を定義することにより、セクション3で説明されている問題のいくつかに対処しようとしました。 一時アドレスは、デバイスが使用する可能性がある他のアドレスを補足するためのものであり、それらを置き換えるためのものではありません。 それらはランダムに生成され、デフォルトで毎日変更されるIIDを使用します。 より安定したアドレスが必要な場合に安定したアドレスを使用できるようにしながら(DNSで公開されたIPv6アドレスなど)、一時的なアドレスを発信接続(Webの閲覧など)に使用するというアイデアでした。


   [RFC3484] originally specified that stable addresses be used for
   outbound connections unless an application explicitly prefers
   temporary addresses.  The default preference for stable addresses was
   established to avoid applications potentially failing due to the
   short lifetime of temporary addresses or the possibility of a reverse
   look-up failure or error.  However, [RFC3484] allowed that
   "implementations for which privacy considerations outweigh these



Cooper, et al.                Informational                     [Page 7]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   application-compatibility concerns MAY reverse the sense of this
   rule" and instead prefer by default temporary addresses rather than
   stable addresses.  Indeed, most implementations (notably including
   Windows) chose to default to temporary addresses for outbound
   connections since privacy was considered more important (and few
   applications supported IPv6 at the time, so application compatibility
   concerns were minimal).  [RFC6724] then obsoleted [RFC3484] and
   changed the default to match what implementations actually did.

[RFC3484]は、アプリケーションが一時アドレスを明示的に優先しない限り、アウトバウンド接続に安定したアドレスを使用することを最初に指定しました 安定したアドレスのデフォルト設定は、一時アドレスの有効期間が短いためにアプリケーションが失敗する可能性、または逆ルックアップの失敗またはエラーの可能性を回避するために確立されました。 ただし、[RFC3484]は、「プライバシーの考慮事項がこれらのアプリケーション互換性の懸念よりも重要な実装は、このルールの意味を逆転させる可能性がある」ことを許可し、代わりにデフォルトで、安定したアドレスではなく一時アドレスを優先します。 実際、ほとんどの実装(特にWindowsを含む)では、プライバシーがより重要であると考えられていたため(およびその時点でIPv6をサポートするアプリケーションはほとんどなかったため、アプリケーションの互換性の懸念は最小限でした)、デフォルトで送信接続の一時アドレスを選択しました。 [RFC6724]は[RFC3484]を廃止し、実装が実際に行ったことと一致するようにデフォルトを変更しました。


   The envisioned relationship in [RFC3484] between stability of an
   address and its use in "public" can be misleading when conducting
   privacy analysis.  The stability of an address and the extent to
   which it is linkable to some other public identifier are independent
   of one another.  For example, there is nothing that prevents a host
   from publishing a temporary address in a public place, such as the
   DNS.  Publishing both a stable address and a temporary address in the
   DNS or elsewhere where they can be linked together by a public
   identifier allows the host's activities when using either address to
   be correlated together.

[RFC3484]で想定されている、アドレスの安定性と「パブリック」でのその使用との関係は、プライバシー分析を行うときに誤解を招く可能性があります。 アドレスの安定性と、他の公開識別子にリンクできる範囲は、互いに独立しています。 たとえば、ホストがDNSなどの公共の場所で一時アドレスを公開するのを妨げるものはありません。 安定したアドレスと一時的なアドレスの両方をDNSまたはその他の場所で公開識別子によってリンクできる場所に公開すると、どちらかのアドレスを使用する場合のホストのアクティビティを相互に関連付けることができます。


   Moreover, because temporary addresses were designed to supplement
   other addresses generated by a host, the host may still configure a
   more stable address even if it only ever intentionally uses temporary
   addresses (as source addresses) for communication to off-link
   destinations.  An attacker can probe for the stable address even if
   it is never used as such a source address or advertised outside the
   link (e.g., in DNS or SIP).

さらに、一時アドレスはホストによって生成された他のアドレスを補足するように設計されているため、オフリンク宛先への通信に一時アドレス(送信元アドレスとして)を意図的に使用する場合でも、ホストはより安定したアドレスを構成できます。 攻撃者は、そのアドレスが送信元アドレスとして使用されたり、リンクの外部(DNSやSIPなど)でアドバタイズされたりしなかったとしても、安定したアドレスをプローブできます。


   This section compares the privacy and security properties of a
   variety of IID generation mechanisms and their possible usage
   scenarios, including scenarios in which a single mechanism is used to
   generate all of a host's IIDs and those in which temporary addresses
   are used together with addresses generated using a different IID
   generation mechanism.  The analysis of the exposure of each IID type
   to correlation assumes that IPv6 prefixes are shared by a reasonably
   large number of nodes.  As [RFC4941] notes, if a very small number of
   nodes (say, only one) use a particular prefix for an extended period
   of time, the prefix itself can be used to correlate the host's
   activities regardless of how the IID is generated.  For example,
   [RFC3314] recommends that prefixes be uniquely assigned to mobile
   handsets where IPv6 is used within General Packet Radio Service
   (GPRS).  In cases where this advice is followed and prefixes persist
   for extended periods of time (or get reassigned to the same handsets
   whenever those handsets reconnect to the same network router), hosts'
   activities could be correlatable for longer periods than the analysis
   below would suggest.

このセクションでは、さまざまなIID生成メカニズムのプライバシーとセキュリティのプロパティ、およびそれらの可能な使用シナリオを比較します。これには、単一のメカニズムを使用してホストのすべてのIIDを生成するシナリオや、一時アドレスを使用して生成されるアドレスと一緒に使用するシナリオが含まれます。異なるIID生成メカニズム。 各IIDタイプの相関関係への露出の分析では、IPv6プレフィックスがかなり多数のノードで共有されていると想定しています。 [RFC4941]が注記しているように、ごく少数のノード(たとえば、1つだけ)が特定のプレフィックスを長期間使用する場合、プレフィックス自体を使用して、IIDの生成方法に関係なく、ホストのアクティビティを関連付けることができます。 たとえば、[RFC3314]は、IPv6がGeneral Packet Radio Service(GPRS)内で使用されるモバイルハンドセットにプレフィックスを一意に割り当てることを推奨しています。 このアドバイスに従い、プレフィックスが長期間持続する場合(または、それらのハンドセットが同じネットワークルーターに再接続するたびに同じハンドセットに再割り当てされる場合)、ホストのアクティビティは、以下の分析が示唆するよりも長い期間相関する可能性があります。






Cooper, et al.                Informational                     [Page 8]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   The table below provides a summary of the whole analysis.  A "No"
   entry indicates that the attack is prevented from being carried out
   on the basis of the IID, but the host may still be vulnerable
   depending on how it employs other protocols.

以下の表は、分析全体の概要を示しています。 「いいえ」のエントリは、攻撃がIIDに基づいて実行されるのを防ぐことを示しますが、ホストが他のプロトコルをどのように使用しているかによっては、依然として脆弱である可能性があります。


   +--------------+-------------+----------+-------------+-------------+
   | Mechanism(s) | Correlation | Location | Address     | Device      |
   |              |             | tracking | scanning    | exploits    |
   +--------------+-------------+----------+-------------+-------------+
   | IEEE         | For device  | For      | Possible    | Possible    |
   | identifier   | lifetime    | device   |             |             |
   |              |             | lifetime |             |             |
   |              |             |          |             |             |
   | Static       | For address | For      | Depends on  | Depends on  |
   | manual       | lifetime    | address  | generation  | generation  |
   |              |             | lifetime | mechanism   | mechanism   |
   |              |             |          |             |             |
   | Constant,    | For address | For      | No          | No          |
   | semantically | lifetime    | address  |             |             |
   | opaque       |             | lifetime |             |             |
   |              |             |          |             |             |
   | CGA          | For         | No       | No          | No          |
   |              | lifetime of |          |             |             |
   |              | (modifier   |          |             |             |
   |              | block +     |          |             |             |
   |              | public key) |          |             |             |
   |              |             |          |             |             |
   | Stable,      | Within      | No       | No          | No          |
   | semantically | single IPv6 |          |             |             |
   | opaque       | link        |          |             |             |
   |              |             |          |             |             |
   | Temporary    | For temp    | No       | No          | No          |
   |              | address     |          |             |             |
   |              | lifetime    |          |             |             |
   |              |             |          |             |             |
   | DHCPv6       | For lease   | No       | Depends on  | No          |
   |              | lifetime    |          | generation  |             |
   |              |             |          | mechanism   |             |
   +--------------+-------------+----------+-------------+-------------+

   Table 1: Privacy and Security Properties of IID Generation Mechanisms

表1:IID生成メカニズムのプライバシーおよびセキュリティプロパティ











Cooper, et al.                Informational                     [Page 9]

RFC 7721             IPv6 Address Generation Privacy          March 2016


4.1.  IEEE-Identifier-Based IIDs

4.1。 IEEE識別子ベースのIID


   As discussed in Section 3, addresses that use IIDs based on IEEE
   identifiers are vulnerable to all four attacks.  They allow
   correlation and location tracking for the lifetime of the device
   since IEEE identifiers last that long and their structure makes
   address scanning and device exploits possible.

セクション3で説明したように、IEEE識別子に基づくIIDを使用するアドレスは、4つすべての攻撃に対して脆弱です。 IEEE識別子はその長さを持ち、その構造によってアドレススキャンとデバイスの悪用が可能になるため、デバイスの寿命の相関と位置追跡が可能です。


4.2.  Static, Manually Configured IIDs

4.2。 静的、手動で構成されたIID


   Because static, manually configured IIDs are stable, both correlation
   and location tracking are possible for the life of the address.

手動で構成された静的なIIDは安定しているため、アドレスの存続期間中、相関と位置追跡の両方が可能です。


   The extent to which location tracking can be successfully performed
   depends, to some extent, on the uniqueness of the employed IID.  For
   example, one would expect "low byte" IIDs to be more widely reused
   than, for example, IIDs where the whole 64 bits follow some pattern
   that is unique to a specific organization.  Widely reused IIDs will
   typically lead to false positives when performing location tracking.

位置追跡を正常に実行できる範囲は、ある程度、採用されたIIDの一意性に依存します。 たとえば、「低バイト」のIIDは、たとえば、64ビット全体が特定の組織に固有のパターンに従うIIDよりも広く再利用されると予想されます。 広く再利用されているIIDは、通常、位置追跡の実行時に誤検知を引き起こします。


   Whether manually configured addresses are vulnerable to address
   scanning and device exploits depends on the specifics of how the IIDs
   are generated.

手動で構成されたアドレスがアドレススキャンやデバイスエクスプロイトに対して脆弱かどうかは、IIDの生成方法の詳細によって異なります。


4.3.  Constant, Semantically Opaque IIDs

4.3。 一定で、意味的に不透明なIID


   Although a mechanism to generate a constant, semantically opaque IID
   has not been standardized, it has been in wide use for many years on
   at least one platform (Windows).  Windows uses the random generation
   mechanism described in [RFC4941] in lieu of generating an IEEE-
   identifier-based IID.  This mitigates the device-specific
   exploitation and address-scanning attacks but still allows
   correlation and location tracking because the IID is constant across
   IPv6 links and time.

一定の意味的に不透明なIIDを生成するメカニズムは標準化されていませんが、少なくとも1つのプラットフォーム(Windows)で長年にわたって広く使用されています。 Windowsは、IEEE識別子ベースのIIDを生成する代わりに、[RFC4941]で説明されているランダム生成メカニズムを使用します。 これにより、デバイス固有の悪用やアドレススキャン攻撃が軽減されますが、IIDはIPv6リンクと時間全体で一定であるため、相関と位置追跡が可能になります。


4.4.  Cryptographically Generated IIDs

4.4。 暗号的に生成されたIID


   Cryptographically Generated Addresses (CGAs) [RFC3972] bind a hash of
   the host's public key to an IPv6 address in the SEcure Neighbor
   Discovery (SEND) protocol [RFC3971].  CGAs may be regenerated for
   each subnet prefix, but this is not required given that they are
   computationally expensive to generate.  A host using a CGA can be
   correlated for as long as the lifetime of the combination of the
   public key and the chosen modifier block since it is possible to
   rotate modifier blocks without generating new public keys.  Because
   the cryptographic hash of the host's public key uses the subnet
   prefix as an input, even if the host does not generate a new public
   key or modifier block when it moves to a different IPv6 link, its



Cooper, et al.                Informational                    [Page 10]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   location cannot be tracked via the IID.  CGAs do not allow device-
   specific exploitation or address-scanning attacks.

暗号化生成アドレス(CGA)[RFC3972]は、ホストの公開鍵のハッシュをSEcure Neighbor Discovery(SEND)プロトコル[RFC3971]のIPv6アドレスにバインドします。 CGAはサブネットプレフィックスごとに再生成できますが、生成するのに計算コストがかかるため、これは必要ありません。 新しい公開鍵を生成せずに修飾子ブロックをローテーションすることができるため、CGAを使用するホストは、公開鍵と選択された修飾子ブロックの組み合わせの存続期間にわたって相関させることができます。 ホストの公開キーの暗号化ハッシュはサブネットプレフィックスを入力として使用するため、ホストが別のIPv6リンクに移動するときにホストが新しい公開キーまたは修飾子ブロックを生成しない場合でも、その場所はIIDを介して追跡できません。 CGAは、デバイス固有の攻撃やアドレススキャン攻撃を許可しません。


4.5.  Stable, Semantically Opaque IIDs

4.5。 安定した、意味的に不透明なIID


   [RFC7217] specifies an algorithm that generates, for each network
   interface, a unique random IID per IPv6 link.  The aforementioned
   algorithm is employed not only for global unicast addresses, but also
   for unique local unicast addresses and link-local unicast addresses
   since these addresses may leak out via application protocols (e.g.,
   IPv6 addresses embedded in email headers).

[RFC7217]は、IPv6リンクごとに一意のランダムIIDをネットワークインターフェイスごとに生成するアルゴリズムを指定します。 上記のアルゴリズムは、グローバルユニキャストアドレスだけでなく、一意のローカルユニキャストアドレスやリンクローカルユニキャストアドレスにも使用されます。これらのアドレスは、アプリケーションプロトコル(電子メールヘッダーに埋め込まれたIPv6アドレスなど)を介して漏出する可能性があるためです。


   A host that stays connected to the same IPv6 link could therefore be
   tracked at length, whereas a mobile host's activities could only be
   correlated for the duration of each network connection.  Location
   tracking is not possible with these addresses.  They also do not
   allow device-specific exploitation or address-scanning attacks.

したがって、同じIPv6リンクに接続されたままであるホストは追跡できますが、モバイルホストのアクティビティは、各ネットワーク接続の期間中のみ相関できます。 これらの住所では位置追跡はできません。 また、デバイス固有の攻撃やアドレススキャン攻撃も許可されません。


4.6.  Temporary IIDs

4.6 一時的なIID


   A host that uses only a temporary address mitigates all four threats.
   Its activities may only be correlated for the lifetime of a single
   temporary address.

一時アドレスのみを使用するホストは、4つの脅威すべてを軽減します。 その活動は、単一の一時アドレスの存続期間中のみ相関されます。


   A host that configures both an IEEE-identifier-based IID and
   temporary addresses makes the host vulnerable to the same attacks as
   if temporary addresses were not in use, although the viability of
   some of them depends on how the host uses each address.  An attacker
   can correlate all of the host's activities for which it uses its
   IEEE-identifier-based IID.  Once an attacker has obtained the IEEE-
   identifier-based IID, location tracking becomes possible on other
   IPv6 links even if the host only makes use of temporary addresses on
   those other IPv6 links; the attacker can actively probe the other
   IPv6 links for the presence of the IEEE-identifier-based IID.
   Device-specific vulnerabilities can still be exploited.  Address
   scanning is also still possible because the IEEE-identifier-based
   address can be probed.

IEEE識別子ベースのIIDと一時アドレスの両方を構成するホストは、一時アドレスが使用されていない場合と同じ攻撃に対してホストを脆弱にしますが、それらのいくつかの実行可能性は、ホストが各アドレスをどのように使用するかに依存します。 攻撃者は、IEEE識別子ベースのIIDを使用するホストのすべてのアクティビティを関連付けることができます。 攻撃者がIEEE識別子ベースのIIDを取得すると、ホストが他のIPv6リンク上の一時アドレスのみを使用する場合でも、他のIPv6リンク上で位置追跡が可能になります。 攻撃者は、IEEE識別子ベースのIIDが存在するかどうか、他のIPv6リンクをアクティブにプローブできます。 デバイス固有の脆弱性は引き続き悪用される可能性があります。 IEEE識別子ベースのアドレスをプローブできるため、アドレススキャンも可能です。


   If the host instead generates a constant, semantically opaque IID to
   use in a stable address for server-like connections together with
   temporary addresses for outbound connections (as is the default in
   Windows), it sees some improvements over the previous scenario.  The
   address-scanning attacks and device-specific exploitation attacks are
   no longer possible because the OUI is no longer embedded in any of
   the host's addresses.  However, correlation of some activities across
   time and location tracking are both still possible because the
   semantically opaque IID is constant.  And once an attacker has
   obtained the host's semantically opaque IID, location tracking is



Cooper, et al.                Informational                    [Page 11]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   possible on any network by probing for that IID, even if the host
   only uses temporary addresses on those networks.  However, if the
   host generates but never uses a constant, semantically opaque IID, it
   mitigates all four threats.

代わりに、ホストが一定の意味的に不透明なIIDを生成して、サーバーのような接続の安定したアドレスと、発信接続の一時アドレス(Windowsのデフォルト)を併用すると、前のシナリオに比べていくつかの改善が見られます。 OUIがホストのどのアドレスにも組み込まれていないため、アドレススキャン攻撃およびデバイス固有の悪用攻撃はできなくなりました。 ただし、意味的に不透明なIIDが一定であるため、時間を超えたいくつかのアクティビティの相関と位置追跡はどちらも可能です。 また、攻撃者がホストの意味的に不透明なIIDを取得すると、ホストがそれらのネットワークで一時アドレスのみを使用している場合でも、そのIIDをプローブすることにより、任意のネットワークで位置追跡が可能になります。 ただし、ホストが一定の意味的に不透明なIIDを生成するが使用しない場合は、4つの脅威すべてを軽減します。


   When used together with temporary addresses, the stable, semantically
   opaque IID generation mechanism [RFC7217] improves upon the previous
   scenario by limiting the potential for correlation to the lifetime of
   the stable address (which may still be lengthy for hosts that are not
   mobile) and by eliminating the possibility for location tracking
   (since a different IID is generated for each subnet prefix).  As in
   the previous scenario, a host that configures but does not use a
   stable, semantically opaque address mitigates all four threats.

一時的なアドレスと一緒に使用すると、安定した意味的に不透明なIID生成メカニズム[RFC7217]は、相関の可能性を安定したアドレスの存続期間に制限することにより、以前のシナリオを改善します(モバイルではないホストではまだ長くなる可能性があります)。 ロケーショントラッキングの可能性を排除することにより(サブネットプレフィックスごとに異なるIIDが生成されるため)。 前のシナリオと同様に、安定した意味的に不透明なアドレスを構成するが使用しないホストは、4つの脅威すべてを軽減します。


4.7.  DHCPv6 Generation of IIDs

4.7。 DHCPv6によるIIDの生成


   The security and privacy implications of DHCPv6-based addresses will
   typically depend on whether the client requests an IA_NA (Identity
   Association for Non-temporary Addresses) or an IA_TA (Identity
   Association for Temporary Addresses) [RFC3315] and the specific
   DHCPv6 server software being employed.

DHCPv6ベースのアドレスのセキュリティとプライバシーへの影響は通常、クライアントがIA_NA(非一時アドレスのIDアソシエーション)またはIA_TA(一時アドレスのIDアソシエーション)[RFC3315]を要求するかどうか、および使用されている特定のDHCPv6サーバーソフトウェアによって異なります。 。


   DHCPv6 temporary addresses have the same properties as SLAAC
   temporary addresses (see Section 4.6).  On the other hand, the
   properties of DHCPv6 non-temporary addresses typically depend on the
   specific DHCPv6 server software being employed.  Recent releases of
   most popular DHCPv6 server software typically lease random addresses
   with a similar lease time as that of IPv4.  Thus, these addresses can
   be considered to be "stable, semantically opaque".  [DHCPv6-IID]
   specifies an algorithm that can be employed by DHCPv6 servers to
   generate "stable, semantically opaque" addresses.

DHCPv6一時アドレスには、SLAAC一時アドレスと同じプロパティがあります(セクション4.6を参照)。 一方、DHCPv6非一時アドレスのプロパティは、通常、使用されている特定のDHCPv6サーバーソフトウェアに依存します。 最も一般的なDHCPv6サーバーソフトウェアの最近のリリースでは、通常、IPv4と同様のリース時間でランダムアドレスをリースします。 したがって、これらのアドレスは「安定した、意味的に不透明」であると見なすことができます。 [DHCPv6-IID]は、DHCPv6サーバーが「安定した、意味的に不透明な」アドレスを生成するために使用できるアルゴリズムを指定します。


   On the other hand, some DHCPv6 software leases sequential addresses
   (typically low-byte addresses).  These addresses can be considered to
   be stable addresses.  The drawback of this address generation scheme
   compared to "stable, semantically opaque" addresses is that, since
   they follow specific patterns, they enable IPv6 address scans.

一方、一部のDHCPv6ソフトウェアは、連続したアドレス(通常は低バイトアドレス)をリースします。 これらのアドレスは、安定したアドレスと見なすことができます。 「安定した、意味的に不透明な」アドレスと比較したこのアドレス生成スキームの欠点は、特定のパターンに従うため、IPv6アドレススキャンが可能になることです。


4.8.  Transition and Coexistence Technologies

4.8。 移行および共存テクノロジ


   Addresses specified based on transition or coexistence technologies
   that embed an IPv4 address within an IPv6 address are not included in
   Table 1 because their privacy and security properties are inherited
   from the embedded address.  For example, Teredo [RFC4380] specifies a
   means to generate an IPv6 address from the underlying IPv4 address
   and port, leaving many other bits set to zero.  This makes it
   relatively easy for an attacker to scan for IPv6 addresses by
   guessing the Teredo client's IPv4 address and port (which for many



Cooper, et al.                Informational                    [Page 12]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   NATs is not randomized).  For this reason, popular implementations
   (e.g., Windows) began deviating from the standard by including 12
   random bits in place of zero bits.  This modification was later
   standardized in [RFC5991].

IPv4アドレスをIPv6アドレス内に埋め込む遷移または共存テクノロジに基づいて指定されたアドレスは、プライバシーとセキュリティのプロパティが埋め込みアドレスから継承されるため、表1には含まれていません。 たとえば、Teredo [RFC4380]は、基礎となるIPv4アドレスとポートからIPv6アドレスを生成し、他の多くのビットをゼロに設定する手段を指定しています。 これにより、攻撃者はTeredoクライアントのIPv4アドレスとポート(多くのNATではランダム化されていません)を推測することで、IPv6アドレスをスキャンすることが比較的簡単になります。 このため、一般的な実装(Windowsなど)は、ゼロビットの代わりに12個のランダムビットを含めることにより、標準から逸脱し始めました。 この修正は後で[RFC5991]で標準化されました。


   Some other transition technologies (e.g., [RFC5214], [RFC6052])
   specify means to generate an IPv6 address from an underlying IPv4
   address without a port.  Such mechanisms thus make it much easier for
   an attacker to conduct an address scan than for mechanisms that
   require finding a port number as well.

他のいくつかの移行テクノロジー([RFC5214]、[RFC6052]など)は、ポートのない基礎となるIPv4アドレスからIPv6アドレスを生成する手段を指定しています。 したがって、このようなメカニズムにより、ポート番号を見つける必要があるメカニズムよりも、攻撃者がアドレススキャンを実行するのがはるかに簡単になります。


   Finally, still other mechanisms (e.g., [RFC7596], [RFC7597],
   [RFC7599]) are somewhere in between, using an IPv4 address and a port
   set ID (which for many NATs is not randomized).  In general, such
   mechanisms are thus typically as easy to scan as in the Teredo
   example above without the 12-bit mitigation.

最後に、さらに他のメカニズム([RFC7596]、[RFC7597]、[RFC7599]など)は、IPv4アドレスとポートセットID(多くのNATではランダム化されていません)を使用して、その中間にあります。 したがって、一般に、このようなメカニズムは、通常、上記のTeredoの例と同じように、12ビットの軽減策なしでスキャンするのが簡単です。


5.  Miscellaneous Issues with IPv6 Addressing

5. IPv6アドレッシングに関するその他の問題


5.1.  Network Operation

5.1。 ネットワーク運用


   It is generally agreed that IPv6 addresses that vary over time in a
   specific IPv6 link tend to increase the complexity of event logging,
   trouble-shooting, enforcement of access controls and quality of
   service, etc.  As a result, some organizations disable the use of
   temporary addresses [RFC4941] even at the expense of reduced privacy
   [Broersma].

特定のIPv6リンクで時間とともに変化するIPv6アドレスは、イベントロギング、トラブルシューティング、アクセス制御の実施、サービスの品質などの複雑さを増す傾向があることは一般的に同意されています。 その結果、一部の組織では、プライバシーの低下[Broersma]を犠牲にしても、一時アドレス[RFC4941]の使用を無効にしています。


5.2.  Compliance

5.2。 コンプライアンス


   Some IPv6 compliance testing suites required (and might still
   require) implementations to support IEEE-identifier-based IIDs in
   order to be approved as compliant.  This document recommends that
   compliance testing suites be relaxed to allow other forms of address
   generation that are more amenable to privacy.

一部のIPv6準拠テストスイートは、準拠として承認されるために、IEEE識別子ベースのIIDをサポートするための実装が必要です(まだ必要な場合があります)。 このドキュメントでは、コンプライアンステストスイートを緩和して、プライバシーの影響を受けやすい他の形式のアドレス生成を許可することを推奨しています。


5.3.  Intellectual Property Rights (IPRs)

5.3。 知的財産権(IPR)


   Some IPv6 addressing techniques might be covered by Intellectual
   Property rights, which might limit their implementation in different
   operating systems.  [CGA-IPR] and [KAME-CGA] discuss the IPRs on
   CGAs.

一部のIPv6アドレッシング手法は、知的財産権の対象となる場合があり、異なるオペレーティングシステムでの実装を制限する場合があります。 [CGA-IPR]および[KAME-CGA]は、CGAのIPRについて議論します。


6.  Security Considerations

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


   This whole document concerns the privacy and security properties of
   different IPv6 address generation mechanisms.

このドキュメント全体は、さまざまなIPv6アドレス生成メカニズムのプライバシーとセキュリティのプロパティに関するものです。





Cooper, et al.                Informational                    [Page 13]

RFC 7721             IPv6 Address Generation Privacy          March 2016


7.  References

7.リファレンス


7.1.  Normative References

7.1。 規範的な参考文献


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <http://www.rfc-editor.org/info/rfc2464>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,
              <http://www.rfc-editor.org/info/rfc3971>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <http://www.rfc-editor.org/info/rfc3972>.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              DOI 10.17487/RFC4380, February 2006,
              <http://www.rfc-editor.org/info/rfc4380>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

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

   [RFC5991]  Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
              Security Updates", RFC 5991, DOI 10.17487/RFC5991,
              September 2010, <http://www.rfc-editor.org/info/rfc5991>.






Cooper, et al.                Informational                    [Page 14]

RFC 7721             IPv6 Address Generation Privacy          March 2016


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

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

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

7.2.  Informative References

7.2。 参考情報


   [Broersma] Broersma, R., "IPv6 Everywhere: Living with a Fully
              IPv6-enabled environment",  Australian IPv6 Summit 2010,
              Melbourne, VIC Australia, October 2010,
              <http://www.ipv6.org.au/10ipv6summit/talks/
              Ron_Broersma.pdf>.

   [CGA-IPR]  IETF, "IPR Details: Microsoft's Statement about IPR
              claimed in RFC 3972", November 2005,
              <https://datatracker.ietf.org/ipr/676/>.

   [DHCPv6-IID]
              Gont, F. and W. Liu, "A Method for Generating Semantically
              Opaque Interface Identifiers with Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", Work in
              Progress, draft-ietf-dhc-stable-privacy-addresses-02,
              April 2015.

   [KAME-CGA] The KAME Project, "The KAME IPR policy and concerns of
              some technologies which have IPR claims", November 2005,
              <http://www.kame.net/newsletter/20040525/>.

   [Microsoft]
              Microsoft, "IPv6 interface identifiers", 2013,
              <http://www.microsoft.com/resources/documentation/
              windows/xp/all/proddocs/en-us/
              sag_ip_v6_imp_addr7.mspx?mfr=true>.

   [Panopticlick]
              Electronic Frontier Foundation, "Panopticlick", 2011,
              <http://panopticlick.eff.org>.




Cooper, et al.                Informational                    [Page 15]

RFC 7721             IPv6 Address Generation Privacy          March 2016


   [RFC1971]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August
              1996, <http://www.rfc-editor.org/info/rfc1971>.

   [RFC1972]  Crawford, M., "A Method for the Transmission of IPv6
              Packets over Ethernet Networks", RFC 1972,
              DOI 10.17487/RFC1972, August 1996,
              <http://www.rfc-editor.org/info/rfc1972>.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              DOI 10.17487/RFC3041, January 2001,
              <http://www.rfc-editor.org/info/rfc3041>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3314]  Wasserman, M., Ed., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, DOI 10.17487/RFC3314, September 2002,
              <http://www.rfc-editor.org/info/rfc3314>.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484,
              DOI 10.17487/RFC3484, February 2003,
              <http://www.rfc-editor.org/info/rfc3484>.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              DOI 10.17487/RFC5214, March 2008,
              <http://www.rfc-editor.org/info/rfc5214>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <http://www.rfc-editor.org/info/rfc6052>.

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








Cooper, et al.                Informational                    [Page 16]

RFC 7721             IPv6 Address Generation Privacy          March 2016


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

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

   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <http://www.rfc-editor.org/info/rfc7596>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,
              <http://www.rfc-editor.org/info/rfc7597>.

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <http://www.rfc-editor.org/info/rfc7599>.

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




















Cooper, et al.                Informational                    [Page 17]

RFC 7721             IPv6 Address Generation Privacy          March 2016


Acknowledgements

   The authors would like to thank Bernard Aboba, Brian Carpenter, Tim
   Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz,
   Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for
   providing valuable comments on earlier draft versions of this
   document.

Authors' Addresses

   Alissa Cooper
   Cisco
   707 Tasman Drive
   Milpitas, CA  95035
   United States

   Phone: +1-408-902-3950
   Email: alcoop@cisco.com
   URI:   https://www.cisco.com/

   Fernando Gont
   Huawei Technologies
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

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


   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   United States

   Phone: +1 425 703 8835
   Email: dthaler@microsoft.com












Cooper, et al.                Informational                    [Page 18]