RFC 8064 - Recommendation on Stable IPv6 Interface Identifiers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8064
タイトル : RFC 8064 - 安定したIPv6インターフェース識別子に関する推奨事項
翻訳編集 : 自動生成

[要約] RFC 8064は、IPv6インターフェース識別子の安定性に関する推奨事項を提供しています。その目的は、ネットワークの安定性とセキュリティを向上させるために、IPv6インターフェース識別子の生成方法に関するガイドラインを提供することです。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 8064                        SI6 Networks / UTN-FRH
Updates: 2464, 2467, 2470, 2491, 2492,                         A. Cooper
         2497, 2590, 3146, 3572, 4291,                             Cisco
         4338, 4391, 5072, 5121                                D. Thaler
Category: Standards Track                                      Microsoft
ISSN: 2070-1721                                                   W. Liu
                                                     Huawei Technologies
                                                           February 2017

Recommendation on Stable IPv6 Interface Identifiers

安定したIPv6インターフェース識別子に関する推奨事項

Abstract

概要

This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.

このドキュメントでは、ステートレスアドレス自動構成（SLAAC）を使用して安定したIPv6アドレスを生成する場合に推奨されるデフォルトのインターフェース識別子（IID）生成スキームを変更します。そのような場合は、RFC 7217で指定されたメカニズムを使用することをお勧めします。また、IPv6 IIDに安定したリンク層アドレスを埋め込むことはお勧めしません。 RFC 2464、RFC 2467、RFC 2470、RFC 2491、RFC 2492、RFC 2497、RFC 2590、RFC 3146、RFC 3572、RFC 4291、RFC 4338、RFC 4391、RFC 5072、およびRFC 5121を正式に更新します。このドキュメントでは、 RFC 4941で指定されている一時アドレスの使用に関する既存の推奨事項を変更します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8064.

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

著作権表示

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.  Generation of IPv6 Interface Identifiers with SLAAC . . . . .   5
   4.  Future Work . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) [RFC4291] that typically embeds a stable link-layer address (e.g., an IEEE LAN MAC address).

[RFC4862]は、IPv6 [RFC2460]のステートレスアドレス自動構成（SLAAC）を指定します。これにより、ホストは通常、ローカルルーターによってアドバタイズされるネットワークプレフィックスとインターフェイス識別子（IID）で構成される1つ以上の「安定した」アドレスを構成します[RFC4291]これは通常、安定したリンク層アドレス（IEEE LAN MACアドレスなど）を埋め込みます。

In some network technologies and adaptation layers, the use of an IID based on a link-layer address may offer some advantages. For example, [RFC6282] allows for the compression of IPv6 datagrams over IEEE 802.15.4-based networks [RFC4944] when the IID is based on the underlying link-layer address.

一部のネットワーク技術と適応層では、リンク層アドレスに基づくIIDの使用がいくつかの利点を提供する場合があります。たとえば、[RFC6282]は、IIDが基礎となるリンク層アドレスに基づいている場合、IEEE 802.15.4ベースのネットワーク[RFC4944]を介したIPv6データグラムの圧縮を可能にします。

The security and privacy implications of embedding a stable link-layer address in an IPv6 IID have been known for some time now and are discussed in great detail in [RFC7721]. They include:

IPv6 IIDに安定したリンク層アドレスを埋め込むことのセキュリティとプライバシーへの影響は、しばらく前から知られており、[RFC7721]で詳細に説明されています。以下が含まれます：

o Network-activity correlation

o ネットワーク活動相関

o Location tracking

o 位置追跡

o Address scanning

o アドレススキャン

o Device-specific vulnerability exploitation

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

More generally, the reuse of identifiers that have their own semantics or properties across different contexts or scopes can be detrimental for security and privacy [NUM-IDS]. In the case of traditional stable IPv6 IIDs, some of the security and privacy implications are dependent on the properties of the underlying link-layer addresses (e.g., whether the link-layer address is ephemeral or randomly generated), while other implications (e.g., reduction of the entropy of the IID) depend on the algorithm for generating the IID itself. In standardized recommendations for stable IPv6 IID generation meant to achieve particular security and privacy properties, it is necessary to recommend against embedding stable link-layer addresses in IPv6 IIDs.

