[要約] RFC 7421は、IPv6アドレッシングにおける64ビット境界の分析に関するものであり、IPv6アドレスの64ビット境界の利点と課題を調査しています。このRFCの目的は、IPv6ネットワークの設計と運用における64ビット境界の影響を理解し、最適なアドレス割り当て戦略を提案することです。
Internet Engineering Task Force (IETF) B. Carpenter, Ed.
Request for Comments: 7421 Univ. of Auckland
Category: Informational T. Chown
ISSN: 2070-1721 Univ. of Southampton
F. Gont
SI6 Networks / UTN-FRH
S. Jiang
Huawei Technologies Co., Ltd
A. Petrescu
CEA, LIST
A. Yourtchenko
Cisco
January 2015
Analysis of the 64-bit Boundary in IPv6 Addressing
IPv6アドレッシングにおける64ビット境界の分析
Abstract
概要
The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.
IPv6ユニキャストアドレッシング形式には、パケットをサブネットにルーティングするために使用されるプレフィックスと、そのサブネットに接続された特定のインターフェースを指定するために使用されるインターフェース識別子との間の分離が含まれます。現在、インターフェイス識別子は、ほとんどすべての場合で64ビット長として定義されており、サブネットプレフィックスには64ビットが残されています。このドキュメントでは、この固定境界の利点を説明し、それを可変境界として扱うことに関連する問題を分析します。
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/rfc7421.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7421で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Advantages of a Fixed Identifier Length . . . . . . . . . . . 4
3. Arguments for Shorter Identifier Lengths . . . . . . . . . . 5
3.1. Insufficient Address Space Delegated . . . . . . . . . . 5
3.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 6
3.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 7
3.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 7
4. Effects of Varying the Interface Identifier Length . . . . . 8
4.1. Interaction with IPv6 Specifications . . . . . . . . . . 8
4.2. Possible Failure Modes . . . . . . . . . . . . . . . . . 10
4.3. Experimental Observations . . . . . . . . . . . . . . . . 12
4.3.1. Survey of the processing of Neighbor Discovery
Options with Prefixes Other than /64 . . . . . . . . 12
4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14
4.4. Implementation and Deployment Issues . . . . . . . . . . 14
4.5. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Rather than simply overcoming the IPv4 address shortage by doubling the address size to 64 bits, IPv6 addresses were originally chosen to be 128 bits long to provide flexibility and new possibilities. In particular, the notion of a well-defined interface identifier was added to the IP addressing model. The IPv6 addressing architecture [RFC4291] specifies that a unicast address is divided into n bits of subnet prefix followed by (128-n) bits of interface identifier (IID). The bits in the IID may have significance only in the process of deriving the IID; once it is derived, the entire identifier should be treated as an opaque value [RFC7136]. Also, since IPv6 routing is entirely based on variable length prefixes (also known as variable length subnet masks), there is no basic architectural assumption that n has any particular fixed value. All IPv6 routing protocols support prefixes of any length up to /128.
アドレスサイズを2倍の64ビットにしてIPv4アドレス不足を克服するのではなく、IPv6アドレスは当初、柔軟性と新しい可能性を提供するために128ビット長になるように選択されました。特に、明確に定義されたインターフェイス識別子の概念がIPアドレッシングモデルに追加されました。 IPv6アドレッシングアーキテクチャ[RFC4291]は、ユニキャストアドレスがnビットのサブネットプレフィックスに分割され、その後に（128-n）ビットのインターフェイス識別子（IID）が続くことを指定しています。 IIDのビットは、IIDを導出するプロセスでのみ意味を持つ場合があります。それが導出されたら、識別子全体を不透明な値として扱う必要があります[RFC7136]。また、IPv6ルーティングは完全に可変長プレフィックス（可変長サブネットマスクとも呼ばれます）に基づいているため、nに特定の固定値があるという基本的なアーキテクチャ上の仮定はありません。すべてのIPv6ルーティングプロトコルは、/ 128までの任意の長さのプレフィックスをサポートします。
The IID is of basic importance in the IPv6 stateless address autoconfiguration (SLAAC) process [RFC4862]. However, it is important to understand that its length is a parameter in the SLAAC process, and it is determined in a separate link-type specific document (see the definition of "interface identifier" in Section 2 of RFC 4862). The SLAAC protocol does not define its length or assume any particular length. Similarly, DHCPv6 [RFC3315] does not include a prefix length in its address assignment.
IIDは、IPv6ステートレスアドレス自動構成（SLAAC）プロセス[RFC4862]で基本的に重要です。ただし、その長さはSLAACプロセスのパラメータであり、別のリンクタイプ固有のドキュメントで決定されることを理解することが重要です（RFC 4862のセクション2の「インターフェース識別子」の定義を参照）。 SLAACプロトコルはその長さを定義せず、特定の長さを想定していません。同様に、DHCPv6 [RFC3315]では、アドレス割り当てにプレフィックス長が含まれていません。
The notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80. There were two motivations for setting it at /64. One was the original "8+8" proposal [ODELL] that eventually led to the Identifier-Locator Network Protocol (ILNP) [RFC6741], which required a fixed point for the split between local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would become widespread in place of 48-bit addresses, coupled with the plan at that time that auto-configured addresses would normally be based on interface identifiers derived from MAC addresses.
アドレスの/ 64境界の概念は、IPv6の初期設計の後に導入され、/ 80であると予想されていた期間に続きました。 / 64に設定する動機は2つありました。 1つは、元の「8 + 8」提案[ODELL]であり、最終的にIdentifier-Locator Network Protocol（ILNP）[RFC6741]に至りました。これは、アドレスのローカル部分と広域部分の間の分割に固定小数点を必要としました。もう1つは、64ビットの拡張一意識別子（EUI-64）メディアアクセス制御（MAC）アドレスが48ビットアドレスの代わりに広く普及し、当時の自動構成アドレスが通常予定されていた計画と相まって、 MACアドレスから導出されたインターフェイス識別子に基づいています。
As a result, RFC 4291 describes a method of forming interface identifiers from IEEE EUI-64 hardware addresses [IEEE802], and this specifies that such interface identifiers are 64 bits long. Various other methods of forming interface identifiers also specify a length of 64 bits. The addressing architecture, as modified by [RFC7136], states that:
その結果、RFC 4291は、IEEE EUI-64ハードウェアアドレス[IEEE802]からインターフェイス識別子を形成する方法を記述しており、これにより、そのようなインターフェイス識別子は64ビット長であると規定されています。インターフェイス識別子を形成する他のさまざまな方法でも、64ビットの長さが指定されています。 [RFC7136]によって変更されたアドレス指定アーキテクチャは、次のように述べています。
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.
バイナリ値000で始まるアドレスを除くすべてのユニキャストアドレスでは、インターフェイスIDは64ビット長である必要があります。 IEEE MAC層アドレスから派生した場合、それらはModified EUI-64形式で構築する必要があります。
The de facto length of almost all IPv6 interface identifiers is therefore 64 bits. The only documented exception is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem.
したがって、ほとんどすべてのIPv6インターフェース識別子の事実上の長さは64ビットです。唯一文書化された例外は[RFC6164]にあり、これは特に、ピンポン問題として知られるループ状態を回避するために、ルーター間のポイントツーポイントリンクの127ビットプレフィックスを標準化します。
With that exception, and despite the comments above about the routing architecture and the design of SLAAC, using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary.
その例外を除き、ルーティングアーキテクチャとSLAACの設計に関する上記のコメントにもかかわらず、64ビットより短いIIDと64ビットより長いサブネットプレフィックスを使用すると、現在のIPv6仕様の範囲外になるため、結果が異なる場合があります。
The question is often asked why the subnet prefix boundary is set rigidly at /64. The first purpose of this document is to explain the advantages of the fixed IID length. Its second purpose is to analyze, in some detail, the effects of hypothetically varying the IID length. The fixed-length limits the practical length of a routing prefix to 64 bits, whereas architecturally, and from the point of view of routing protocols, it could be any value up to /128, as in the case of host routes. Whatever the length of the IID, the longest match is done on the concatenation of prefix and IID. Here, we mainly discuss the question of a shorter IID, which would allow a longer subnet prefix. The document makes no proposal for a change to the IID length.
サブネットプレフィックスの境界が厳密に/ 64に設定されている理由をよく尋ねられます。このドキュメントの最初の目的は、固定IIDの長さの利点を説明することです。その2つ目の目的は、IIDの長さを仮想的に変化させた場合の影響を詳細に分析することです。固定長はルーティングプレフィックスの実際の長さを64ビットに制限しますが、アーキテクチャ上、ルーティングプロトコルの観点からは、ホストルートの場合のように、/ 128までの任意の値にすることができます。 IIDの長さがどうであれ、最長一致は、プレフィックスとIIDの連結で行われます。ここでは主に、より短いサブネットプレフィックスを許可する短いIIDの問題について説明します。このドキュメントでは、IIDの長さを変更する提案はありません。
The following three sections describe, in turn, the advantages of the fixed-length IID, some arguments for shorter lengths, and the expected effects of varying the length.
次の3つのセクションでは、固定長IIDの利点、短い長さに対するいくつかの引数、および長さを変化させた場合の予想される影響について説明します。
As mentioned in Section 1, the existence of an IID of a given length is a necessary part of IPv6 stateless address autoconfiguration (SLAAC) [RFC4862]. This length is normally the same for all nodes on a given link that is running SLAAC. Even though this length is a parameter for SLAAC, determined separately for the link-layer media type of each interface, a globally fixed IID length for all link-layer media is the simplest solution and is consistent with the principles of Internet host configuration described in [RFC5505].
セクション1で述べたように、所定の長さのIIDの存在は、IPv6ステートレスアドレス自動構成（SLAAC）[RFC4862]の必要な部分です。この長さは通常、SLAACを実行している特定のリンク上のすべてのノードで同じです。この長さはSLAACのパラメーターであり、各インターフェイスのリンク層メディアタイプに対して個別に決定されますが、すべてのリンク層メディアのグローバルに固定されたIID長さは最も簡単なソリューションであり、で説明されているインターネットホスト構成の原則と一致しています。 [RFC5505]。
An interface identifier of significant length, clearly separated from the subnet prefix, makes it possible to limit the traceability of a host computer by varying the identifier. This is discussed further in Section 4.5.
有意な長さのインターフェース識別子は、サブネットプレフィックスから明確に分離されており、識別子を変えることでホストコンピューターのトレーサビリティを制限することができます。これについては、セクション4.5で詳しく説明します。
An interface identifier of significant length guarantees that there are always enough addresses in any subnet to add one or more real or virtual interfaces. There might be other limits, but IP addressing will never get in the way.
重要な長さのインターフェース識別子は、1つ以上の実際のインターフェースまたは仮想インターフェースを追加するのに十分なアドレスがサブネットに常にあることを保証します。他の制限があるかもしれませんが、IPアドレッシングは決して邪魔になりません。
The addressing architecture [RFC4291] [RFC7136] sets the IID length at 64 bits for all unicast addresses and therefore for all media supporting SLAAC. An immediate effect of fixing the IID length at 64 bits is, of course, that it fixes the subnet prefix length also at 64 bits, regardless of the aggregate prefix assigned to the site concerned, which in accordance with [RFC6177] should be /56 or shorter. This situation has various specific advantages:
アドレッシングアーキテクチャ[RFC4291] [RFC7136]は、すべてのユニキャストアドレス、つまりSLAACをサポートするすべてのメディアのIIDの長さを64ビットに設定します。もちろん、IIDの長さを64ビットに固定すると、関連するサイトに割り当てられた集約プレフィックスに関係なく、サブネットプレフィックスの長さも64ビットに固定されます。これは、[RFC6177]に従って/ 56にする必要があります。以下。この状況には、さまざまな特定の利点があります。
o Everything is the same. Compared to IPv4, there is no more calculating leaf subnet sizes, no more juggling between subnets, and fewer consequent errors. Network design is therefore simpler and much more straightforward. This is of importance for all types of networks -- enterprise, campus, small office, or home networks -- and for all types of operator, from professional to consumer.
o すべてが同じです。 IPv4と比較して、リーフサブネットのサイズの計算、サブネット間のジャグリング、および結果として生じるエラーが少なくなります。したがって、ネットワーク設計はより単純ではるかに簡単です。これは、エンタープライズ、キャンパス、小規模オフィス、またはホームネットワークなどのすべてのタイプのネットワーク、およびプロからコンシューマーまで、すべてのタイプのオペレーターにとって重要です。
o Adding a subnet is easy -- just take another /64 from the pool. No estimates, calculations, consideration, or judgement is needed.
o サブネットの追加は簡単です。プールから別の/ 64を取得するだけです。見積もり、計算、考慮、判断は必要ありません。
o Router configurations are homogeneous and easier to understand.
o ルーター構成は同種であり、理解しやすくなっています。
o Documentation is easier to write and easier to read; training is easier.
o ドキュメントは書きやすく、読みやすくなっています。トレーニングは簡単です。
The remainder of this document describes arguments that have been made against the current fixed IID length and analyzes the effects of a possible change. However, the consensus of the IETF is that the benefits of keeping the length fixed at 64 bits and the practical difficulties of changing it outweigh the arguments for change.
このドキュメントの残りの部分では、現在の固定IID長に対して行われた議論について説明し、可能な変更の影響を分析します。ただし、IETFのコンセンサスは、長さを64ビットに固定することの利点と、長さを変更することの実際的な難しさは、変更の議論よりも重要だということです。
In this section, we describe arguments for scenarios where shorter IIDs, implying prefixes longer than /64, have been used or proposed.
このセクションでは、短いIID、つまり/ 64より長いプレフィックスを意味するシナリオが使用または提案された場合の引数について説明します。
A site may not be delegated a sufficiently generous prefix from which to allocate a /64 prefix to all of its internal subnets. In this case, the site may either determine that it does not have enough address space to number all its network elements and thus, at the very best, be only partially operational, or it may choose to use internal prefixes longer than /64 to allow multiple subnets and the hosts within them to be configured with addresses.
サイトには、/ 64プレフィックスをすべての内部サブネットに割り当てるための十分なプレフィックスが委任されていない場合があります。この場合、サイトは、すべてのネットワーク要素に番号を付けるのに十分なアドレススペースがないため、最高の状態で部分的にしか機能しないと判断するか、/ 64よりも長い内部プレフィックスを使用して、複数のサブネットとその内部のホストをアドレスで構成します。
In this case, the site might choose, for example, to use a /80 per subnet in combination with hosts using either manually configured addressing or DHCPv6 [RFC3315].
この場合、サイトは、たとえば、手動で構成されたアドレス指定またはDHCPv6 [RFC3315]を使用するホストと組み合わせて、サブネットごとに/ 80を使用することを選択できます。
Scenarios that have been suggested where an insufficient prefix might be delegated include home or small office networks, vehicles, building services, and transportation services (e.g., road signs). It should be noted that the homenet architecture text [RFC7368] states that Customer Premises Equipment (CPE) should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally.
不十分なプレフィックスが委任される可能性がある場合に提案されているシナリオには、ホームネットワークまたは小規模オフィスネットワーク、車両、建築サービス、および輸送サービス（道路標識など）が含まれます。ホームネットアーキテクチャのテキスト[RFC7368]では、Customer Premises Equipment（CPE）は、/ 64よりも長いプレフィックスを内部で使用するのではなく、十分なアドレススペースがないことをエラー状態と見なす必要があると述べています。
Another scenario occasionally suggested is one where the Internet address registries actually begin to run out of IPv6 prefix space, such that operators can no longer assign reasonable prefixes to users in accordance with [RFC6177]. It is sometimes suggested that assigning a prefix such as /48 or /56 to every user site (including the smallest) as recommended by [RFC6177] is wasteful. In fact, the currently released unicast address space, 2000::/3, contains 35 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a small fraction have been allocated. Allowing for a conservative estimate of allocation efficiency, i.e., an HD-ratio of 0.94 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 prefixes can be allocated. Furthermore, with only 2000::/3 currently committed for unicast addressing, we still have approximately 85% of the address space in reserve. Thus, there is no objective risk of prefix depletion by assigning /48 or /56 prefixes even to the smallest sites.
時々提案される別のシナリオは、インターネットアドレスレジストリが実際にIPv6プレフィックススペースを使い果たし始めるため、[RFC6177]に従ってオペレーターがユーザーに適切なプレフィックスを割り当てられなくなるシナリオです。 [RFC6177]で推奨されているように、すべてのユーザーサイト（最小のものを含む）に/ 48や/ 56などの接頭辞を割り当てるのは無駄です。実際、現在リリースされているユニキャストアドレススペース2000 :: / 3には、35兆/ 48のプレフィックス（（2 ** 45 = 35,184,372,088,832）が含まれ、そのうちの一部のみが割り当てられています。割り当て効率の控えめな見積もりが可能つまり、0.94 [RFC4692]のHD比率では、約5兆/ 48のプレフィックスを割り当てることができます。0.89の緩和されたHD比率でも、約1兆/ 48のプレフィックスを割り当てることができます。さらに、2000のみ:: / 3は現在ユニキャストアドレッシング用にコミットされていますが、アドレススペースの約85％が予約されているため、最小のサイトにも/ 48または/ 56プレフィックスを割り当てることによるプレフィックス枯渇の客観的なリスクはありません。
Some operators have argued that more prefix bits are needed to allow an aggregated hierarchical addressing scheme within a campus or corporate network. However, if a campus or enterprise gets a /48 prefix (or shorter), then that already provides 16 bits for hierarchical allocation. In any case, flat IGP routing is widely and successfully used within rather large networks, with hundreds of routers and thousands of end systems. Therefore, there is no objective need for additional prefix bits to support hierarchy and aggregation within enterprises.
一部の事業者は、キャンパスまたは企業ネットワーク内で集約された階層型アドレッシングスキームを可能にするために、より多くのプレフィックスビットが必要であると主張しています。ただし、キャンパスまたは企業が/ 48（またはそれより短い）プレフィックスを取得する場合、階層割り当てにはすでに16ビットが提供されています。いずれにせよ、フラットIGPルーティングは、数百のルーターと数千のエンドシステムを備えた、かなり大規模なネットワーク内で広く成功裏に使用されています。したがって、企業内での階層と集約をサポートするための追加のプレフィックスビットの客観的な必要はありません。
Some network operators wish to know and audit nodes that are active on a network, especially those that are allowed to communicate off-link or off-site. They may also wish to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN, or site, in order to prevent potential resource-depletion attacks or other problems spreading beyond a certain scope of control. It has been argued that this type of control would be easier if only long network prefixes with relatively small numbers of possible hosts per network were used, reducing the discovery problem. However, such sites most typically operate using DHCPv6, which means that all legitimate hosts are automatically known to the DHCPv6 servers, which is sufficient for audit purposes. Such hosts could, if desired, be limited to a small range of IID values without changing the /64 subnet length. Any hosts inadvertently obtaining addresses via SLAAC can be audited through Neighbor Discovery (ND) logs.
一部のネットワークオペレーターは、ネットワーク上でアクティブなノード、特にオフリンクまたはオフサイトでの通信が許可されているノードを知り、監査したいと考えています。潜在的なリソース枯渇攻撃や特定の制御範囲を超えて広がるその他の問題を防ぐために、特定のホスト、LAN、またはサイトから送信できるアクティブなアドレスとセッションの総数を制限することもできます。このタイプの制御は、ネットワークごとに可能なホストの数が比較的少ない長いネットワークプレフィックスのみを使用すると、発見の問題が軽減されるため、より簡単になると主張されてきました。ただし、そのようなサイトは最も一般的にDHCPv6を使用して動作します。つまり、すべての正当なホストがDHCPv6サーバーに自動的に認識され、監査目的には十分です。このようなホストは、必要に応じて、/ 64サブネット長を変更せずに、小さいIID値の範囲に制限できます。 SLAACを介して誤ってアドレスを取得したホストは、近隣探索（ND）ログを介して監査できます。
A site may be concerned that it is open to ND cache exhaustion attacks [RFC3756], whereby an attacker sends a large number of messages in rapid succession to a series of (most likely inactive) host addresses within a specific subnet. Such an attack attempts to fill a router's ND cache with ND requests pending completion, which results in denying correct operation to active devices on the network.
サイトは、NDキャッシュ枯渇攻撃[RFC3756]にさらされていることを懸念している可能性があります。これにより、攻撃者は特定のサブネット内の一連の（ほとんどの場合は非アクティブな）ホストアドレスに大量のメッセージを連続して送信します。このような攻撃は、ルーターのNDキャッシュをND要求で満たそうとし、完了まで保留します。その結果、ネットワーク上のアクティブなデバイスに対する正しい操作が拒否されます。
One potential way to mitigate this attack would be to consider using a /120 prefix, thus limiting the number of addresses in the subnet to be similar to an IPv4 /24 prefix, which should not cause any concerns for ND cache exhaustion. Note that the prefix does need to be quite long for this scenario to be valid. The number of theoretically possible ND cache slots on the segment needs to be of the same order of magnitude as the actual number of hosts. Thus, small increases from the /64 prefix length do not have a noticeable impact; even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers. Given that most link-layer mappings cause SLAAC to assume a 64-bit network boundary, in such an approach hosts would likely need to use DHCPv6 or be manually configured with addresses.
この攻撃を軽減するための1つの潜在的な方法は、/ 120プレフィックスの使用を検討することです。これにより、サブネット内のアドレス数をIPv4 / 24プレフィックスと同様に制限します。これにより、NDキャッシュが枯渇する心配はありません。このシナリオを有効にするには、プレフィックスをかなり長くする必要があることに注意してください。セグメント上の理論的に可能なNDキャッシュスロットの数は、ホストの実際の数と同じ桁数である必要があります。したがって、/ 64プレフィックス長から少し増加しても、顕著な影響はありません。 2 ^ 32の潜在的なエントリでさえ、2 ^ 64と比較して20億分の1の減少ですが、現在のルーターのメモリを使い果たすには十分です。ほとんどのリンク層マッピングにより、SLAACは64ビットのネットワーク境界を想定するため、このようなアプローチでは、ホストはDHCPv6を使用するか、手動でアドレスを設定する必要があります。
It should be noted that several other mitigations of the ND cache attack are described in [RFC6583], and that limiting the size of the cache and the number of incomplete entries allowed would also defeat the attack. For the specific case of a point-to-point link between routers, this attack is indeed mitigated by a /127 prefix [RFC6164].
NDキャッシュ攻撃の他のいくつかの緩和策が[RFC6583]で説明されており、キャッシュのサイズと許可される不完全なエントリの数を制限することも攻撃を無効にすることに注意すべきです。ルーター間のポイントツーポイントリンクの特定のケースでは、この攻撃は/ 127プレフィックス[RFC6164]によって実際に軽減されます。
This section of the document analyzes the impact and effects of varying the length of an IPv6 unicast IID by reducing it to less than 64 bits.
ドキュメントのこのセクションでは、IPv6ユニキャストIIDの長さを64ビット未満に削減することにより、さまざまな長さの影響と影響を分析します。
The precise 64-bit length of the IID is widely mentioned in numerous RFCs describing various aspects of IPv6. It is not straightforward to distinguish cases where this has normative impact or affects interoperability. This section aims to identify specifications that contain an explicit reference to the 64-bit length. Regardless of implementation issues, the RFCs themselves would all need to be updated if the 64-bit rule was changed, even if the updates were small, which would involve considerable time and effort.
IIDの正確な64ビット長は、IPv6のさまざまな側面を説明する多くのRFCで広く言及されています。これが標準的な影響を及ぼしたり、相互運用性に影響を及ぼしたりするケースを区別することは簡単ではありません。このセクションは、64ビット長への明示的な参照を含む仕様を識別することを目的としています。実装の問題に関係なく、64ビットのルールが変更された場合、たとえ更新が小さくても、かなりの時間と労力を必要とするRFC自体をすべて更新する必要があります。
First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer, and repeat this apparently immutable value: Addressing Architecture [RFC4291], IPv6 Address Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge routers impose /64 for their interfaces [RFC7084]. The IPv6 Subnet Model [RFC5942] points out that the assumption of a /64 prefix length is a potential implementation error.
何よりもまず、IPv6アドレッシングのアーキテクチャーの側面を説明するRFCは、この明らかに不変の値を明示的に示し、参照し、繰り返しています。識別子[RFC6741]。カスタマーエッジルーターは、インターフェイスに/ 64を課しています[RFC7084]。 IPv6サブネットモデル[RFC5942]は、/ 64プレフィックス長の仮定が潜在的な実装エラーであることを指摘しています。
Numerous IPv6-over-foo documents make mandatory statements with
respect to the 64-bit length of the IID to be used during the
Stateless Autoconfiguration. These documents include [RFC2464]
(Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)),
[RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet),
[RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre
Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121]
[RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS]
(Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE]
(BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and
[IPv6-G9959] (IPv6 packets over ITU-T G.9959).
To a lesser extent, the address configuration RFCs themselves may in some ways assume the 64-bit length of an IID (e.g, RFC 4862 for the link-local addresses, DHCPv6 for the potentially assigned EUI-64-based IP addresses, and Optimistic Duplicate Address Detection [RFC4429] that computes 64-bit-based collision probabilities).
それほどではありませんが、アドレス構成RFC自体が何らかの方法でIIDの64ビット長を想定する場合があります（たとえば、リンクローカルアドレスの場合はRFC 4862、割り当てられている可能性のあるEUI-64ベースのIPアドレスの場合はDHCPv6、および楽観的64ビットベースの衝突確率を計算する重複アドレス検出[RFC4429]）。
The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries be sent with a link-local source address, with the exception of MLD messages sent using the unspecified address when the link-local address is tentative [RFC3590]. At the time of publication of RFC 2710, the IPv6 addressing architecture specified link-local addresses with 64-bit interface identifiers. MLDv2 explicitly specifies the use of the fe80::/64 link-local prefix and bases the querier election algorithm on the link-local subnet prefix of length /64.
Multicast Listener Discovery Version 1（MLDv1）[RFC2710]およびMLDv2 [RFC3810]プロトコルでは、リンクローカルアドレスが指定されている場合に未指定アドレスを使用して送信されるMLDメッセージを除いて、すべてのクエリをリンクローカルソースアドレスで送信することが義務付けられています。暫定[RFC3590]。 RFC 2710の公開時に、IPv6アドレッシングアーキテクチャは、64ビットのインターフェイス識別子を使用してリンクローカルアドレスを指定しました。 MLDv2は、fe80 :: / 64リンクローカルプレフィックスの使用を明示的に指定し、長さ/ 64のリンクローカルサブネットプレフィックスをクエリア選択アルゴリズムに基づいています。
The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 20-bit hash function generation, which relies on splitting an IPv6 address in two equally sized, 64-bit-length parts.
「IPv6 Flow Label Specification」[RFC6437]は、20ビットのハッシュ関数生成の例を示しています。これは、IPv6アドレスを2つの同じサイズの64ビット長の部分に分割することに依存しています。
The basic transition mechanisms [RFC4213] refer to IIDs of length 64 for link-local addresses; other transition mechanisms such as Teredo [RFC4380] assume the use of IIDs of length 64. Similar assumptions are found in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency on prefix length, discussed below.
基本的な移行メカニズム[RFC4213]は、リンクローカルアドレスについて長さ64のIIDを参照します。 Teredo [RFC4380]などの他の移行メカニズムでは、長さが64のIIDの使用を想定しています。6to4[RFC3056]と6rd [RFC5969]でも同様の想定があります。 NAT64やNPTv6などの変換ベースの移行メカニズムは、以下で説明するように、プレフィックス長にある程度依存しています。
The proposed method [RFC7278] of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on prefix length, and implicitly on the length of the IID, to be valued at 64.
割り当てられた/ 64プレフィックスをスマートフォンのセルラーインターフェイスからWiFiリンクに拡張する提案された方法[RFC7278]は、プレフィックスの長さに依存し、暗黙的にIIDの長さに依存して、64で評価されます。
The Cryptographically Generated Addresses (CGA) and Hash-Based Addresses (HBA) specifications rely on the 64-bit identifier length (see below), as do the Privacy extensions [RFC4941] and some examples in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296].
暗号化生成アドレス（CGA）とハッシュベースアドレス（HBA）の仕様は、プライバシー拡張[RFC4941]および「インターネットキーエクスチェンジバージョン2（IKEv2）の例と同様に、64ビットの識別子の長さ（下記参照）に依存しています。 「[RFC7296]。
464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. However, it also discusses the possibility of using the interface address on the device as the end point for the traffic, thus potentially removing this dependency.
464XLAT [RFC6877]は、/ 64プレフィックスの取得について明示的に言及しています。ただし、デバイスのインターフェイスアドレスをトラフィックのエンドポイントとして使用する可能性についても説明しているため、この依存関係が削除される可能性があります。
[RFC2526] reserves a number of subnet anycast addresses by reserving some anycast IIDs. An anycast IID so reserved cannot be less than 7 bits long. This means that a subnet prefix length longer than /121 is not possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. This could of course be fixed in the way described for /127 in [RFC6164], i.e., avoiding the use of anycast within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability [RFC4861] [RFC7094]; therefore, applications and their developers would expect it to be available.
[RFC2526]は、いくつかのエニーキャストIIDを予約することにより、いくつかのサブネットエニーキャストアドレスを予約します。このように予約されたエニーキャストIIDは、7ビット未満にはできません。これは、/ 121より長いサブネットプレフィックス長は不可能であり、すべての識別子が予約されているため、正確に/ 121のサブネットは役に立たないことを意味します。また、/ 120の半分はエニーキャスト用に予約されています。これはもちろん、[RFC6164]の/ 127で説明されている方法で修正できます。つまり、/ 120サブネット内でのエニーキャストの使用を回避できます。 「オンリンクエニーキャスト」のサポートは標準のIPv6ネイバー探索機能であることに注意してください[RFC4861] [RFC7094]。したがって、アプリケーションとその開発者は、それが利用可能になることを期待します。
The Mobile IP home network models [RFC4887] rely heavily on the /64 subnet length and assume a 64-bit IID.
モバイルIPホームネットワークモデル[RFC4887]は、/ 64サブネット長に大きく依存し、64ビットIIDを想定しています。
While preparing this document, it was noted that many other IPv6 specifications refer to mandatory alignment on 64-bit boundaries, 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence numbers and cookies in security, etc. Finally, the number "64" may be considered "magic" in some RFCs, e.g., 64k limits in DNS and Base64 encodings in MIME. None of this has any influence on the length of the IID but might confuse a careless reader.
このドキュメントの準備中に、他の多くのIPv6仕様が64ビット境界、64ビットデータ構造、MIBの64ビットカウンター、64ビットシーケンス番号、セキュリティのCookieなどでの必須の配置に言及していることが指摘されました。たとえば、DNSの64k制限やMIMEのBase64エンコーディングなど、一部のRFCでは「64」という数値は「マジック」と見なされる場合があります。これはIIDの長さに影響を与えませんが、不注意な読者を混乱させる可能性があります。
This section discusses several specific aspects of IPv6 where we can expect operational failures with subnet prefixes other than /64.
このセクションでは、/ 64以外のサブネットプレフィックスで動作障害が予想されるIPv6のいくつかの特定の側面について説明します。
o Router implementations: Router implementors might interpret IETF specifications such as [RFC6164] and [RFC7136] as indicating that prefixes between /65 and /126 (inclusive) for unicast packets on-the-wire are invalid and that operational practices that utilize prefix lengths in this range may fail on some devices, as discussed in Section 4.3.2.
o ルーターの実装：ルーターの実装者は、[RFC6164]や[RFC7136]などのIETF仕様を、ネットワーク上のユニキャストパケットの/ 65から/ 126（両端を含む）までのプレフィックスが無効であり、プレフィックス長を利用する運用慣行を示すと解釈する場合がありますセクション4.3.2で説明するように、この範囲は一部のデバイスで失敗する可能性があります。
o Multicast: [RFC3306] defines a method for generating IPv6 multicast group addresses based on unicast prefixes. This method assumes a longest prefix of 64 bits. If a longer prefix is used, there is no way to generate a specific multicast group address using this method. In such cases, the administrator would need to use an "artificial" prefix from within their allocation (a /64 or shorter) from which to generate the group address. This prefix would not correspond to a real subnet.
o マルチキャスト：[RFC3306]は、ユニキャストプレフィックスに基づいてIPv6マルチキャストグループアドレスを生成する方法を定義します。このメソッドは、最長の64ビットのプレフィックスを想定しています。より長いプレフィックスが使用されている場合、この方法を使用して特定のマルチキャストグループアドレスを生成する方法はありません。このような場合、管理者はグループアドレスを生成するための割り当て（/ 64以下）内から「人工的な」プレフィックスを使用する必要があります。このプレフィックスは実際のサブネットに対応していません。
Similarly, [RFC3956], which specifies the Embedded Rendezvous Point (RP)) allowing IPv6 multicast rendezvous point addresses to be embedded in the multicast group address, would also fail, as the scheme assumes a maximum prefix length of 64 bits.
同様に、IPv6マルチキャストランデブーポイントアドレスをマルチキャストグループアドレスに埋め込むことを許可するEmbedded Rendezvous Point（RP）を指定する[RFC3956]も失敗します。これは、スキームが最大プレフィックス長を64ビットと想定しているためです。
o CGA: The Cryptographically Generated Address format [RFC3972] is heavily based on a /64 interface identifier. [RFC3972] has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. Changing the /64 boundary would certainly invalidate the current CGA definition. However, the CGA might benefit in a redefined version if more bits are used for interface identifiers (which means shorter prefix length). For now, 59 bits are used for cryptographic purposes. The more bits are available, the stronger CGA could be. Conversely, longer prefixes would weaken CGA.
o CGA：暗号で生成されたアドレス形式[RFC3972]は、/ 64インターフェイス識別子に大きく基づいています。 [RFC3972]は、公開鍵と64ビットのサブネットプレフィックスから64ビットのインターフェース識別子を生成する方法を示す詳細なアルゴリズムを定義しています。 / 64境界を変更すると、確かに現在のCGA定義が無効になります。ただし、より多くのビットがインターフェース識別子に使用されている場合（つまり、プレフィックス長が短い場合）、CGAは再定義されたバージョンでメリットがある可能性があります。現時点では、暗号化の目的で59ビットが使用されています。利用可能なビットが多ければ多いほど、より強力なCGAになる可能性があります。逆に、プレフィックスが長いと、CGAが弱くなります。
o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] are flexible for the prefix length. [RFC6052] has defined multiple address formats for NAT64. In Section 2 of
o NAT64：ステートレスNAT64 [RFC6052]とステートフルNAT64 [RFC6146]はどちらも、プレフィックス長に柔軟性があります。 [RFC6052]はNAT64に複数のアドレス形式を定義しています。のセクション2
"IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the network-specific prefix could be one of /32, /40, /48, /56, /64, and /96. The remaining part of the IPv6 address is constructed by a 32-bit IPv4 address, an 8-bit u byte and a variable length suffix (there is no u byte and suffix in the case of the 96-bit Well-Known Prefix). NAT64 is therefore OK with a subnet boundary out to /96 but not longer.
「IPv4-Embedded IPv6 Address Prefix and Format」[RFC6052]、ネットワーク固有のプレフィックスは、/ 32、/ 40、/ 48、/ 56、/ 64、/ 96のいずれかになります。 IPv6アドレスの残りの部分は、32ビットのIPv4アドレス、8ビットのuバイト、および可変長のサフィックスで構成されます（96ビットのWell-Knownプレフィックスの場合、uバイトとサフィックスはありません）。したがって、NAT64は/ 96までのサブネット境界で問題はありませんが、長くはありません。
o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 prefix. When the NPTv6 Translator is configured with a /48 or shorter prefix, the 64-bit interface identifier is kept unmodified during translation. However, the /64 boundary might be changed as long as the "inside" and "outside" prefixes have the same length.
o NPTv6：IPv6-to-IPv6ネットワークプレフィックス変換[RFC6296]も/ 64境界にバインドされています。 NPTv6は/ 64プレフィックスを別の/ 64プレフィックスにマップします。 NPTv6トランスレーターが/ 48以下のプレフィックスで構成されている場合、64ビットのインターフェイス識別子は変換中に変更されずに保持されます。ただし、「内部」と「外部」の接頭辞が同じ長さである限り、/ 64境界は変更される可能性があります。
o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is designed around the /64 boundary, since it relies on locally unique 64-bit node identifiers (in the interface identifier field). While a redesign to use longer prefixes is not inconceivable, this would need major changes to the existing specification for the IPv6 version of ILNP.
o ILNP：Identifier-Locator Network Protocol（ILNP）[RFC6741]は、ローカルで一意の64ビットノード識別子（インターフェイス識別子フィールド内）に依存するため、/ 64境界を中心に設計されています。より長いプレフィックスを使用するように再設計することは考えられませんが、これにはILNPのIPv6バージョンの既存の仕様に大きな変更が必要になります。
o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in its insecure form treats IPv6 addresses as opaque 128-bit objects. However, to secure the protocol against spoofing, it is essential to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs are generated using a procedure that assumes a 64-bit identifier. Therefore, in effect, secure shim6 is affected by the /64 boundary exactly like CGAs.
o Shim6：IPv6のマルチホーミングShimプロトコル（Shim6）[RFC5533]は、安全でない形式でIPv6アドレスを不透明な128ビットオブジェクトとして扱います。ただし、なりすましからプロトコルを保護するには、CGA（上記を参照）またはHBA [RFC5535]を使用することが不可欠です。 CGAと同様に、HBAは64ビットの識別子を前提とする手順を使用して生成されます。したがって、実質的に、セキュアなshim6はCGAとまったく同じように/ 64境界の影響を受けます。
o Duplicate address risk: If SLAAC was modified to work with shorter IIDs, the statistical risk of hosts choosing the same pseudo-random identifier [RFC7217] would increase correspondingly. The practical impact of this would range from slight to dramatic, depending on how much the IID length was reduced. In particular, a /120 prefix would imply an 8-bit IID and address collisions would be highly probable.
o 重複アドレスのリスク：SLAACがより短いIIDで機能するように変更された場合、同じ疑似ランダム識別子[RFC7217]を選択するホストの統計的リスクがそれに応じて増加します。これの実際的な影響は、IIDの長さがどの程度削減されたかに応じて、わずかなものから劇的なものまでさまざまです。特に、/ 120プレフィックスは8ビットのIIDを意味し、アドレスの衝突が発生する可能性が非常に高くなります。
o The link-local prefix: While RFC 4862 is careful not to define any specific length of link-local prefix within fe80::/10, the addressing architecture [RFC4291] does define the link-local IID length to be 64 bits. If different hosts on a link used IIDs of different lengths to form a link-local address, there is potential for confusion and unpredictable results. Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface, in accordance with the relevant IPv6-over-foo specification, and systems behave as if the link-local prefix was actually fe80::/64. There might be no way to change this except conceivably by manual configuration, which will be impossible if the host concerned has no local user interface.
oリンクローカルプレフィックス：RFC 4862はfe80 :: / 10内でリンクローカルプレフィックスの特定の長さを定義しないように注意していますが、アドレッシングアーキテクチャ[RFC4291]はリンクローカルIIDの長さを64ビットに定義しています。リンク上の異なるホストが異なる長さのIIDを使用してリンクローカルアドレスを形成した場合、混乱や予測できない結果が生じる可能性があります。現在、通常、リンクローカルIIDの長さの64ビットの選択は、関連するIPv6-over-foo仕様に従ってインターフェイスごとにハードコーディングされており、システムは、リンクローカルプレフィックスが実際にはfe80 :: / 64であるかのように動作します。 。おそらく手動による設定を除いて、これを変更する方法がない可能性があります。関係するホストにローカルユーザーインターフェイスがない場合、これは不可能です。
It goes without saying that if prefixes longer than /64 are to be used, all hosts must be capable of generating IIDs shorter than 64 bits, in order to follow the auto-configuration procedure correctly [RFC4862].
言うまでもなく、/ 64より長いプレフィックスを使用する場合、自動構成手順を正しく実行するには、すべてのホストが64ビットより短いIIDを生成できる必要があります[RFC4862]。
4.3.1. Survey of the processing of Neighbor Discovery Options with Prefixes Other than /64
4.3.1. / 64以外の接頭辞を持つ近傍検索オプションの処理の調査
This section provides a survey of the processing of Neighbor Discovery options that include prefixes that are different than /64.
このセクションでは、/ 64以外のプレフィックスを含む近隣探索オプションの処理について概説します。
The behavior of nodes was assessed with respect to the following options:
ノードの動作は、次のオプションに関して評価されました。
o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit set.
o PIO-A：Aビットが設定されたプレフィックス情報オプション（PIO）[RFC4861]。
o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit set.
o PIO-L：Lビットが設定されたプレフィックス情報オプション（PIO）[RFC4861]。
o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A and L bits set.
o PIO-AL：AとLの両方のビットが設定されたプレフィックス情報オプション（PIO）[RFC4861]。
o RIO: Route Information Option (RIO) [RFC4191].
o RIO：ルート情報オプション（RIO）[RFC4191]。
In the tables below, the following notation is used:
以下の表では、次の表記が使用されています。
NOT-SUP: This option is not supported (i.e., it is ignored no matter the prefix length used).
NOT-SUP：このオプションはサポートされていません（つまり、使用されるプレフィックス長に関係なく無視されます）。
LOCAL: The corresponding prefix is considered "on-link".
ローカル：対応するプレフィックスは「オンリンク」と見なされます。
ROUTE: The corresponding route is added to the IPv6 routing table.
ROUTE：対応するルートがIPv6ルーティングテーブルに追加されます。
NOT-DEF: The default configuration is NOT-SUP, but there is an option to enable ROUTE.
NOT-DEF：デフォルトの構成はNOT-SUPですが、ROUTEを有効にするオプションがあります。
IGNORE: The option is ignored as an error.
IGNORE：オプションはエラーとして無視されます。
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
Table 1: Processing of ND options with prefixes longer than /64
表1：/ 64より長い接頭辞を持つNDオプションの処理
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
Table 2: Processing of ND options with prefixes shorter than /64
表2：/ 64より短い接頭辞を持つNDオプションの処理
The results obtained can be summarized as follows:
得られた結果は、次のように要約できます。
o The "A" bit in the Prefix Information Options is honored only if the prefix length is 64. This is consistent with [RFC4862], at least for the case where the IID length is defined to be 64 bits in the corresponding link-type-specific document, which is the case for all currently published such documents. [RFC4862] defines the case where the sum of the advertised prefix length and the IID length does not equal 128 as an error condition.
oプレフィックス情報オプションの「A」ビットは、プレフィックス長が64の場合にのみ有効です。これは、少なくともIIDの長さが対応するリンクタイプで64ビットとして定義されている場合、[RFC4862]と一致しています。固有のドキュメント。これは、現在公開されているすべてのドキュメントに当てはまります。 [RFC4862]は、アドバタイズされたプレフィックス長とIID長の合計が128に等しくない場合をエラー条件として定義しています。
o The "L" bit in the Prefix Information Options is honored for any arbitrary prefix length (whether shorter or longer than /64).
o 接頭辞情報オプションの「L」ビットは、任意の接頭辞の長さ（/ 64より短いか長いか）に適用されます。
o Nodes that support the Route Information Option allow such routes to be specified with prefixes of any arbitrary length (whether shorter or longer than /64)
o ルート情報オプションをサポートするノードでは、このようなルートを任意の長さ（/ 64より短いか長いか）のプレフィックスで指定できます。
Participants in the V6OPS working group have indicated that some forwarding devices have been shown to work correctly with long prefixes such as /80 or /96. Indeed, it is to be expected that forwarding based on the longest prefix match will work for any prefix length, and no reports of this completely failing have been noted. Also, DHCPv6 is in widespread use without any dependency on the /64 boundary. Reportedly, there are deployments of /120 subnets configured using DHCPv6.
V6OPSワーキンググループの参加者は、一部の転送デバイスが/ 80や/ 96などの長いプレフィックスで正しく動作することが示されていることを示しています。実際、最長のプレフィックスの一致に基づく転送は、どのプレフィックス長でも機能することが予想され、この完全に失敗したという報告はありません。また、DHCPv6は、/ 64境界に依存せずに広く使用されています。報告によると、DHCPv6を使用して構成された/ 120サブネットの展開があります。
There have been definite reports that some routers have a performance drop-off or even resource exhaustion for prefixes longer than /64 due to design issues. In particular, some routing chip designs allocate much less space for longer prefixes than for prefixes up to /64 for the sake of savings in memory, power, and lookup latency. Some devices need special-case code to handle point-to-point links according to [RFC6164].
一部のルーターでは、設計上の問題により、/ 64よりも長いプレフィックスのパフォーマンスが低下したり、リソースが枯渇したりするという明確な報告があります。特に、一部のルーティングチップデザインでは、メモリ、電力、およびルックアップの待ち時間を節約するために、/ 64までの接頭辞よりも長い接頭辞に割り当てるスペースがはるかに少なくなっています。一部のデバイスは、[RFC6164]に従ってポイントツーポイントリンクを処理するために特別なケースのコードを必要とします。
It has been reported that at least one type of switch has a content-addressable memory limited to 144 bits, which is indeed a typical value for commodity components [TCAM]. This means that packet filters or access control lists cannot be defined based on 128-bit addresses and two 16-bit port numbers; the longest prefix that could be used in such a filter is a /112.
少なくとも1つのタイプのスイッチには、144ビットに制限された連想メモリがあり、これは実際に商品コンポーネント[TCAM]の典型的な値であることが報告されています。つまり、128ビットアドレスと2つの16ビットポート番号に基づいてパケットフィルターまたはアクセス制御リストを定義することはできません。このようなフィルターで使用できる最長のプレフィックスは/ 112です。
From an early stage, implementations and deployments of IPv6 assumed the /64 subnet length, even though routing was based on prefixes of any length. As shown above, this became anchored in many specifications (Section 4.1) and in important aspects of implementations commonly used in local area networks (Section 4.3). In fact, a programmer might be lulled into assuming a comfortable rule of thumb that subnet prefixes are always /64 and an IID is always of length 64. Apart from the limited evidence in Section 4.3.1, we cannot tell without code inspections or tests
初期段階から、ルーティングは任意の長さのプレフィックスに基づいていましたが、IPv6の実装と展開では/ 64サブネット長が想定されていました。上記のように、これは多くの仕様（セクション4.1）およびローカルエリアネットワークで一般的に使用される実装の重要な側面（セクション4.3）で定着しました。実際、プログラマーは、サブネットプレフィックスは常に/ 64で、IIDは常に長さ64であるという大まかな経験則に思い悩むかもしれません。セクション4.3.1の限られた証拠は別として、コードインスペクションまたはテストなしではわかりません
whether existing stacks are able to handle a flexible IID length or whether they would require modification to do so. A conforming implementation of an IPv6-over-foo that specifies a 64 bit IID for foo links will of course only support 64. But in a well designed stack, the IP layer itself will treat that 64 as a parameter, so changing the IID length in the IPv6-over-foo code should be all that is necessary.
既存のスタックが柔軟なIIDの長さを処理できるかどうか、またはそのために変更が必要かどうか。もちろん、fooリンクの64ビットIIDを指定するIPv6-over-fooの準拠実装は64のみをサポートします。ただし、適切に設計されたスタックでは、IP層自体がその64をパラメーターとして扱い、IIDの長さを変更しますIPv6-over-fooコードでは、必要なものがすべて必要です。
The main practical consequence of the existing specifications is that deployments in which longer subnet prefixes are used cannot make use of SLAAC-configured addresses and require either manually configured addresses or DHCPv6. To reverse this argument, if it was considered desirable to allow auto-configured addresses with subnet prefixes longer than /64, all of the specifications identified above as depending on /64 would have to be modified with due regard to interoperability with unmodified stacks. In fact, [RFC7217] allows for this possibility. Then, modified stacks would have to be developed and deployed. It might be the case that some stacks contain dependencies on the /64 boundary that are not directly implied by the specifications, and any such hidden dependencies would also need to be found and removed.
既存の仕様の主な実用的な結果は、より長いサブネットプレフィックスが使用される展開では、SLAAC構成のアドレスを利用できず、手動で構成されたアドレスまたはDHCPv6のいずれかを必要とすることです。この引数を逆にするには、/ 64よりも長いサブネットプレフィックスを持つ自動構成アドレスを許可することが望ましいと考えられる場合、未変更のスタックとの相互運用性を考慮して、/ 64に依存する上記のすべての仕様を変更する必要があります。実際、[RFC7217]はこの可能性を考慮しています。次に、変更されたスタックを開発してデプロイする必要があります。一部のスタックに/ 64境界の依存関係が含まれていて、仕様に直接関係していない場合があり、そのような隠された依存関係も見つけて削除する必要があります。
At least one DHCPv6 client unconditionally installs a /64 prefix as on-link when it configures an interface with an address, although some specific operating system vendors seem to change this default behavior by tweaking a client-side script. This is in clear violation of the IPv6 subnet model [RFC5942]. The motivation for this choice is that if there is no router on the link, the hosts would fail to communicate with each other using the configured addresses because the "on-link assumption" was removed in [RFC4861]. This is not really about the magic number of 64, but an implementation may sometimes pick an arbitrary value of prefix length due to the removal of the on-link assumption, and the value chosen will most likely be 64.
少なくとも1つのDHCPv6クライアントは、アドレスを使用してインターフェイスを構成するときに無条件で/ 64プレフィックスをオンリンクとしてインストールしますが、一部の特定のオペレーティングシステムベンダーは、クライアント側のスクリプトを微調整することによってこのデフォルトの動作を変更しているようです。これはIPv6サブネットモデル[RFC5942]に明らかに違反しています。この選択の動機は、[RFC4861]で「リンク上の仮定」が削除されたため、リンク上にルーターがない場合、ホストは構成されたアドレスを使用して相互に通信できないことです。これは実際には64のマジックナンバーではありませんが、実装では、オンリンクの仮定が削除されたため、プレフィックス長の任意の値が選択される場合があり、選択された値はおそらく64になります。
Typical IP Address Management (IPAM) tools treat /64 as the default subnet length but allow users to specify longer subnet prefixes if desired. Clearly, all IPAM tools and network management systems would need to be checked in detail.
典型的なIPアドレス管理（IPAM）ツールは/ 64をデフォルトのサブネット長として扱いますが、ユーザーは必要に応じてより長いサブネットプレフィックスを指定できます。明らかに、すべてのIPAMツールとネットワーク管理システムを詳細にチェックする必要があります。
Finally, IPv6 is already deployed at many sites, with a large number of staff trained on the basis of the existing standards, supported by documentation and tools based on those standards. Numerous existing middlebox devices are also based on those standards. These people, documents, tools, and devices represent a very large investment that would be seriously impacted by a change in the /64 boundary.
最後に、IPv6はすでに多くのサイトに展開されており、多数のスタッフが既存の標準に基づいてトレーニングされ、それらの標準に基づくドキュメントとツールによってサポートされています。既存のミドルボックスデバイスの多くも、これらの標準に基づいています。これらの人、ドキュメント、ツール、デバイスは、/ 64境界の変更によって深刻な影響を受ける非常に大きな投資を表しています。
The length of the interface identifier has implications for privacy [ADDRESS-PRIVACY]. In any case in which the value of the identifier is intended to be hard to guess, whether or not it is cryptographically generated, it is apparent that more bits are better. For example, if there are only 20 bits to be guessed, then at most just over a million guesses are needed, which is well within the capacity of a low-cost attack mechanism. It is hard to state in general how many bits are enough to protect privacy, since this depends on the resources available to the attacker, but it seems clear that a privacy solution needs to resist an attack requiring billions rather than millions of guesses. Trillions would be better, suggesting that at least 40 bits should be available. Thus, we can argue that subnet prefixes longer than say /80 might raise privacy concerns by making the IID guessable.
インターフェース識別子の長さはプライバシーに影響を与えます[ADDRESS-PRIVACY]。識別子の値が推測しにくいものである場合は、暗号で生成されているかどうかにかかわらず、より多くのビットが優れていることは明らかです。たとえば、推測するビットが20ビットしかない場合、必要な推測はせいぜい100万を超えます。これは、低コストの攻撃メカニズムの能力の範囲内です。プライバシーを保護するのに十分なビット数は攻撃者が利用できるリソースに依存するため、一般的に何ビットで十分かを述べることは困難ですが、プライバシーソリューションは何百万もの推測ではなく何十億もの攻撃を必要とする攻撃に抵抗する必要があることは明らかです。数兆の方が良いので、少なくとも40ビットが利用可能である必要があります。したがって、/ 80よりも長いサブネットプレフィックスは、IIDを推測可能にすることでプライバシーの懸念を引き起こす可能性があると主張できます。
A prefix long enough to limit the number of addresses comparably to an IPv4 subnet, such as /120, would create exactly the same situation for privacy as IPv4 except for the absence of NAT. In particular, a host would be forced to pick a new IID when roaming to a new network to avoid collisions. As mentioned earlier, it is likely that SLAAC will not be used on such a subnet.
アドレスの数を/ 120などのIPv4サブネットと同等に制限するのに十分な長さのプレフィックスは、NATがないことを除いて、IPv4とまったく同じプライバシーの状況を作成します。特に、衝突を避けるために、新しいネットワークにローミングするとき、ホストは新しいIIDを選択する必要があります。前述のように、SLAACはそのようなサブネットでは使用されない可能性があります。
In addition to the privacy issues mentioned in Section 4.5 and the issues mentioned with CGAs and HBAs in Section 4.2, the length of the subnet prefix affects the matter of defense against scanning attacks [HOST-SCANNING]. Assuming the attacker has discovered or guessed the prefix length, a longer prefix reduces the space that the attacker needs to scan, e.g., to only 256 addresses if the prefix is /120. On the other hand, if the attacker has not discovered the prefix length and assumes it to be /64, routers can trivially discard attack packets that do not fall within an actual subnet.
セクション4.5で言及されたプライバシーの問題とセクション4.2で言及されたCGAおよびHBAに関する問題に加えて、サブネットプレフィックスの長さは、スキャン攻撃に対する防御の問題に影響します[ホストスキャン]。攻撃者がプレフィックス長を発見または推測した場合、プレフィックスが長くなると、攻撃者がスキャンする必要のあるスペースが減少します。たとえば、プレフィックスが/ 120の場合、256アドレスのみになります。一方、攻撃者がプレフィックス長を発見せずに/ 64であると想定した場合、ルーターは実際のサブネットに含まれない攻撃パケットを簡単に破棄できます。
However, assume that an attacker finds one valid address "A" and assumes that it is within a long prefix such as a /120. The attacker then starts a scanning attack by scanning "outwards" from A, by trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all hosts in any subnet with a long prefix, because they will have addresses close to A. We therefore conclude that any prefix containing densely packed valid addresses is vulnerable to a scanning attack, without the attacker needing to guess the prefix length. Therefore, to preserve IPv6's advantage over IPv4 in resisting scanning attacks, it is important that subnet prefixes are short enough to allow sparse allocation of identifiers within each subnet. The considerations are similar to those for privacy, and we can again argue that prefixes longer than say /80 might significantly increase vulnerability. Ironically, this argument is exactly converse to the argument for longer prefixes to resist an ND cache attack, as described in Section 3.4.
ただし、攻撃者が1つの有効なアドレス「A」を見つけ、それが/ 120などの長いプレフィックス内にあると想定します。次に攻撃者は、A + 1、A-1、A + 2、A-2などを試行することにより、Aから「外向き」にスキャンすることでスキャン攻撃を開始します。この攻撃者は、長いプレフィックスを持つサブネット内のすべてのホストを簡単に見つけます。 Aに近いアドレスを持つためです。したがって、密にパックされた有効なアドレスを含むプレフィックスは、攻撃者がプレフィックス長を推測する必要なく、スキャン攻撃に対して脆弱であると結論付けます。したがって、スキャン攻撃に対抗する際にIPv4よりもIPv6の利点を維持するには、サブネットプレフィックスを短くして、各サブネット内の識別子をまばらに割り当てることが重要です。考慮事項はプライバシーの場合と同様であり、プレフィックスが/ 80と言うよりも長いと、脆弱性が大幅に増加する可能性があることを再度主張できます。皮肉なことに、この議論は、セクション3.4で説明されているように、NDキャッシュ攻撃に抵抗するためのより長いプレフィックスの議論とは正反対です。
Denial-of-service attacks related to Neighbor Discovery are discussed in Section 3.4 and in [RFC6583]. One of the mitigations suggested by that document is "sizing subnets to reflect the number of addresses actually in use", but the fact that this greatly simplifies scanning attacks is not noted. For further discussion of scanning attacks, see [HOST-SCANNING].
近隣探索に関連するサービス拒否攻撃については、セクション3.4と[RFC6583]で説明されています。このドキュメントで提案されている緩和策の1つは、「実際に使用されているアドレスの数を反映するようにサブネットのサイズを変更する」ことですが、これによりスキャン攻撃が大幅に簡略化されるという事実は指摘されていません。スキャン攻撃の詳細については、[HOST-SCANNING]を参照してください。
Note that, although not known at the time of writing, there might be other resource exhaustion attacks available, similar in nature to the ND cache attack. We cannot exclude that such attacks might be exacerbated by sparsely populated subnets such as a /64. It should also be noted that this analysis assumes a conventional deployment model with a significant number of end-systems located in a single LAN broadcast domain. Other deployment models might lead to different conclusions.
この記事の執筆時点では判明していませんが、NDキャッシュ攻撃と性質が似ている他のリソース枯渇攻撃が利用できる可能性があることに注意してください。そのような攻撃が/ 64などのまばらに存在するサブネットによって悪化する可能性があることを除外することはできません。また、この分析では、単一のLANブロードキャストドメインに多数のエンドシステムが配置されている従来の展開モデルを想定していることにも注意してください。他の展開モデルは異なる結論を導く可能性があります。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、December 1998、<http://www.rfc-editor.org/info/rfc2464>。
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998, <http://www.rfc-editor.org/info/rfc2467>.
[RFC2467] Crawford、M。、「Transmission of IPv6 Packets over FDDI Networks」、RFC 2467、December 1998、<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, December 1998, <http://www.rfc-editor.org/info/rfc2470>.
[RFC2470] Crawford、M.、Narten、T。、およびS. Thomas、「Token Ring Networks over IPv6 Packets over Token Ring Networks」、RFC 2470、1998年12月、<http://www.rfc-editor.org/info/ rfc2470>。
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999, <http://www.rfc-editor.org/info/rfc2492>.
[RFC2492]アーミテージ、G。、シュルター、P。、およびM.ジョーク、「IPv6 over ATM Networks」、RFC 2492、1999年1月、<http://www.rfc-editor.org/info/rfc2492>。
[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, January 1999, <http://www.rfc-editor.org/info/rfc2497>.
[RFC2497] Souvatzis、I.、 "Transmission of IPv6 Packets over ARCnet Networks"、RFC 2497、January 1999、<http://www.rfc-editor.org/info/rfc2497>。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999, <http://www.rfc-editor.org/info/rfc2526>.
[RFC2526] Johnson、D。およびS. Deering、「予約済みIPv6サブネットエニーキャストアドレス」、RFC 2526、1999年3月、<http://www.rfc-editor.org/info/rfc2526>。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999, <http://www.rfc-editor.org/info/rfc2529>.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメイン上のIPv6の転送」、RFC 2529、1999年3月、<http://www.rfc-editor.org/info/rfc2529>。
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, 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、1999年5月、<http://www.rfc-editor.org/info / rfc2590>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月、<http://www.rfc-editor.org/info/ rfc2710>。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月、<http://www.rfc-editor.org/info/rfc3056>。
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001, <http://www.rfc-editor.org/info/rfc3146>.
[RFC3146] Fujisawa、K. and A. Onoe、 "Transmission of IPv6 Packets over IEEE 1394 Networks"、RFC 3146、October 2001、<http://www.rfc-editor.org/info/rfc3146>。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002, <http://www.rfc-editor.org/info/rfc3306>.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-Prefix-based IPv6 Multicast Addresses」、RFC 3306、2002年8月、<http://www.rfc-editor.org/info/rfc3306>。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003, <http://www.rfc-editor.org/info/rfc3590>.
[RFC3590] Haberman、B。、「Multicast Listener Discovery（MLD）Protocolのソースアドレス選択」、RFC 3590、2003年9月、<http://www.rfc-editor.org/info/rfc3590>。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月、<http://www.rfc-editor.org/info/rfc3810>。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[RFC3956] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、2004年11月、<http://www.rfc-editor.org/info/rfc3956 >。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月、<http://www.rfc-editor.org/info/rfc3972>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「Default Router Preferences and More-Specific Routes」、RFC 4191、2005年11月、<http://www.rfc-editor.org/info/rfc4191>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]ノードマーク、E。およびR.ギリガン、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月、<http://www.rfc-editor.org/info/rfc4213>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、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, January 2006, <http://www.rfc-editor.org/info/rfc4338>.
[RFC4338] DeSanti、C.、Carlson、C。、およびR. Nixon、「IPv6、IPv4、およびアドレス解決プロトコル（ARP）パケットのファイバーチャネル上での送信」、RFC 4338、2006年1月、<http：// www .rfc-editor.org / info / rfc4338>。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月、<http://www.rfc-editor.org/info/rfc4380>。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>.
[RFC4429] Moore、N。、「IPv6の楽観的重複アドレス検出（DAD）」、RFC 4429、2006年4月、<http://www.rfc-editor.org/info/rfc4429>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：//www.rfc- editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、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, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、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, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、2007年9月、<http：//www.rfc -editor.org/info/rfc4944>。
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007, <http://www.rfc-editor.org/info/rfc5072>.
[RFC5072] Varada、S.、Haskins、D。、およびE. Allen、「IPバージョン6 over PPP」、RFC 5072、2007年9月、<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, 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、2008年2月、< http://www.rfc-editor.org/info/rfc5121>。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月、<http://www.rfc-editor.org/ info / rfc5214>。
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009, <http://www.rfc-editor.org/info/rfc5453>.
[RFC5453] Krishnan、S。、「Reserved IPv6 Interface Identifiers」、RFC 5453、2009年2月、<http://www.rfc-editor.org/info/rfc5453>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E.およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、2009年6月、<http://www.rfc-editor.org/info/rfc5533>。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>.
[RFC5535] Bagnulo、M。、「ハッシュベースアドレス（HBA）」、RFC 5535、2009年6月、<http://www.rfc-editor.org/info/rfc5535>。
[RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009, <http://www.rfc-editor.org/info/rfc5692>.
[RFC5692] Jeon、H.、Jeong、S。、およびM. Riegel、「IP over Ethernet over IEEE 802.16 Networks」、RFC 5692、2009年10月、<http://www.rfc-editor.org/info / rfc5692>。
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010, <http://www.rfc-editor.org/info/rfc5942>.
[RFC5942] Singh、H.、Beebee、W。、およびE. Nordmark、「IPv6サブネットモデル：リンクとサブネットプレフィックスの関係」、RFC 5942、2010年7月、<http://www.rfc-editor.org / info / rfc5942>。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructure on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月、<http://www.rfc-editor.org/info/rfc5969 >。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月、<http：// www .rfc-editor.org / info / rfc6052>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月、<http：// rfc-editor .org / info / rfc6146>。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]河野正明、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリッティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164、 2011年4月、<http://www.rfc-editor.org/info/rfc6164>。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
[RFC6177] Narten、T.、Huston、G。、およびL. Roberts、「エンドサイトへのIPv6アドレスの割り当て」、BCP 157、RFC 6177、2011年3月、<http://www.rfc-editor.org/info / rfc6177>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、2011年11月、<http://www.rfc-editor.org/info / rfc6437>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、2013年11月、<http：//www.rfc-editor。 org / info / rfc7084>。
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、2014年2月、<http://www.rfc-editor.org/info/rfc7136>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、2014年10月、< http://www.rfc-editor.org/info/rfc7296>。
[ADDRESS-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, draft-ietf-6man-ipv6-address-generation-privacy-02, October 2014.
[ADDRESS-PRIVACY] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのプライバシーに関する考慮事項」、作業中、draft-ietf-6man-ipv6-address-generation-privacy-02、 2014年10月。
[AERO-TRANS] Templin, F., "Transmission of IP Packets over AERO Links", Work in Progress, draft-templin-aerolink-46, October 2014.
[AERO-TRANS] Templin、F。、「AEROリンクを介したIPパケットの送信」、進行中の作業、draft-templin-aerolink-46、2014年10月。
[BLUETOOTH-LE] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Work in Progress, draft-ietf-6lowpan-btle-12, February 2013.
[BLUETOOTH-LE] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「BLUETOOTH Low Energyを介したIPv6パケットの送信」、作業中、 draft-ietf-6lowpan-btle-12、2013年2月。
[HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host-scanning-04, June 2014.
[HOST-SCANNING] Gont、F。およびT. Chown、「IPv6ネットワークのネットワーク偵察」、作業中、draft-ietf-opsec-ipv6-host-scanning-04、2014年6月。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001 (R2007), 2007.
[IEEE802] IEEE、「IEEE Standard for Local and Metropolitan Area Networks：Overview and Architecture」、IEEE Std 802-2001（R2007）、2007。
[IPv6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Work in Progress, draft-ietf-6lo-lowpanz-08, October 2014.
[IPv6-G9959] Brandt、A。およびJ. Buron、「ITU-T G.9959ネットワークを介したIPv6パケットの送信」、Work in Progress、draft-ietf-6lo-lowpanz-08、2014年10月。
[IPv6-TRANS] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", Work in Progress, draft-ietf-6lo-6lobac-00, July 2014.
[IPv6-TRANS] Lynn、K.、Ed。、Martocci、J.、Neilson、C。、およびS. Donaldson、「MS / TPネットワークを介したIPv6の伝送」、作業中、draft-ietf-6lo-6lobac -00、2014年7月。
[ODELL] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, draft-odell-8+8-00, October 1996.
[ODELL] O'Dell、M。、「8 + 8-IPv6の代替アドレス指定アーキテクチャ」、作業中、draft-odell-8 + 8-00、1996年10月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, <http://www.rfc-editor.org/info/rfc2629>.
[RFC2629] Rose、M。、「XMLを使用したI-DおよびRFCの記述」、RFC 2629、1999年6月、<http://www.rfc-editor.org/info/rfc2629>。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月、<http://www.rfc-editor.org/ info / rfc3756>。
[RFC4692] Huston, G., "Considerations on the IPv6 Host Density Metric", RFC 4692, October 2006, <http://www.rfc-editor.org/info/rfc4692>.
[RFC4692] Huston、G。、「Considerations on the IPv6 Host Density Metric」、RFC 4692、2006年10月、<http://www.rfc-editor.org/info/rfc4692>。
[RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007, <http://www.rfc-editor.org/info/rfc4887>.
[Rufsey ౪౮౮౭] Tubert、P。、脇川、R。、およびW. Devarapalli、「ネットワークモビリティホームネットワークモデル」、Rfak4、2009年7月、<http://www.rfak-editor.org/info/rofsy1>。
[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009, <http://www.rfc-editor.org/info/rfc5505>.
[RFC5505] Aboba、B.、Thaler、D.、Andersson、L。、およびS. Cheshire、「Principles of Internet Host Configuration」、RFC 5505、2009年5月、<http://www.rfc-editor.org/ info / rfc5505>。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://rfc-editor.org/info/rfc6583>.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、2012年3月、<http://rfc-editor.org/info/rfc6583>。
[RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012, <http://www.rfc-editor.org/info/rfc6741>.
[RFC6741] Atkinson ,, RJ。、 "Identifier-Locator Network Protocol（ILNP）Engineering Considerations"、RFC 6741、November 2012、<http://www.rfc-editor.org/info/rfc6741>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M.、C。Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、2013年4月、<http://www.rfc-editor.org/info/ rfc6877>。
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, January 2014, <http://www.rfc-editor.org/info/rfc7094>.
[RFC7094] McPherson、D.、Oran、D.、Thaler、D。、およびE. Osterweil、「IP Anycastのアーキテクチャに関する考慮事項」、RFC 7094、2014年1月、<http://www.rfc-editor.org/ info / rfc7094>。
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、2014年4月、<http://www.rfc-editor.org/info/rfc7217> 。
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>.
[RFC7278] Byrne、C.、Drown、D。、およびA. Vizdal、「IPv6 / 64プレフィックスの第3世代パートナーシッププロジェクト（3GPP）モバイルインターフェースからLANリンクへの拡張」、RFC 7278、2014年6月、<http ：//www.rfc-editor.org/info/rfc7278>。
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC, 7368, October 2014.
[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC、7368、2014年10月。
[TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic Approaches to Redesigning TCAM-Based Systems", ACM SIGMETRICS'08 467-468, 2008.
[TCAM] Meiners、C.、Liu、A。、およびE. Torng、「TCAMベースのシステムを再設計するためのアルゴリズム的アプローチ」、ACM SIGMETRICS'08 467-468、2008。
Acknowledgements
謝辞
This document was inspired by a vigorous discussion on the V6OPS working group mailing list with at least 20 participants. Later, valuable comments were received from Ran Atkinson, Fred Baker, Steven Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other participants in the 6MAN working group. An extremely detailed review by Mark Smith was especially helpful.
このドキュメントは、少なくとも20人の参加者がいるV6OPSワーキンググループメーリングリストでの活発な議論に触発されました。その後、Ran Atkinson、Fred Baker、Steven Blake、Lorenzo Colitti、David Farmer、Bill Fenner、Ray Hunter、Paraskevi Iliadou、Jen Linkova、Philip Matthews、Matthew Petach、Scott Schmit、Tatuya Jinmei、Fred Templin、Oleから貴重なコメントを受け取りましたTroan、Stig Venaas、および6MANワーキンググループの他の多数の参加者。 Mark Smithによる非常に詳細なレビューが特に役に立ちました。
This document was originally produced using the xml2rfc tool [RFC2629].
このドキュメントは、もともとxml2rfcツール[RFC2629]を使用して作成されました。
Authors' Addresses
著者のアドレス
Brian Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand EMail: brian.e.carpenter@gmail.com
ブライアンカーペンター（編集者）オークランド大学コンピューターサイエンス学部PB 92019オークランド1142ニュージーランドメール：brian.e.carpenter@gmail.com
Tim Chown University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
Tim Chown University of Southamptonサウサンプトン、ハンプシャーSO17 1BJイギリスEメール：tjc@ecs.soton.ac.uk
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina EMail: fgont@si6networks.com
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo、Province of Buenos Aires 1706 Argentina EMail：fgont@si6networks.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
S横江hu Aはテクノロジー株式会社Q14、hu Aはキャンパスno.156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国Eメール：natal@huawei.com
Alexandru Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France EMail: Alexandru.Petrescu@cea.fr
Alexandru Petrescu CEA、リストCEA Saclay Gif-sur-Yvette、イルドフランス91190フランスメール：Alexandru.Petrescu@cea.fr
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem 1830 Belgium EMail: ayourtch@cisco.com
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem 1830 Belgium EMail：ayourtch@cisco.com