より一般的には、異なるコンテキストまたはスコープ全体で独自のセマンティクスまたはプロパティを持つ識別子を再利用すると、セキュリティとプライバシーが損なわれる可能性があります[NUM-IDS]。従来の安定したIPv6 IIDの場合、セキュリティとプライバシーの影響の一部は、基礎となるリンク層アドレスのプロパティ（たとえば、リンク層アドレスが一時的であるかランダムに生成されるか）に依存しますが、その他の影響（たとえば、ＩＩＤのエントロピーの低減）は、ＩＩＤ自体を生成するためのアルゴリズムに依存する。特定のセキュリティとプライバシーのプロパティを実現するための安定したIPv6 IID生成に関する標準化された推奨事項では、安定したリンク層アドレスをIPv6 IIDに埋め込まないように推奨する必要があります。

Furthermore, some popular IPv6 implementations have already deviated from the traditional stable IID generation scheme to mitigate the aforementioned security and privacy implications [Microsoft].

さらに、前述のセキュリティとプライバシーへの影響を軽減するために、一部の一般的なIPv6実装は、従来の安定したIID生成スキームからすでに逸脱しています[Microsoft]。

As a result of the aforementioned issues, this document changes the recommended default IID generation scheme for generating stable IPv6 addresses with SLAAC to that specified in [RFC7217] and recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers, such that the aforementioned issues are mitigated. That is, this document simply replaces the default algorithm that is recommended to be employed when generating stable IPv6 IIDs.

前述の問題の結果として、このドキュメントでは、SLAACを使用して安定したIPv6アドレスを生成するための推奨デフォルトIID生成スキームを[RFC7217]で指定されたものに変更し、前述の問題が発生するように、IPv6インターフェイス識別子に安定したリンク層アドレスを埋め込むことを推奨しません。軽減されます。つまり、このドキュメントは、安定したIPv6 IIDを生成するときに採用することが推奨されているデフォルトのアルゴリズムを単に置き換えたものです。

NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. Appendix A of [RFC4291] then describes how to transform an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an EUI-64 identifier is derived, into an IID in the Modified EUI-64 format.

注：[RFC4291]は、IIDの「Modified EUI-64 format」を定義しています。 [RFC4291]の付録Aでは、IEEE EUI-64識別子、またはEUI-64識別子の導出元であるIEEE 802 48ビットMACアドレスを、Modified EUI-64形式のIIDに変換する方法について説明しています。

In a variety of scenarios, addresses that remain stable for the lifetime of a host's connection to a single subnet are viewed as desirable. For example, stable addresses may be viewed as beneficial for network management, event logging, enforcement of access control, provision of quality of service, or for server or router interfaces. Similarly, stable addresses (as opposed to temporary addresses [RFC4941]) allow for long-lived TCP connections and are also usually desirable when performing server-like functions (i.e., receiving incoming connections).

さまざまなシナリオで、単一のサブネットへのホストの接続の存続期間中安定したままであるアドレスが望ましいと見なされます。たとえば、安定したアドレスは、ネットワーク管理、イベントロギング、アクセス制御の実施、サービス品質の提供、またはサーバーまたはルーターインターフェイスにとって有益であると見なされる場合があります。同様に、（一時アドレス[RFC4941]とは対照的に）安定したアドレスは、長期間のTCP接続を可能にし、サーバーのような機能（つまり、着信接続の受信）を実行するときにも通常は望ましいです。

The recommendations in this document apply only in cases where implementations otherwise would have configured a stable IPv6 IID containing a link-layer address. For example, this document does not change any existing recommendations concerning the use of temporary addresses as specified in [RFC4941] and the recommendations do not apply to cases where SLAAC is employed to generate non-stable IPv6 addresses (e.g., by embedding a link-layer address that is periodically randomized); in addition, this document does not introduce any new requirements regarding when stable addresses are to be configured. Thus, the recommendations in this document simply improve the security and privacy properties of stable addresses.

このドキュメントの推奨事項は、実装によってリンク層アドレスを含む安定したIPv6 IIDが構成されている場合にのみ適用されます。たとえば、このドキュメントは、[RFC4941]で指定されている一時アドレスの使用に関する既存の推奨事項を変更せず、推奨事項は、SLAACが不安定なIPv6アドレスの生成に使用されている場合（たとえば、リンクを埋め込むことによって）には適用されません。定期的にランダム化されるレイヤーアドレス）;さらに、このドキュメントでは、安定したアドレスを構成するタイミングに関する新しい要件は紹介されていません。したがって、このドキュメントの推奨事項は、安定したアドレスのセキュリティとプライバシーのプロパティを改善するだけです。

2. Terminology

2. 用語

Stable address: An address that does not vary over time within the same network (as defined in [RFC7721]).

安定したアドレス：同じネットワーク内で経時的に変化しないアドレス（[RFC7721]で定義）。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Generation of IPv6 Interface Identifiers with SLAAC

3. SLAACによるIPv6インターフェース識別子の生成

Nodes SHOULD implement and employ [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC. A link layer MAY also define a mechanism for stable IPv6 address generation that is more efficient and does not address the security and privacy considerations discussed in Section 1. The choice of whether or not to enable the security- and privacy-preserving mechanism SHOULD be configurable in such a case.

ノードは、SLAACで安定したIPv6アドレスを生成するためのデフォルトスキームとして[RFC7217]を実装して使用する必要があります（SHOULD）。リンク層は、より効率的で、セクション1で説明したセキュリティとプライバシーの考慮事項に対応しない、安定したIPv6アドレス生成のメカニズムも定義する場合があります（MAY）。セキュリティとプライバシーを維持するメカニズムを有効にするかどうかの選択は、構成可能である必要があります（SHOULD）このような場合には。

By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID. In particular, this document RECOMMENDS that nodes do not generate stable IIDs with the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391], [RFC5072], and [RFC5121].

デフォルトでは、ノードはIIDに安定したリンク層アドレスを埋め込むIPv6アドレス生成スキームを採用すべきではありません（SHOULD NOT）。特に、このドキュメントでは、[RFC2464]、[RFC2467]、[RFC2470]、[RFC2491]、[RFC2492]、[RFC2497]、[RFC2590]、[RFC3146]で指定されたスキームではノードが安定したIIDを生成しないことを推奨しています。 [RFC3572]、[RFC4338]、[RFC4391]、[RFC5072]、および[RFC5121]。

4. Future Work

4. 今後の仕事

At the time of this writing, the mechanisms specified in the following documents might require updates to be fully compatible with the recommendations in this document:

このドキュメントの執筆時点では、次のドキュメントで指定されているメカニズムでは、このドキュメントの推奨事項と完全に互換性のある更新が必要になる場合があります。

o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282]

o 「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」[RFC6282]

o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]

o 「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」[RFC4944]

o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]

o 「低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）を介したIPv6のネイバー探索最適化」[RFC6775]

o "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428]

o 「ITU-T G.9959ネットワークを介したIPv6パケットの送信」[RFC7428]

Future revisions or updates of these documents should consider the issues of privacy and security mentioned in Section 1 and explain any design and engineering considerations that lead to the use of stable IIDs based on a node's link-layer address.

これらのドキュメントの将来の改訂または更新では、セクション1で述べたプライバシーとセキュリティの問題を考慮し、ノードのリンク層アドレスに基づく安定したIIDの使用につながる設計およびエンジニアリングの考慮事項を説明する必要があります。

5. Security Considerations

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

This document recommends against the (default) use of predictable Interface Identifiers in IPv6 addresses. It recommends [RFC7217] as the default scheme for generating IPv6 stable addresses with SLAAC, such that the security and privacy issues of IIDs that embed stable link-layer addresses are mitigated.

このドキュメントでは、IPv6アドレスで予測可能なインターフェイス識別子を（デフォルトで）使用しないことを推奨しています。 SLAACでIPv6安定アドレスを生成するためのデフォルトスキームとして[RFC7217]を推奨し、安定したリンク層アドレスを埋め込むIIDのセキュリティとプライバシーの問題が軽減されるようにします。

6. References

6. 参考文献

6.1. Normative References

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。

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

[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<http://www.rfc-editor.org/info/rfc2464>。

[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, <http://www.rfc-editor.org/info/rfc2467>.

[RFC2467] Crawford、M。、「Transmission of IPv6 Packets over FDDI Networks」、RFC 2467、DOI 10.17487 / RFC2467、1998年12月、<http://www.rfc-editor.org/info/rfc2467>。

[RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, DOI 10.17487/RFC2470, December 1998, <http://www.rfc-editor.org/info/rfc2470>.

[RFC2470]クロフォード、M。、ナルテン、T。、およびS.トーマス、「トークンリングネットワークを介したIPv6パケットの送信」、RFC 2470、DOI 10.17487 / RFC2470、1998年12月、<http：//www.rfc-editor .org / info / rfc2470>。

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, DOI 10.17487/RFC2491, January 1999, <http://www.rfc-editor.org/info/rfc2491>.

[RFC2491] Armitage、G.、Schulter、P.、Jork、M。、およびG. Harter、「IPv6 over Non-Broadcast Multiple Access（NBMA）ネットワーク」、RFC 2491、DOI 10.17487 / RFC2491、1999年1月、<http ：//www.rfc-editor.org/info/rfc2491>。

[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, <http://www.rfc-editor.org/info/rfc2492>.

[RFC2492]アーミテージ、G。、シュルター、P。、およびM.ジョーク、「IPv6 over ATM Networks」、RFC 2492、DOI 10.17487 / RFC2492、1999年1月、<http://www.rfc-editor.org/info / rfc2492>。

[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, <http://www.rfc-editor.org/info/rfc2497>.

[RFC2497] Souvatzis、I.、 "Transmission of IPv6 Packets over ARCnet Networks"、RFC 2497、DOI 10.17487 / RFC2497、January 1999、<http://www.rfc-editor.org/info/rfc2497>

[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, DOI 10.17487/RFC2590, May 1999, <http://www.rfc-editor.org/info/rfc2590>.

[RFC2590] Conta、A.、Malis、A。、およびM. Mueller、「Transmission of IPv6 Packets over Frame Relay Networks Specification」、RFC 2590、DOI 10.17487 / RFC2590、1999年5月、<http：//www.rfc- editor.org/info/rfc2590>。

[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, October 2001, <http://www.rfc-editor.org/info/rfc3146>.

[RFC3146]藤沢健一、尾上明夫、「IEEE 1394ネットワークを介したIPv6パケットの送信」、RFC 3146、DOI 10.17487 / RFC3146、2001年10月、<http://www.rfc-editor.org/info/rfc3146 >。

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

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

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, January 2006, <http://www.rfc-editor.org/info/rfc4338>.

[RFC4338] DeSanti、C.、Carlson、C。、およびR. Nixon、「IPv6、IPv4、およびアドレス解決プロトコル（ARP）パケットのファイバーチャネル上での送信」、RFC 4338、DOI 10.17487 / RFC4338、2006年1月、< http://www.rfc-editor.org/info/rfc4338>。

[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 2006, <http://www.rfc-editor.org/info/rfc4391>.

[RFC4391] Chu、J。およびV. Kashyap、「Transmission of IP over InfiniBand（IPoIB）」、RFC 4391、DOI 10.17487 / RFC4391、2006年4月、<http://www.rfc-editor.org/info/rfc4391 >。

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

[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<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>.

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

[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, <http://www.rfc-editor.org/info/rfc5072>.

[RFC5072] Varada、S.、Ed。、Haskins、D.、and E. Allen、 "IP Version 6 over PPP"、RFC 5072、DOI 10.17487 / RFC5072、September 2007、<http：//www.rfc-editor .org / info / rfc5072>。

[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, DOI 10.17487/RFC5121, February 2008, <http://www.rfc-editor.org/info/rfc5121>.

[RFC5121] Patil、B.、Xia、F.、Sarikaya、B.、Choi、JH。、およびS. Madanapalli、「IEEE 802.16ネットワーク上のIPv6 Convergence Sublayerを介したIPv6の送信」、RFC 5121、DOI 10.17487 / RFC5121 、2008年2月、<http://www.rfc-editor.org/info/rfc5121>。

[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]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。

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

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

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

6.2. Informative References

6.2. 参考引用

[Microsoft] Davies, J., "Understanding IPv6, 3rd. ed", page 83, Microsoft Press, 2012, <http://it-ebooks.info/book/1022/>.

[Microsoft] Davies、J。、「Understanding IPv6、3rd。ed」、83ページ、Microsoft Press、2012、<http://it-ebooks.info/book/1022/>。

[NUM-IDS] Gont, F. and I. Arce, "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols", Work in Progress, February 2016.

[NUM-IDS] Gont、F。およびI. Arce、「ネットワークプロトコルで使用される数値識別子のセキュリティとプライバシーへの影響」、進行中の作業、2016年2月。

[RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July 2003, <http://www.rfc-editor.org/info/rfc3572>.

[RFC3572] Ogura、T.、Maruyama、M.、and T. Yoshida、 "Internet Protocol Version 6 over MAPOS（Multiple Access Protocol over SONET / SDH）"、RFC 3572、DOI 10.17487 / RFC3572、July 2003、<http： //www.rfc-editor.org/info/rfc3572>。

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

Acknowledgements

謝辞

The authors would like to thank (in alphabetical order) Bob Hinden, Ray Hunter, and Erik Nordmark, for providing a detailed review of this document.

著者は、このドキュメントの詳細なレビューを提供してくれたBob Hinden、Ray Hunter、およびErik Nordmarkに（アルファベット順で）感謝します。

The authors would like to thank (in alphabetical order) Fred Baker, Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing valuable comments on earlier draft versions of this document.

著者は（アルファベット順で）フレッド・ベイカー、カーステン・ボーマン、スコット・ブリム、ブライアン・カーペンター、サミタ・チャクラバルティ、ティム・チョウン、ロレンツォ・コリッティ、ジーン・ミシェル・コムズ、グレッグ・デイリー、エスコ・ダイク、ラルフ・ドロムス、デビッド・ファーマー、ブライアンに感謝しますハーバーマン、ウルリッヒヘルバーグ、フィリップホンバーグ、ジャハンギールホセイン、ジョナサンフイ、クリスチャンウイテマ、レイハンター、エリッククライン、シェンジャン、ロジャージョルゲンセン、ダンルエドケ、ケリーリン、ジョージミッチェル、ガブリエルモンテネグロ、エリックノードマーク、サイモンペロー、トムペッチ、このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくださったAlexandru Petrescu、Michael Richardson、Arturo Servin、Mark Smith、Tom Taylor、Ole Troan、Tina Tsou、Glen Turner、Randy Turner、Juan Carlos Zuniga。

Authors' Addresses

著者のアドレス

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

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

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

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

アリッサクーパーシスコ707タスマンドライブミルピタス、カリフォルニア州95035アメリカ合衆国

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

Dave Thaler Microsoft Microsoft Corporation One Microsoft Way Redmond, WA 98052

だゔぇてゃぇｒみｃろそｆｔみｃろそｆｔこｒぽらちおんおねみｃろそｆｔわｙれｄもんｄ、わ９８０５２

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

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

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

   Email: liushucheng@huawei.com