Internet Engineering Task Force (IETF) P. Eronen
Request for Comments: 5739 Nokia
Category: Experimental J. Laganier
ISSN: 2070-1721 QUALCOMM, Inc.
C. Madson
Cisco Systems
February 2010
IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
インターネット鍵交換プロトコルバージョン2（IKEv2の）でのIPv6の設定
Abstract
抽象
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link".
インターネット鍵交換プロトコルバージョン2（IKEv2の）は、リモートVPNアクセス（VPNゲートウェイにクライアント）のために使用される場合、ゲートウェイはクライアントにのIKEv2構成ペイロードを使用して、内部ネットワークからIPアドレスを割り当てます。設定ペイロードは、IPv4のためによくRFC 4306の作業で指定されたが、それは難しいのIPv6の特定の機能を使用するために作ります。この文書では、クライアント・ゲートウェイ「仮想リンク」で使用するのIPv6のすべての機能を有効にする、クライアントへのIPv6プレフィックスを割り当てるためにVPNゲートウェイを可能にするIKEv2のための新しい設定属性を指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5739.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5739で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction and Problem Statement ..............................4
2. Terminology .....................................................5
3. Current Limitations and Goals ...................................6
3.1. Multiple Prefixes ..........................................6
3.2. Link-Local Addresses .......................................6
3.3. Interface Identifier Selection .............................7
3.4. Sharing VPN Access .........................................7
3.5. General Goals ..............................................8
3.6. Non-Goals ..................................................8
3.7. Additional Information .....................................9
4. Solution Details ................................................9
4.1. Initial Exchanges ..........................................9
4.2. Reauthentication ..........................................11
4.3. Creating CHILD_SAs ........................................11
4.4. Relationship to Neighbor Discovery ........................12
4.5. Relationship to Existing IKEv2 Payloads ...................13
5. Payload Formats ................................................13
5.1. INTERNAL_IP6_LINK Configuration Attribute .................13
5.2. INTERNAL_IP6_PREFIX Configuration Attribute ...............14
5.3. LINK_ID Notify Payload ....................................14
6. IANA Considerations ............................................15
7. Security Considerations ........................................15
8. Acknowledgments ................................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................16
Appendix A. Design Rationale (Non-Normative) ...................19
A.1. Link Model ................................................20
A.2. Distributing Prefix Information ...........................20
A.3. Unique Address Allocation .................................21
A.4. Layer 3 Access Control ....................................21
A.5. Other Considerations ......................................22
A.6. Alternative Solution Sketches .............................24
A.6.1. Version -00 Sketch ..................................24
A.6.2. Router Aggregation Sketch #1 ..........................25
A.6.3. Router Aggregation Sketch #2 ..........................27
A.6.4. IPv4-Like Sketch ....................................28
A.6.5. Sketch Based on RFC 3456 ..............................30
Appendix B. Evaluation (Non-Normative) .........................31
In typical remote access VPN use (client to VPN gateway), the client needs an IP address in the network protected by the security gateway. IKEv2 includes a feature called "configuration payloads" that allows the gateway to dynamically assign a temporary address to the client [IKEv2].
典型的なリモートアクセスVPNの利用（VPNゲートウェイへのクライアント）では、クライアントは、セキュリティゲートウェイで保護されたネットワーク内でIPアドレスを必要とします。 IKEv2のゲートウェイが動的にクライアント[IKEv2の]への一時的なアドレスを割り当てることができ、「設定ペイロード」と呼ばれる機能が含まれています。
For IPv4, the message exchange would look as follows:
次のようにIPv4の場合、メッセージ交換はなります。
Client Gateway
-------- ---------
HDR(IKE_SA_INIT), SAi1, KEi, Ni -->
ＨＤＲ（いけ＿さ＿いにＴ）、 さい１、 けい、 に ーー＞
<-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]
< - HDR（IKE_SA_INIT）SAR1、KBrをなし、[CERTREQ]
HDR(IKE_AUTH), SK { IDi, CERT, [CERTREQ], AUTH, [IDr], CP(CFG_REQUEST) = { INTERNAL_IP4_ADDRESS(), INTERNAL_IP4_DNS() }, SAi2, TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } -->
HDR（IKE_AUTH）、SK {IDI、CERT、[CERTREQ]、AUTH、[IDR]、CP（CFG_REQUEST）= {INTERNAL_IP4_ADDRESS（）、INTERNAL_IP4_DNS（）}、SAI2、をTSi =（0、0〜65535、0.0.0.0 -255.255.255.255）とTSR =（0、0〜65535、0.0.0.0〜255.255.255.255）} - >
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP4_ADDRESS(192.0.2.234),
INTERNAL_IP4_DNS(198.51.100.33) },
SAr2,
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }
Figure 1: IPv4 Configuration
図1：IPv4の設定
The IPv4 case has been implemented by various vendors and, in general, works well. IKEv2 also defines almost identical configuration payloads for IPv6:
IPv4のケースは、一般的には、うまく機能し、さまざまなベンダーによって実装されています。 IKEv2のもIPv6のほとんど同一の構成ペイロードを定義します。
Client Gateway
-------- ---------
HDR(IKE_AUTH), SK { IDi, CERT, [CERTREQ], AUTH, [IDr], CP(CFG_REQUEST) = { INTERNAL_IP6_ADDRESS(), INTERNAL_IP6_DNS() }, SAi2, TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF), TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } -->
HDR（IKE_AUTH）、SK {ID I、CERT、[CERTREQ]、AUTH、[IDR]、CP（CFG_REQUEST）= {INTERNAL_IP6_ADDRESS（）INTERNAL_IP6_DNS（）}、SAI2、をTSi =（0、0-65535、0：0 ：0：0：0：0：0：0 - FFFF：FFFF：FFFF：FFFF：FFFF：FFFF：FFFF：FFFF）、TSRは=（0、0-65535、0：0：0：0：0：0 ：0：0 - FFFF：FFFF：FFFF：FFFF：FFFF：FFFF：FFFF：FFFF）} - >
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5,
64),
INTERNAL_IP6_DNS(2001:DB8:9:8:7:6:5:4) },
SAr2,
TSi = (0, 0-65535,
2001:DB8:0:1:2:3:4:5 -
2001:DB8:0:1:2:3:4:5),
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) }
Figure 2: IPv6 Configuration
図2：IPv6設定
In other words, IPv6 is basically treated as IPv4 with larger addresses. As noted in [RFC4718], this does not fully follow the "normal IPv6 way of doing things", and it complicates or prevents using certain features of IPv6. Section 3 describes the limitations in detail.
換言すれば、IPv6は基本的に大きなアドレスとIPv4のものとして扱われます。 [RFC4718]で述べたように、これは完全に「物事の通常のIPv6道」を従っていない、そしてそれが複雑にまたはIPv6の特定の機能を使用して防ぐことができます。第3節では詳細に制限事項について説明します。
This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link".
この文書では、クライアント・ゲートウェイ「仮想リンク」で使用するのIPv6のすべての機能を有効にする、クライアントへのIPv6プレフィックスを割り当てるためにVPNゲートウェイを可能にするIKEv2のための新しい設定属性を指定します。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"); a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+").
IKEv2ペイロードを含むメッセージが説明されている場合、オプションのペイロードは、括弧内に示されている（例えば、「[FOO]」）。プラス記号は、ペイロードを1回以上繰り返すことができることを示している（例えば、「FOO +」）。
This document uses the term "virtual interface" when describing how the client uses the IPv6 address(es) assigned by the gateway. While existing IPsec documents do not use this term, it is not a new concept. In order to use the address assigned by the VPN gateway, current VPN clients already create a local "virtual interface", as only addresses assigned to interfaces can be used, e.g., as source addresses for TCP connections. Note that this definition of "interface" is not necessarily identical with what some particular implementations call "interface".
クライアントがゲートウェイによって割り当てられたIPv6アドレスを使用する方法を説明するときに、この文書では、用語「仮想インターフェイス」を使用しています。既存のIPsec文書は、この用語を使用していませんが、それは新しい概念ではありません。 VPNゲートウェイによって割り当てられたアドレスを使用するために、現在のVPNクライアントは、既にTCP接続のソースアドレスとして、例えば、インターフェースに割り当てられたアドレスのみを使用することができるように、ローカルな「仮想インタフェース」を作成します。 「インターフェース」のこの定義は、いくつかの特定の実装では、「インターフェース」と呼ぶものと必ずしも同じではないことに注意してください。
This section describes the limitations of the current IPv6 configuration mechanism and requirements for the new solution.
このセクションでは、現在のIPv6の設定メカニズムと新しいソリューションのための要件の制限事項について説明します。
In Figure 2, only a single IPv6 address (from a single prefix) is assigned. The specification does allow the client to include multiple INTERNAL_IP6_ADDRESS attributes in its request, but the gateway cannot assign more addresses than the client requested.
図2において、（単一プレフィックスから）のみを単一のIPv6アドレスが割り当てられます。仕様では、クライアントがリクエストで複数のINTERNAL_IP6_ADDRESS属性を含めることができませんが、ゲートウェイは、クライアントが要求した数より多くのアドレスを割り当てることはできません。
Multiple prefixes are useful for site renumbering, host-based site multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In all of these cases, the gateway has better information on how many different addresses (from different prefixes) the client should be assigned.
複数のプレフィックスは、サイトのリナンバリング、ホストベースのサイトマルチホーミング[SHIM6]、および一意のローカルIPv6アドレス[RFC4193]のために便利です。これらすべての場合では、ゲートウェイは、クライアントが割り当てられるべきである（異なるプレフィックスから）どのように多くの異なるアドレスのより良い情報を持っています。
The solution should support assigning addresses from multiple prefixes, without requiring the client to know beforehand how many prefixes are needed.
解決策は必要とされ、事前にどのように多くの接頭語を知っているクライアントを必要とせずに、複数のプレフィックスからアドレスを割り当てるサポートする必要があります。
The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 addresses of all types are assigned to interfaces, not nodes. [..] All interfaces are required to have at least one Link-Local unicast address".
IPv6のアドレス体系[IPv6Addr]「は、すべてのタイプのIPv6のアドレスはインタフェースではなく、ノードに割り当てられている。[..]すべてのインターフェイスは、少なくとも一つのリンクローカルユニキャストアドレスを持つことが必要である」ことを指定します。
Currently, the virtual interface created by IKEv2 configuration payloads does not have link-local addresses. This violates the requirements in [IPv6Addr] and prevents the use of protocols that require link-local addresses, such as [MLDv2] and [DHCPv6].
現在、IKEv2の設定ペイロードによって作成された仮想インターフェイスは、リンクローカルアドレスを持っていません。これは、[IPv6Addr]で要件に違反すると、このような[MLDv2の]と[DHCPv6の]のようにリンクローカルアドレスを必要とするプロトコルの使用を防止します。
The solution should assign link-local addresses to the virtual interfaces and allow them to be used for protocols between the VPN client and gateway.
溶液は、仮想インタフェースにリンクローカルアドレスを割り当て、それらは、VPNクライアントとゲートウェイとの間のプロトコルのために使用されることを可能にするべきです。
In the message exchange shown in Figure 2, the gateway chooses the interface ID used by the client. It is also possible for the client to request a specific interface ID; the gateway then chooses the prefix part.
図2に示すメッセージ交換では、ゲートウェイは、クライアントによって使用されるインターフェースIDを選択します。クライアントは、特定のインターフェイスIDを要求することも可能です。ゲートウェイは、その後プレフィックス部分を選択します。
This approach complicates the use of Cryptographically Generated Addresses (CGAs) [CGA]. With CGAs, the interface ID cannot be calculated before the prefix is known. The client could first obtain a non-CGA address to determine the prefix and then send a separate CFG_REQUEST to obtain a CGA address with the same prefix. However, this approach requires that the IKEv2 software component provide an interface to the component managing CGAs; an ugly implementation dependency that would be best avoided.
このアプローチは、暗号化生成アドレス（CGAs）[CGA]の使用を複雑にします。接頭辞が知られる前にCGAsでは、インタフェースIDを計算することができません。クライアントは、最初の接頭辞を決定し、その後、同じプレフィックスを持つCGAアドレスを取得するために別のCFG_REQUESTを送信するために非CGAアドレスを得ることができました。しかし、このアプローチは、IKEv2のソフトウェアコンポーネントがCGAs管理コンポーネントへのインターフェースを提供することを要求します。最高の回避されるだろう醜い実装依存。
Similar concerns apply to other cases where the client has some interest in what interface ID is being used, such as Hash-Based Addresses [HBA] and privacy addresses [RFC4941].
同様の懸念は、このようなハッシュベースアドレス[HBA]およびプライバシーアドレスなどのクライアントは、インタフェースIDが使用されているものの中にいくつかの関心を持っている他の例、[RFC4941]に適用されます。
Without CGAs and HBAs, VPN clients are not able to fully use IPv6 features such as [SHIM6] or enhanced Mobile IPv6 route optimization [RFC4866].
CGAsおよびHBAがなければ、VPNクライアントは完全な[SHIM6]または強化されたモバイルIPv6経路最適化[RFC4866]とIPv6機能を使用することができません。
The solution should allow the VPN client to easily obtain several addresses from a given prefix, where the interface IDs are selected by the client and may depend on the prefix.
溶液は、VPNクライアントが容易にインターフェースIDは、クライアントによって選択されたプレフィックスに依存しうる所与のプレフィックスから複数のアドレスを得ることが可能にすべきです。
Some VPN clients may want to share the VPN connection with other devices (e.g., from a cell phone to a laptop or vice versa) via some local area network connection (such as Wireless LAN or Bluetooth), if allowed by the security policy.
一部のVPNクライアントは、セキュリティポリシーで許可されていれば、（例えば無線LANやBluetoothなど）いくつかのローカルエリアネットワーク接続を介して他の機器（例えば、携帯電話からラップトップまたはその逆）とのVPN接続を共有することができます。
Quite obviously, sharing of VPN access requires more than one address (unless NAT is used). However, the current model where each address is requested separately is probably complex to integrate with a local area network that uses stateless address autoconfiguration [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client and advertising that to the local link (something resembling [NDProxy]) would be preferable. With DHCPv6 prefix delegation [RFC3633], even [NDProxy] and associated multi-link subnet issues would be avoided.
（NATが使用されていない限り）かなり明らかに、VPNアクセスの共有は、複数のアドレスが必要です。しかし、各アドレスを別々に要求されている現在のモデルはおそらく、ステートレスアドレス自動設定[AUTOCONF]を使用して、ローカルエリアネットワークとの統合が複雑です。このように、ローカルリンク（似た何か[NDProxy]）に望ましいであろうとVPNクライアントや広告のための全体の接頭辞を取得します。 DHCPv6のプレフィックス委譲[RFC3633]で、でも[NDProxy]と関連したマルチリンクサブネット上の問題は回避されるだろう。
The solution should support sharing the VPN access over a local area network connection when the other hosts are using stateless address autoconfiguration.
解決策は、他のホストがステートレスアドレス自動設定を使用しているローカルエリアネットワーク接続を介してVPNアクセスを共有してサポートする必要があります。
o The solution should avoid periodic messages over the VPN tunnel.
Oソリューションは、VPNトンネル経由で定期的にメッセージを避ける必要があります。
o Reauthentication should work, where the client can start a new IKE Security Association (SA) and continue using the same addresses as before.
O再認証は、クライアントが新しいIKEセキュリティアソシエーション（SA）を起動し、前と同じアドレスを使用し続けることができる場所、動作するはずです。
o There should be compatibility with other IPsec uses. Configuring a virtual IPv6 link (with addresses assigned in IKEv2) should not prevent the same peers from using IPsec/IKEv2 for other uses (with other addresses). In particular, the peers may have Security Policy Database (SPD) entries and Peer Authorization Database (PAD) Child SA Authorization Data entries that are not related to the virtual link; when a CHILD_SA is created, it should be unambiguous which entries are used.
O他のIPsecの使用との互換性があるはずです。 （IKEv2の中で割り当てられたアドレスを持つ）仮想IPv6リンクを設定する（他のアドレスを持つ）他の用途のためのIPsec / IKEv2のを使用してから、同じピアを妨げるべきではありません。具体的には、ピアは、セキュリティポリシーデータベース（SPD）エントリおよびピア認証データベース（PAD）仮想リンクに関連していない子供SA認証データ項目を有していてもよいです。 CHILD_SAが作成されたとき、エントリが使用されている明確なはずです。
o There should be compatibility with current IPv6 configuration. Although the current IPv6 mechanism is not widely implemented, new solutions should not preclude its use (e.g., by defining incompatible semantics for the existing payloads).
O現在のIPv6構成との互換性があるはずです。現在のIPv6メカニズムが広く実装されていないが、新しい溶液（例えば、既存のペイロードのための互換性のないセマンティクスを定義することによって）その使用を妨げてはなりません。
o The solution should have clean implementation dependencies. In particular, it should not require significant modifications to the core IPv6 stack (typically part of the operating system) or require the IKEv2 implementor to re-implement parts of the IPv6 stack (e.g., to have access or control to functionality that is currently not exposed by interfaces of the IPv6 stack).
Oソリューションは、きれいな実装の依存関係を持つ必要があります。特に、コアIPv6スタックに有意な変更を必要とはならない（オペレーティング・システムの典型的部分）、または現在ない機能へのアクセス又は制御を有するように、IPv6スタックの再実装部品（例えばするのIKEv2実装を必要としますIPv6スタックのインターフェースによって）露出されました。
o Re-use existing mechanisms as much as possible, as described in [IPConfig]. Appendix A describes the rationale of why this document nevertheless uses IKEv2 configuration payloads for configuring the addresses. However, Section 4.1 recommends using a DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses).
[IPCONFIG]に記載されているようにできるだけO再利用既存のメカニズム、。付録Aは、この文書は、それにもかかわらず、アドレスを設定するためのIKEv2構成ペイロードを使用する理由の根拠を説明しています。しかしながら、セクション4.1は、（DNSサーバアドレスなど）は、他の構成情報を取得するためのDHCPv6情報要求メッセージを使用することをお勧めします。
Mobile IPv6 already defines how it interacts with IPsec/IKEv2 [RFC4877], and the intent of this document is not to change that interaction in any way.
モバイルIPv6は、すでにそれはIPsecの/ IKEv2の[RFC4877]と対話する方法を定義し、この文書の意図はどのような方法でその相互作用を変更することはありません。
If the VPN client is assigned IPv6 address(es) from prefix(es) that are shared with other VPN clients, this results in some kind of multi-link subnet. [Multilink] describes issues associated with multi-link subnets and recommends that they be avoided.
VPNクライアントは、他のVPNクライアントと共有されている接頭語（ES）からのIPv6アドレスを割り当てられている場合、これはマルチリンクサブネットのいくつかの種類になります。 [マルチリンクはマルチリンクサブネットに関連する問題について説明し、それらを回避することをお勧めします。
The original 3GPP specifications for IPv6 assigned a single IPv6 address to each mobile phone, resembling current IKEv2 payloads. [RFC3314] describes the problems with this approach and caused 3GPP to change the specifications to assign unique /64 prefix(es) for each phone.
IPv6の元の3GPP仕様は、現在のIKEv2ペイロードに類似し、各携帯電話に単一のIPv6アドレスを割り当てます。 [RFC3314]は、このアプローチの問題を説明し、3GPPは、各電話機に固有の/ 64接頭語（es）を割り当てるために仕様を変更させます。
Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique prefixes.
同様の問題のため、IEEE 802.16のIPv6収束サブレイヤ[RFC5121]及びプロキシモバイルIPv6 [RFC5213]もユニークなプレフィックスを割り当てます。
During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be configured. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs). Typically, the client would also ask for the DHCPv6 server address; this is used only for configuration (such as DNS server addresses), not address assignment.
IKE_AUTH中に、クライアントは、新しい構成属性は、仮想リンクを要求INTERNAL_IP6_LINKは、設定する送信します。属性は、リンクローカルアドレス（他のアドレスは、他のインターフェイスIDを使用すること）のために、クライアントのインターフェイスIDが含まれています。一般的に、クライアントはDHCPv6サーバアドレスを求めるだろう。これは、割り当てに対処しない（例えば、DNSサーバアドレスなど）の設定のためにのみ使用されます。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
If the client has sent the INTERNAL_IP6_LINK configuration attribute, the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration attribute present in the request.
クライアントがINTERNAL_IP6_LINK構成属性を送信した場合、VPNゲートウェイは、任意のINTERNAL_IP6_ADDRESS構成が要求に存在属性を無視します。
The VPN gateway MUST choose for itself a link-local interface identifier different than the client's, i.e., accept the link-local interface identifier proposed by the client. In case the VPN gateway cannot accept the link-local interface identifier the client proposed, the VPN gateway MUST fail the IPv6 address assignment by including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message.
VPNゲートウェイは、自身のためにクライアントの異なるリンクローカルインターフェース識別子を選択し、すなわち、クライアントが提案したリンクローカルインタフェース識別子を受け入れなければなりません。場合にVPNゲートウェイは、クライアントが提案されているリンクローカルインターフェース識別子を受け入れることができない、VPNゲートウェイはINTERNAL_ADDRESS_FAILUREメッセージをNOTIFYペイロードを含めることによって、IPv6アドレスの割り当てに失敗しなければなりません。
The VPN gateway then replies with an INTERNAL_IP6_LINK configuration attribute that contains the IKEv2 Link ID (an identifier selected by the VPN gateway, treated as an opaque octet string by the client -- this will be used for reauthentication and CREATE_CHILD_SA messages), the gateway's link-local interface identifier, and zero or more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by the initiator are also narrowed to contain only the assigned prefixes and the client link-local address (FE80::<Client's Interface ID>) identifier.
VPNゲートウェイは、その後のIKEv2リンクIDが含まINTERNAL_IP6_LINK構成属性で応答（クライアントによる不透明なオクテット文字列として扱わVPNゲートウェイによって選択された識別子を、 - これは再認証とCREATE_CHILD_SAメッセージに使用される）、ゲートウェイのリンクを-localインタフェース識別子、およびゼロ以上INTERNAL_IP6_PREFIX属性。イニシエータによって提案されたトラフィックセレクタはまた、唯一の割り当てられたプレフィックスと、クライアントのリンクローカルアドレス（FE80 :: <クライアントのインターフェイスID>）の識別子を含むように狭くなっています。
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID,
IKEv2 Link ID)
INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) }
TSi = ((0, 0-65535,
FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>)
(0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535,
Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, the client can configure its link-local address (FE80::<Client's Interface ID>) and other non-link-local unicast addresses from the assigned prefixes (with any proper interface identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously assign the same prefixes to any other client and MUST NOT itself configure addresses from these prefixes. Thus, the client does not have to perform Duplicate Address Detection (DAD). (This approach is based on [IPv6PPP].)
この時点で、クライアントはそのリンクローカルアドレス（FE80 :: <クライアントのインターフェイスID>）および（任意の適切なインタフェース識別子[IPv6Addr]との）割り当てられたプレフィックスから他の非リンクローカルユニキャストアドレスを設定することができます。 VPNゲートウェイは、同時に他のクライアントに同じプレフィックスを割り当ててはならないと自身がこれらのプレフィックスからアドレスを設定してはなりません。したがって、クライアントは、重複アドレス検出（DAD）を実行する必要はありません。 （このアプローチは[IPv6PPP]に基づくものです。）
The prefixes remain valid through the lifetime of the IKE SA (and its continuations via rekeying). If the VPN gateway needs to remove a prefix it has previously assigned, or assign a new prefix, it can do so with reauthentication (either starting reauthentication itself or requesting the client to reauthenticate using [RFC4478]).
プレフィックスは（再入力を経由して、その継続）IKE SAのライフタイムを通じて有効なまま。 VPNゲートウェイは、それが以前に割り当てられたプレフィックスを削除するか、新しいプレフィックスを割り当てるために必要がある場合は、再認証（再認証自体を起動するか、[RFC4478]を使用して再認証をクライアントに要求のいずれか）で行うことができます。
The client also contacts the DHCPv6 server. This is the RECOMMENDED way to obtain additional configuration parameters (such as DNS server addresses), as it allows easier extensibility and more options (such as the domain search list for DNS).
クライアントも連絡DHCPv6サーバ。それが簡単に拡張して（例えばDNSのドメイン検索リストなど）より多くのオプションを可能にするように、これは、（例えばDNSサーバアドレスなど）追加の構成パラメータを取得することをお勧めの方法です。
When the client performs reauthentication (and wants to continue using the same "virtual link"), it includes the IKEv2 Link ID given by the gateway in the INTERNAL_IP6_LINK attribute.
クライアントが再認証を行う（と同じ「仮想リンク」を使用し続けたい）ときは、INTERNAL_IP6_LINK属性にゲートウェイによって与えられるIKEv2のリンクIDが含まれます。
CP(CFG_REQUEST) = { INTERNAL_IP6_LINK(Client's Link Local Interface ID, IKEv2 Link ID) INTERNAL_IP6_DHCP() } TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
CP（CFG_REQUEST）= {INTERNAL_IP6_LINK（クライアントのリンクローカルインタフェースID、IKEv2のリンクID）INTERNAL_IP6_DHCP（）}をTSi =（0、0-65535、0：0：0：0：0：0：0：0 - FFFF：FFFF ：FFFF：FFFF：FFFF：FFFF：FFFF：FFFF）TSR =（0、0-65535、0：0：0：0：0：0：0：0 - FFFF：FFFF：FFFF：FFFF：FFFF：FFFF： FFFF：FFFF） - >
At this point, the gateway MUST verify that the client is indeed allowed to use the link identified by the IKEv2 Link ID. The same situation occurs in [IKEv2] when the client wants to continue using the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration attribute. Typically, the gateway would use the Link ID to look up relevant local state and compare the authenticated peer identity of the IKE_SA with the local state.
この時点で、ゲートウェイは、クライアントが実際にIKEv2のリンクIDによって識別されたリンクを使用することが許可されていることを確かめなければなりません。同じ状況は、クライアントがINTERNAL_IP4_ADDRESSの構成属性と同じIPv4アドレスを引き続き使用したい場合、[IKEv2の]で発生します。通常、ゲートウェイは、該当する地域の状態を調べて、ローカル状態でIKE_SAの認証されたピアのアイデンティティを比較するために、リンクIDを使用します。
If the client is allowed to continue using this link, the gateway replies (see Section 4.1) with the same gateway's link-local interface ID and IKEv2 Link ID as used earlier and sends the IPv6 prefix(es) associated with this link. Usually, the IPv6 prefix(es) will also be the same as earlier, but this is not required.
クライアントは、このリンクを使用し続けることが許可されている場合は、ゲートウェイの返信は以前に使用したのと同じゲートウェイのリンクローカルインタフェースIDを持つとIKEv2のリンクID（セクション4.1を参照）、このリンクに関連付けられているIPv6プレフィックス（複数可）を送信します。通常、IPv6プレフィックス（複数可）も、以前と同じになりますが、これは必須ではありません。
If the client is not allowed to continue using this link, the gateway treats it as a request for a new virtual link, selects a different IKEv2 Link ID value, and replies as in Section 4.1.
クライアントは、このリンクを使用し続けることが許可されていない場合、ゲートウェイは、新しい仮想リンクのための要求として扱います異なるのIKEv2リンクID値を選択し、4.1節のように応答します。
When a CHILD_SA is created, the peers need to determine which SPD entries and PAD Child SA Authorization Data entries are used for this CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is simple: all the matching SPD entries and Child SA Authorization Data entries are related to the "virtual link" between the VPN client and the VPN gateway. However, if the same peers are also using IPsec/ IKEv2 for other uses (with addresses not assigned inside IKEv2), they would also have SPD entries and PAD Child SA Authorization Data that is not related to the virtual link.
CHILD_SAが作成されると、ピアはSPDエントリとパッド子供SA認証データエントリがこのCHILD_SAのために使用されているかを決定する必要があります。基本的なクライアントとVPNゲートウェイの用途では、状況は単純です：すべての一致するSPDエントリと子SA認可データエントリは、VPNクライアントとVPNゲートウェイの間の「仮想リンク」に関連しています。同じピアはまた、（IKEv2の内部で割り当てられていないアドレスで）他の用途のためのIPsec / IKEv2のを使用している場合は、彼らはまた、仮想リンクとは関係ありませんSPDエントリとパッド子供SA認証データを持っているでしょう。
If one of the peers requests a CHILD_SA and proposes traffic selectors covering everything (like in Figure 2), should those be narrowed to the prefixes configured with INTERNAL_IP6_PREFIX or to the other SPD/PAD entries? While some kind of heuristics are possible (see Appendix A for discussion), this document specifies an explicit solution:
ピアの1つは、CHILD_SAを要求し（図2のように）、すべてをカバーするトラフィックセレクタを提案している場合は、それらをINTERNAL_IP6_PREFIXで構成された接頭辞または他のSPD /パッドエントリを狭くする必要がありますか？ヒューリスティックのいくつかの種類が（議論については、付録Aを参照してください）可能であるが、この文書は、明示的なソリューションを指定します。
The peers MUST include a LINK_ID notification, containing the IKEv2 Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are related to the virtual link. The LINK_ID notification is not included in the CREATE_CHILD_SA response or when doing IKE_SA rekeying.
ピアは、仮想リンクに関連している（キー更新を含む）すべてのCREATE_CHILD_SA要求で、IKEv2のリンクIDを含む、LINK_ID通知を含まなければなりません。 LINK_ID通知はCREATE_CHILD_SA応答またはときIKE_SAの鍵の変更を行うには含まれていません。
Neighbor Discovery [IPv6ND] specifies the following mechanisms:
近隣探索[IPv6ND]は、以下のメカニズムを指定します。
Router Discovery, Prefix Discovery, Parameter Discovery, and address autoconfiguration are not used, as the necessary functionality is implemented in IKEv2.
必要な機能は、IKEv2の中に実装されているようにルータ発見、プレフィックスの発見、パラメータ検出、およびアドレス自動設定は、使用されません。
Address Resolution, Next-hop Determination, and Redirect are not used, as the virtual link does not have link-layer addresses and is a point-to-point link.
アドレス解決、ネクストホップの決定、およびリダイレクトは、仮想リンクは、リンク層アドレスを持っていないとして、使用およびポイントツーポイントリンクではありません。
Neighbor Unreachability Detection could be used but is a bit redundant given IKEv2 Dead Peer Detection.
近隣到達不能検出を使用することができるが、IKEv2のデッド・ピア検出所与のビットに冗長です。
Duplicate Address Detection is not needed because this is a point-to-point link, where the VPN gateway does not assign any addresses from the global unicast prefixes, and the link-local interface identifier is negotiated separately.
これは、VPNゲートウェイは、グローバルユニキャストプレフィクスから任意のアドレスを割り当てないポイントツーポイントリンクは、あるので、重複アドレス検出が必要とされない、およびリンクローカルインタフェース識別子は、別々にネゴシエートされます。
Duplicate Address Detection is not needed for global unicast addresses formed from the global unicast prefix(es) configured as part of the IKEv2 exchange, because this is a point-to-point link, where the VPN gateway does not assign any addresses from the global unicast prefixes. Duplicate Address Detection may be needed for link-local addresses, e.g., when the client configures a link-local address as per [RFC4941].
これは、VPNゲートウェイは、グローバルからの任意のアドレスを割り当てないポイントツーポイントリンクは、あるので、重複アドレス検出は、IKEv2の交換の一部として構成されているグローバルユニキャスト接頭語（es）から形成されたグローバルユニキャストアドレスのために必要とされませんユニキャストプレフィックス。クライアントは[RFC4941]あたりとしてリンクローカルアドレスを設定する際に重複アドレス検出は、例えば、リンクローカルアドレス、ために必要とすることができます。
Thus, Duplicate Address Detection MAY be skipped for global unicast addresses formed from the global unicast prefix(es) configured as part of the IKEv2 exchange. However, Duplicate Address Detection for link-local unicast addresses MUST be performed as required per some other specifications, e.g., [RFC4941].
従って、重複アドレス検出のIKEv2交換の一部として構成されているグローバルユニキャスト接頭語（es）から形成されたグローバルユニキャストアドレスのために省略してもよいです。例えば、いくつかの他の仕様ごとに[RFC4941]を必要に応じしかし、リンクローカルユニキャストアドレスの重複アドレス検出を実行しなければなりません。
The mechanism described in this document is not intended to be used at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, the VPN client MAY include attributes for both mechanisms in CFG_REQUEST. The capabilities and preferences of the VPN gateway will then determine which is used.
この文書で説明するメカニズムは、既存のINTERNAL_IP6_ADDRESS属性と同時に使用するものではありません。のみINTERNAL_IP6_ADDRESSを実装するゲートウェイとの互換性のために、VPNクライアントはCFG_REQUESTで両方のメカニズムの属性を含むかもしれません。 VPNゲートウェイの能力や嗜好は次に使用されるかを決定します。
All other attributes except INTERNAL_IP6_ADDRESS (and INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of [RFC4718] for discussion).
[IKEv2の]からINTERNAL_IP6_ADDRESS（およびINTENAL_ADDRESS_EXPIRY）を除く他のすべての属性はやや紛らわしい名前のINTERNAL_IP6_SUBNET（議論のためのセクション6.3 [RFC4718]を参照）を含め、有効なまま。
The INTERNAL_IP6_LINK configuration attribute is formatted as follows:
次のようにINTERNAL_IP6_LINK構成属性がフォーマットされます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Local |
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IKEv2 Link ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2].
O予約（1ビット） - [のIKEv2]参照。
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (17).
O型（15ビット）属性 - INTERNAL_IP6_LINK（17）。
o Length (2 octets) - Length in octets of the Value field (Link-Local Interface ID and IKEv2 Link ID); 8 or more.
O長（2つのオクテット） - Valueフィールドのオクテットの長さ（リンクローカルインタフェースIDとIKEv2のリンクID）。 8以上。
o Link-Local Interface ID (8 octets) - The Interface ID used for link-local address (by the party that sent this attribute).
Oリンク・ローカル・インタフェースID（8つのオクテット） - （この属性を送っ者による）リンクローカルアドレスに使用するインターフェイスのID。
o IKEv2 Link ID (variable length) - The Link ID (may be empty when the client does not yet know the Link ID). The Link ID is selected by the VPN gateway and is treated as an opaque octet string by the client.
OのIKEv2リンクID（可変長） - リンクIDは、（クライアントがまだリンクIDを知らないとき空の場合もあります）。リンクIDは、VPNゲートウェイによって選択され、クライアントによる不透明なオクテット文字列として扱われます。
The INTERNAL_IP6_PREFIX configuration attribute is formatted as follows:
次のようにINTERNAL_IP6_PREFIX構成属性がフォーマットされます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2].
O予約（1ビット） - [のIKEv2]参照。
o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (18).
O型（15ビット）属性 - INTERNAL_IP6_PREFIX（18）。
o Length (2 octets) - Length in octets of the Value field; in this case, 17.
O長（2つのオクテット） - Valueフィールドのオクテット単位の長さ。この場合、17インチ
o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. The low-order bits of the prefix field that are not part of the prefix MUST be set to zero by the sender and MUST be ignored by the receiver.
Oプレフィックス（16オクテット） - 仮想リンクに割り当てられたIPv6プレフィックス。接頭辞の一部ではないプレフィックスフィールドの下位ビットは送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
o Prefix Length (1 octet) - The length of the prefix in bits; usually 64.
Oプレフィックス長（1つのオクテット） - ビットでプレフィックスの長さ。通常は64。
The LINK_ID notification is included in CREATE_CHILD_SA requests to indicate that the SA being created is related to the virtual link. If this notification is not included, the CREATE_CHILD_SA requests are related to the real interface.
LINK_ID通知はSAが仮想リンクに関連して作成されていることを示すためにCREATE_CHILD_SA要求に含まれています。この通知が含まれていない場合は、CREATE_CHILD_SA要求は、実際のインタフェースに関連しています。
The Notify Message Type for LINK_ID is 16414. The Protocol ID and SPI Size fields are set to zero. The data associated with this notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK configuration attribute.
LINK_IDのための通知メッセージタイプは、プロトコルIDとSPIサイズフィールドがゼロに設定されている16414.です。この通知に関連付けられたデータは、IKEv2のリンクIDがINTERNAL_IP6_LINK構成属性に返されます。
This document defines two new IKEv2 configuration attributes, whose values have been allocated from the "IKEv2 Configuration Payload Attribute Types" namespace [IKEv2]:
この文書では、その値から割り当てられている「のIKEv2設定ペイロードタイプ属性」名前空間[IKEv2の2つの新しいのIKEv2構成属性を定義しています。
Multi-
Value Attribute Type Valued Length Reference
------ ---------------------- ------ ------------- ---------
17 INTERNAL_IP6_LINK NO 8 or more [RFC5739]
18 INTERNAL_IP6_PREFIX YES 17 octets [RFC5739]
This document also defines one new IKEv2 notification, whose value has been allocated from the "IKEv2 Notify Message Types - Status Types" namespace [IKEv2]:
：名前空間[IKEv2の] - この文書はまた、その値が「ステータスタイプのIKEv2は、メッセージタイプを通知する」から割り当てられている1つの新しいIKEv2の通知を、定義します
Value Notify Messages - Status Types Reference
------ ------------------------------- ---------
16414 LINK_ID [RFC5739]
This document does not create any new namespaces to be maintained by IANA.
この文書は、IANAによって維持されるすべての新しい名前空間を作成しません。
Since this document is an extension to IKEv2, the security considerations in [IKEv2] apply here as well.
このドキュメントはIKEv2のに拡張したものですので、[IKEv2の]のセキュリティの考慮事項はここにも適用されます。
The mechanism described in this document assigns each client a unique prefix, which makes using randomized interface identifiers [RFC4941] ineffective from a privacy point of view: the client is still uniquely identified by the prefix. In some environments, it may be preferable to assign a VPN client the same prefix each time a VPN connection is established; other environments may prefer assigning a different prefix every time for privacy reasons. (This is basically a similar trade-off as in Mobile IPv6 -- using the same Home Address forever is simpler than changing it often, but has privacy implications.)
本書で説明されたメカニズムは、各クライアントにビューのプライバシーの観点から無効ランダムインタフェース識別子[RFC4941]を使用して行うユニークなプレフィックスを割り当てる：クライアントがまだ一意のプレフィックスによって識別されます。いくつかの環境では、VPNクライアントにVPN接続が確立されるたびに同じプレフィックスを割り当てることが好ましいであろう。他の環境では異なる接頭辞にプライバシー上の理由のためにすべての時間を割り当てる好むかもしれません。 （これはモバイルIPv6のように基本的には同様のトレードオフである - 永遠に同じホームアドレスを使用すると、多くの場合、それを変更するよりも簡単ですが、プライバシーの意味を持ちます。）
The authors would like to thank Patrick Irwin, Tero Kivinen, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments.
作者は彼らの貴重なコメントのためにパトリック・アーウィン、TERO Kivinen、Chinhグエン、モハンパルタサラティ、ヤロンシェファー、Hemantシン、デーブターラー、Yinghzhe呉、およびファン趙に感謝したいと思います。
Many of the challenges associated with IPsec-protected "virtual interfaces" have been identified before, for example, in the context of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider
IPsecで保護された「仮想インタフェース」に関連付けられている課題の多くは、IPsec [RFC4891]、プロバイダとのIPv6型のIPv4トンネルを保護の文脈において、例えば、前に同定されています
Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 [RFC4877]. Some of the limitations of assigning a single IPv6 address were identified in [RFC3314].
プロビジョニングのVPN（[VLINK]、[RFC3884]）、及びモバイルIPv6 [RFC4877]。単一のIPv6アドレスを割り当てるの制限の一部は、[RFC3314]で同定されました。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Addr] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[AUTOCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[AUTOCONF]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2006.
[CGA]オーラ、T.、 "暗号的に生成されたアドレス（CGA）"、RFC 3972、2006年3月。
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
【のDHCPv6] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[HBA] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[HBA] Bagnulo、M.、 "ハッシュベースアドレス（HBA）"、RFC 5535、2009年6月。
[IPConfig] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009.
[IPCONFIG] Aboba、B.、ターラー、D.、アンダーソン、L.、およびS.チェシャー、 "インターネットホスト構成の原則"、RFC 5505、2009年5月。
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
【IPv6ND] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[IPv6PPP] Varada、S.、ハスキンズ、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[のMLDv2]ヴィーダ、R.とL.コスタ、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[MOBIKE] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[Multilink] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[マルチリンク]ターラー、D.、 "マルチリンクサブネットの問題"、RFC 4903、2007年6月。
[NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[NDProxy]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、RFC 4389、2006年4月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、RFC 3314、2002年9月、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456]パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、 "IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定"、RFC 3456、2003年1月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884]タッチ、J.、エッゲルト、L.、およびY.王、 "ダイナミックルーティングのためのIPsecトランスポートモードの使用"、RFC 3884、2004年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478]ニール、Y.、RFC 4478、2006年4月 "インターネットキーエクスチェンジ（IKEv2の）プロトコルで繰り返さ認証"。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P.およびP.ホフマン、 "IKEv2の明確化および実装のガイドライン"、RFC 4718、2006年10月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] Arkko、J.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のためのルート最適化の強化"、RFC 4866、2007年5月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[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.
[RFC5121]パティル、B.、夏、F.、Sarikaya、B.、チェ、JH。、およびS. Madanapalli、 "IEEE 802.16ネットワークの上のIPv6コンバージェンスサブレイヤを介したIPv6の送信"、RFC 5121、2008年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[SHIM6] Nordmarkと、E.およびM. Bagnulo、 "SHIM6：IPv6のレベル3マルチホーミングシム・プロトコル"、RFC 5533、2009年6月。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
[VLINK]ダフィー、M.、 "PPVPNsのIPsec保護された仮想リンクのための枠組み"、進歩、2002年10月の作業。
Appendix A. Design Rationale (Non-Normative)
付録A.デザイン理論的根拠（規範性なし）
This appendix describes some of the reasons why the solution in Section 4 was selected and lists some alternative designs that were considered but were ultimately rejected.
この付録では、第4節でソリューションを選択した理由のいくつかを説明し、考えられていたが、最終的に拒絶されたいくつかの代替設計を示しています。
Assigning a new IPv6 address to the client creates a new "virtual IPv6 interface" and "virtual link" between the client and the gateway. We will assume that the virtual link has the following properties:
クライアントに新たにIPv6アドレスを割り当てると、新しい「仮想IPv6インターフェース」と、クライアントとゲートウェイの間の「仮想リンク」を作成します。私たちは、仮想リンクは、以下の性質を持っていることを前提としています：
o The link and its interfaces are created and destroyed by the IKEv2 process.
Oリンクとそのインタフェースが作成され、IKEv2のプロセスによって破壊されます。
o The link is not an IPsec SA; at any time, there can be zero or more IPsec SAs covering traffic on this link.
Oリンクは、IPsec SAはありません。任意の時点で、このリンク上のトラフィックをカバーするゼロ以上のIPsecのSAが存在することができます。
o The link is not a single IKE SA; to support reauthentication, it must be possible to identify the same link in another IKE SA.
リンクは、単一のIKE SAはなく、O。再認証をサポートするために、他のIKE SA内の同じリンクを特定することが可能でなければなりません。
o Not all IPsec-protected traffic between the peers is necessarily related to the virtual link (although in the simplest VPN client-to-gateway scenario, it will be).
（最も簡単なVPNクライアントからゲートウェイへのシナリオでは、それはなりますが）Oピア間のすべてのIPsecで保護されたトラフィックは、必ずしも仮想リンクに関係しているわけではありません。
Given these assumptions and the goals described in Section 3, it seems that the most important design choices to be made are the following:
これらの仮定を考慮すると、第3節で説明した目標は、最も重要な設計上の選択を行うことが、次のされているようです。
o What link/subnet model is used; in other words, how relationships between VPN clients, IPv6 subnet prefixes, and link-local traffic (especially link-local multicast) are organized.
O何リンク/サブネットモデルが使用されています。つまり、VPNクライアント、IPv6サブネットプレフィックス、およびリンクローカルトラフィック（特にリンクローカルマルチキャスト）との間にどのように関係が整理されています。
o How information about the IPv6 prefix(es) is distributed from the gateway to the clients.
O IPv6プレフィックス（複数可）についての情報は、クライアントへのゲートウェイから配信される方法。
o How to ensure unique IPv6 addresses for each client and keep forwarding state up-to-date accordingly.
Oどのように各クライアントに一意のIPv6アドレスを確実かつ最新に応じて転送状態を維持します。
o How layer 3 access control is done; in other words, where the mechanisms for preventing address spoofing by clients are placed architecturally.
Oレイヤ3アクセス制御が行われている方法。換言すれば、クライアントがアドレススプーフィングを防止するための機構はアーキテクチャ配置されます。
Each of these is discussed next in turn.
これらのそれぞれが順番に次に説明されます。
A.1. Link Model
A.1。リンクモデル
There are at least three main choices for how to organize the relationships between VPN clients, IPv6 subnet prefixes, and link-local traffic:
VPNクライアント、IPv6サブネットプレフィックス、およびリンクローカルトラフィック間の関係を整理する方法については、少なくとも三つの主要な選択肢があります。
o Point-to-point link model: each VPN client is assigned one or more IPv6 prefixes. These prefixes are not shared with other clients, and there is no link-local traffic between different VPN clients connected to the same gateway.
Oポイントツーポイントリンクモデル：各VPNクライアントが1つのまたは複数のIPv6プレフィックスを割り当てられています。これらのプレフィックスは、他のクライアントと共有されていない、同じゲートウェイに接続された異なるVPNクライアントとの間にはリンクローカルトラフィックは存在しません。
o Multi-access link model: multiple VPN clients share the same IPv6 prefix. Link-local multicast packets sent by one VPN client will be received by other VPN clients (VPN gateway will forward the packets, possibly with Multicast Listener Discovery (MLD) snooping to remove unnecessary packets).
Oマルチアクセスリンクモデル：複数のVPNクライアントと同じIPv6プレフィックスを共有しています。 1つのVPNクライアントから送信されたリンクローカルマルチキャストパケットは、他のVPNクライアントによって受信されます（VPNゲートウェイは不要なパケットを削除するスヌーピングおそらくマルチキャストリスナ発見（MLD）と、パケットを転送します）。
o "Router aggregation" link model: one form of "multi-link" subnet [Multilink] where multiple VPN clients share the same IPv6 prefix. Link-local multicast will not be received by other VPN clients.
O「ルータ集約」リンクモデル：「マルチリンク」サブネットの一の形態【マルチ】複数のVPNクライアントは、同一のIPv6プレフィックスを共有する場合。リンクローカルマルチキャストは、他のVPNクライアントによって受信されることはありません。
In the multi-access link model, VPN clients who are idle (i.e., not currently sending or receiving application traffic) could receive significant amounts of multicast packets from other clients (depending on how many other clients are connected). This is especially undesirable when the clients are battery-powered such as a PDA that keeps the VPN connection to corporate intranet active 24/7. For this reason, using the multi-access link model was rejected.
マルチアクセスリンクモデルでは、アイドル状態になっているVPNクライアント（すなわち、現在のアプリケーショントラフィックを送信または受信していないが）他のクライアント（他のクライアントが接続されているどのように多く依存）からのマルチキャストパケットを大量に受け取ることができます。クライアントがバッテリ駆動しているとき、これは、このような24/7アクティブな企業イントラネットへのVPN接続を維持PDAとしては特に望ましくありません。このため、マルチアクセスリンクモデルが拒否されました使用して。
The configuration attributes specified in Section 4 use the point-to-point link model.
第4節で指定された構成属性は、ポイントツーポイントリンクモデルを使用します。
A.2. Distributing Prefix Information
A.2。プレフィックス情報の配布
Some types of addresses, such as CGAs, require knowledge about the prefix before an address can be generated. The prefix information could be distributed to clients in the following ways:
アドレスを生成することができます前に、このようなCGAsなどのアドレスの種類によっては、接頭語についての知識が必要です。プレフィックス情報は、次の方法でクライアントに配布することができます：
o IKEv2 messages (configuration payloads)
OのIKEv2メッセージ（設定ペイロード）
o Router Advertisement messages (sent over the IPsec tunnel)
Oルータ広告メッセージ（IPsecトンネルを介して送信されます）
o DHCPv6 messages (sent over the IPsec tunnel)
O（IPsecトンネルを介して送信される）のDHCPv6メッセージ
In Section 4, the prefix information is distributed in IKEv2 messages.
第4節では、プレフィックス情報は、IKEv2のメッセージで配布されています。
A.3. Unique Address Allocation
A.3。ユニークなアドレス割り当て
In the "multi-access" and "router aggregation" link models (where a single IPv6 prefix is shared between multiple VPN clients), mechanisms are needed to ensure that one VPN client does not use an address already used by some other client. Also, the VPN gateway has to know which client is using which addresses in order to correctly forward traffic.
「マルチアクセス」（単IPv6プレフィックスは、複数のVPNクライアント間で共有されている）「ルーター集約」リンクモデルでは、メカニズムは1つのVPNクライアントがすでにいくつかの他のクライアントが使用するアドレスを使用しないことを保証するために必要とされています。また、VPNゲートウェイが正しくトラフィックを転送するために、どのアドレス使用しているクライアント知っている必要があります。
The main choices seem to be the following:
主な選択肢は次のように見えます。
o Clients receive the address(es) they are allowed to use in IKEv2 messages (configuration payloads). In this case, keeping track of which client is using which address is trivial.
Oクライアントは、それらがIKEv2のメッセージ（設定ペイロード）で使用することが許可されているアドレス（複数可）を受け取ります。この場合は、自明でどのアドレス使用しているクライアントを追跡します。
o Clients receive the address(es) they are allowed to use in DHCPv6 messages sent over the IPsec tunnel. In case the DHCPv6 server is not integrated with the VPN gateway, the gateway may need to work as a relay agent to keep track of which client is using which address (and update its forwarding state accordingly).
Oクライアントは、それらがIPsecトンネル経由で送信されたDHCPv6メッセージで使用することを許可されているアドレス（複数可）を受け取ります。 DHCPv6サーバは、VPNゲートウェイと統合されていない場合には、ゲートウェイは、クライアントがそのアドレスを使用しているのを追跡する（それに応じて転送状態を更新）するリレーエージェントとして動作する必要があるかもしれません。
o Clients can use stateless address autoconfiguration to configure addresses and perform Duplicate Address Detection (DAD). This is easy to do in a multi-access link model and can be made to work with a router aggregation link model if the VPN gateway traps Neighbor Solicitation (NS) messages and spoofs Neighbor Advertisement (NA) replies. The gateway keeps track of which client is using which address (and updates its forwarding state accordingly) by trapping these NS/NA messages.
Oクライアントがアドレスを設定し、重複アドレス検出（DAD）を実行するためにステートレスアドレス自動設定を使用することができます。これは、マルチアクセスリンクモデルで行うのは簡単で、VPNゲートウェイは、近隣要請（NS）メッセージをトラップし、近隣広告（NA）応答を偽装場合、ルータ集約リンクモデルで動作させることができます。ゲートウェイは、これらのNS / NAメッセージをトラップしたアドレスを使用して（それに応じて転送状態を更新）されたクライアントを追跡します。
In the point-to-point link model, the client can simply use any address from the prefix, and the VPN gateway only needs to know which client is using which prefix in order to forward packets correctly.
ポイントツーポイントリンクモデルでは、クライアントは単にプレフィックスから任意のアドレスを使用することができ、およびVPNゲートウェイがのみ正しくパケットを転送するために、どのプレフィックスを使用しているクライアントを知っている必要があります。
A.4. Layer 3 Access Control
A.4。レイヤ3つのアクセス制御
It is almost always desirable to prevent one VPN client from sending packets with a source address that is used by another VPN client. In order to correctly forward packets destined to clients, the VPN gateway obviously has to know which client is using which address; the question is therefore where, architecturally, the mechanisms for ingress filtering are placed.
ほとんど常に他のVPNクライアントによって使用される送信元アドレスを持つパケットを送信してから1つのVPNクライアントを防止することが望ましいです。オーダー顧客宛に正しくパケットを転送では、VPNゲートウェイは明らかにされたアドレスを使用しているクライアント知っている必要があります。アーキテクチャ、イングレス・フィルタリングのための機構が配置されている場合、問題は、したがって、です。
o Layer 3 access control could be enforced by IPsec Security Association Database (SAD) / SPD; the addresses/prefixes assigned to a VPN client would be reflected in the traffic selectors used in IPsec Security Association and Security Policy Database entries, as negotiated in IKEv2.
Oレイヤ3アクセス・コントロールは、IPsecセキュリティアソシエーションデータベース（SAD）/ SPDによって強制することができ、 IKEv2ので交渉としてVPNクライアントに割り当てられたアドレス/プレフィックスは、IPsecのセキュリティアソシエーションに使用されるトラフィックセレクタとセキュリティポリシーデータベース項目に反映されるだろう。
o The ingress filtering capability could be placed outside IPsec; the traffic selectors in SAD/SPD entries would cover traffic that would be dropped later by ingress filtering.
Oイングレスフィルタリング機能は、IPsecの外側に配置することができます。 SAD / SPDエントリでトラフィックセレクタは、入力フィルタリングによって、後に廃棄されますトラフィックをカバーします。
The former approach is used by the current IPv4 solution and the mechanism specified in Section 4.
前者のアプローチは、現在のIPv4溶液及びセクション4で指定されたメカニズムによって使用されます。
A.5. Other Considerations
A.5。その他の考慮事項
VPN gateway state
VPNゲートウェイ状態
In some combinations of design choices, the amount of state information required in the VPN gateway depends not only on the number of clients but also on the number of addresses used by one client. With privacy addresses and potentially some uses of Cryptographically Generated Addresses (CGAs), a single client could have a large number of different addresses (especially if different privacy addresses are used with different destinations).
設計の選択肢のいくつかの組み合わせでは、VPNゲートウェイに必要な状態情報の量は、クライアントの数にも1つのクライアントによって使用されるアドレスの数に依存しないだけ。プライバシーアドレスと暗号的に生成されたアドレス（CGAs）の潜在的にいくつかの用途では、単一のクライアントは（異なるプライバシーアドレスが異なる宛先で使用されている場合は特に）の異なるアドレスの数が多いことができます。
Virtual link identifier
仮想リンク識別子
Reauthentication requires a way to uniquely identify the virtual link when a second IKE SA is created. Some possible alternatives are the IKE Security Parameter Indexes (SPIs) of the IKE SA where the virtual link was "created" (assuming we can't have multiple virtual links within the same IKE SA), a new identifier assigned when the link is created, or any unique prefix or address that remains assigned to the link for its entire lifetime. Section 4 specifies that the gateway assigns a new IKEv2 Link ID when the link is created. The client treats the Link ID as an opaque octet string; the gateway uses it to identify relevant local state when reauthentication is done.
再認証は、第二IKE SAが作成されたときに一意の仮想リンクを識別するための方法が必要です。リンクが作成されたときにいくつかの可能な選択肢は、新しい識別子が割り当てられている（私たちは同じIKE SA内に複数の仮想リンクを持つことができないと仮定して）仮想リンクは、「作成」されたIKE SAのIKEセキュリティパラメータインデックス（SPIの）ですその生涯のためのリンクに割り当てられたまま、または任意のユニークなプレフィックスまたはアドレス。第4節では、リンクが作成されたときに、ゲートウェイが新しいIKEv2のリンクIDを割り当てることを指定します。クライアントは、不透明なオクテット文字列としてリンクIDを扱います。ゲートウェイは、再認証が行われたときに、関連するローカル状態を識別するためにそれを使用します。
Note that the link is not uniquely identified by the IKE peer identities (because IDi is often a user identity that can be used on multiple hosts at the same time) or the outer IP addresses of the peers (due to NAT Traversal and [MOBIKE]).
NATトラバーサルおよび[MOBIKE]に（リンクが一意IKEピアのID（IDiとはしばしば、同時に複数のホストに使用することができるユーザのアイデンティティであるため）、またはピアの外部IPアドレスによって識別されないことに注意してください）。
Prefix lifetime
プレフィックス寿命
Prefixes could remain valid either for the lifetime of the IKE SA, until explicitly cancelled, or for an explicitly specified time. In Section 4, the prefixes remain valid for the lifetime of the IKE SA (and its continuations via rekeying but not via reauthentication). If necessary, the VPN gateway can thus add or remove prefixes by triggering reauthentication. It is assumed that adding or removing prefixes is a relatively rare situation, and thus this document does not specify more complex solutions (such as explicit prefix lifetimes or use of CFG_SET/CFG_ACK).
プレフィックスは、IKE SAのライフタイムのために、明示的にキャンセルされるまで、または明示的に指定された時間のためにどちらかの有効なままでした。第4節では、プレフィックスは（再認証を経て再入力ではなく経由して、その継続）IKE SAのライフタイムのための有効なまま。必要に応じて、VPNゲートウェイは、このように再認証をトリガすることによってプレフィックスを追加または削除することができます。接頭辞を追加または削除することは比較的まれな状況であると仮定されるので、この文書は、（明示的なプレフィックスの寿命やCFG_SET / CFG_ACKの使用など）、より複雑なソリューションを指定していません。
Compatibility with other IPsec uses
他のIPsecの使用との互換性
Compatibility with other IPsec uses probably requires that when a CHILD_SA is created, both peers can determine whether the CHILD_SA applies to the virtual interface (at the end of the virtual link) or the real interfaces over which IKEv2 messages are being sent. This is required to select the correct SPD to be used for traffic-selector narrowing and SA authorization in general.
他のIPsecとの互換性は、おそらく使用CHILD_SAが作成されるときに、両方のピアがCHILD_SAが又はのIKEv2メッセージが送信されてその上に実際のインターフェイス（仮想リンクの終了時に）仮想インタフェースに適用されるかどうかを判定することができることを必要とします。これは、一般的には、トラフィックセレクタの狭小化とSAの認証に使用する正しいSPDを選択する必要があります。
One straight-forward solution is to add an extra payload to CREATE_CHILD_SA requests, containing the virtual link identifier. Requests not containing this payload would refer to the real link (over which IKEv2 messages are being sent).
ワンストレートフォワードソリューションは、仮想リンクの識別子を含む、CREATE_CHILD_SA要求に余分なペイロードを追加することです。このペイロードを含まない要求は（IKEv2のメッセージが送信されてその上に）実際のリンクを参照することになります。
Another solution is to require that the peer requesting a CHILD_SA proposes traffic selectors that identify the link. For example, if TSi includes the peer's "outer" IP address, it's probably related to the real interface, not the virtual one. Or if TSi includes any of the prefixes assigned by the gateway (or the link-local or multicast prefix), it is probably related to the virtual interface.
別の解決策は、CHILD_SAを要求ピアがリンクを識別するトラフィックセレクタを提案することを要求することです。 TSiは、ピアの「外側」IPアドレスが含まれている場合たとえば、それはおそらく本当のインターフェースではなく、仮想1に関連しています。 TSiゲートウェイ（又はリンクローカルまたはマルチキャストプレフィックス）によって割り当てられたプレフィックスのいずれかが含まれている場合、または、それは、おそらく仮想インタフェースに関連しています。
These heuristics can work in many situations but have proved inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891], Provider Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 [RFC4877]. Thus, Section 4 includes the virtual link identifier in all CREATE_CHILD_SA requests that apply to the virtual interface.
これらのヒューリスティックは、多くの状況で動作することができるが、IPv6のインIPv4トンネル[RFC4891]、プロバイダプロビジョニングのVPN（[VLINK]、[RFC3884]）、及びモバイルIPv6 [RFC4877]の文脈では不十分であることが判明しました。したがって、第4節では、仮想インターフェイスに適用されるすべてのCREATE_CHILD_SA要求における仮想リンク識別子を含みます。
Example of other IPsec uses:
他のIPsecの例を使用しています：
If a VPN gateway receives a CREATE_CHILD_SA request associated with a physical Ethernet interface, requesting an SA for (TSi=FE80::something, dst=*), it would typically reject the request (or, in other words, narrow it to an empty set) because it doesn't have SPD/PAD entries that would allow joe.user@example.com to request such CHILD_SAs.
VPNゲートウェイは（TSI = FE80 ::何か、DST = *）のためのSAを要求し、物理イーサネットインターフェイスに関連付けられたCREATE_CHILD_SA要求を受信した場合、それは、典型的には、要求を拒否（または、言い換えれば、空にそれを狭めることになりますそれは、このようなのCHILD_SAsを要求するjoe.user@example.comを可能にするSPD / PADのエントリを持っていないため）を設定します。
(However, it might have SPD/PAD entries that would allow "neighboring-router.example.com" to create such SAs to protect, for example, some routing protocol that uses link-local addresses.)
（ただし、それは、例えば、保護するために、このようなSAを作成するために、リンクローカルアドレスを使用して、いくつかのルーティングプロトコルを「neighboring-router.example.com」を可能とするSPD / PADのエントリを持っているかもしれません。）
However, the virtual interface created when joe.user@example.com authenticated and sent INTERNAL_IP6_LINK would have a different SPD/PAD, which would allow joe.user@example.com to create this SA.
しかし、仮想インターフェイスはjoe.user@example.com認証されたときに作成され、INTERNAL_IP6_LINKは、このSAを作成するためにjoe.user@example.comを可能にするさまざまなSPD /パッドを、持っているでしょう送りました。
A.6. Alternative Solution Sketches
A.6。代替ソリューションのスケッチ
A.6.1. Version -00 Sketch
A.6.1。バージョン-00スケッチ
The -00 version of this document contained the following solution sketch, which is basically a combination of (1) a point-to-point link model, (2) prefix information distributed in Neighbor Advertisements, and (3) access control enforced outside IPsec.
この文書の-00バージョンは、基本的には（1）ポイントツーポイントリンクモデルの組み合わせである以下の溶液スケッチ、近隣広告に分布（2）プレフィックス情報を含有し、（3）アクセス制御は、IPsecの外側に適用します。
1. During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs).
1. IKE_AUTH中に、クライアントは、作成する仮想リンクを要求し、新しい構成属性、INTERNAL_IP6_LINKを送信します。属性は、リンクローカルアドレス（他のアドレスは、他のインターフェイスIDを使用すること）のために、クライアントのインターフェイスIDが含まれています。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own link-local interface ID (which has to be different from the client's) and an IKEv2 Link ID (which will be used for reauthentication).
VPNゲートウェイは、独自のリンクローカルインタフェースID（クライアントの異なるされなければならない）と（再認証に使用される）のIKEv2リンクIDで応答します。
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the link-local addresses.
この時点で、両方のピアは、リンクローカルアドレスを持つ仮想インターフェイスを設定します。
2. The next step is IPv6 stateless address autoconfiguration, that is, Router Solicitation and Router Advertisement messages sent over the IPsec SA.
2.次のステップは、つまり、ルータ要請およびルータ広告メッセージは、IPsecのSAを介して送信されたIPv6ステートレスアドレス自動設定、です。
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: src=FE80::<Gateway's Interface ID> dst=FF02:0:0:0:0:0:0:1, Prefix1, [Prefix2...])
< - ESP（ルータアドバタイズメント：SRC = FE80 :: <GatewayのインタフェースID> DST = FF02：0：0：0：0：0：0：1、PREFIX1、[PREFIX2 ...]）
After receiving the Router Advertisement, the client can configure unicast addresses from the advertised prefixes, using any proper interface ID. The VPN gateway does not simultaneously assign the same prefixes to any other client and does not itself configure addresses from these prefixes. Thus, the client does not have to perform Duplicate Address Detection (DAD).
ルータ通知を受け取った後、クライアントは、任意の適切なインタフェースIDを使用して、広告を出してプレフィックスからユニキャストアドレスを設定することができます。 VPNゲートウェイは、同時に他のクライアントに同じプレフィックスを割り当てていないと自身がこれらのプレフィックスからアドレスを設定していません。したがって、クライアントは、重複アドレス検出（DAD）を実行する必要はありません。
3. Reauthentication works basically the same way as in Section 4; the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute.
3.再認証は、セクション4と基本的に同じように動作します。クライアントはINTERNAL_IP6_LINK属性にIKEv2のリンクIDが含まれます。
4. Creating and rekeying IPsec SAs works basically the same way as in Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA requests that are related to the virtual link.
4.作成とIPsec SAは、基本的には4.3節と同様に動作し再入力します。クライアントは、仮想リンクに関連するものをCHILD_SA要求でIKEv2のリンクIDが含まれます。
Comments: This was changed in the -01 version of this document based on feedback from VPN vendors; while the solution looks nice on paper, it is claimed to be unnecessarily complex to implement when the IKE implementation and IPv6 stack are from different companies. Furthermore, enforcing access control outside IPsec is a significant architectural change compared to current IPv4 solutions.
コメント：これは、VPNベンダーからのフィードバックに基づいて、このドキュメントの-01バージョンで変更されました。ソリューションは、紙の上に素敵に見えますが、IKEの実装とIPv6スタックが別の会社からあるとき、実装が不必要に複雑であると主張されています。また、IPsecの外部からのアクセス制御を施行すると、現在のIPv4ソリューションと比較して有意なアーキテクチャの変更です。
A.6.2. Router Aggregation Sketch #1
A.6.2。ルータ集約スケッチ＃1
Hemant Singh helped sketch the following solution during the IETF 70 meeting in Vancouver. It combines (1) the router aggregation link model, (2) prefix information distributed in IKEv2 messages, (3) unique address allocation with stateless address autoconfiguration (with VPN gateway trapping NS messages and spoofing NA replies), and (4) access control enforced (partly) outside IPsec.
HemantシンはバンクーバーのIETF 70会議中に、以下のソリューションをスケッチ助けました。これは（NSメッセージとスプーフィングNAが応答を捕捉VPNゲートウェイと）のIKEv2メッセージで配布（1）ルーターの集約リンクモデル、（2）プレフィックス情報、ステートレスアドレス自動設定（3）固有のアドレス割り当て、及び（4）アクセス制御を組み合わせIPsecの外（一部）施行。
1. During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs).
1. IKE_AUTH中に、クライアントは、作成する仮想リンクを要求し、新しい構成属性、INTERNAL_IP6_LINKを送信します。属性は、リンクローカルアドレス（他のアドレスは、他のインターフェイスIDを使用すること）のために、クライアントのインターフェイスIDが含まれています。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's), an IKEv2 Link ID (which will be used for reauthentication and CREATE_CHILD_SA messages), and zero or more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by the initiator are also narrowed to contain only the assigned prefixes (and the link-local prefix).
VPNゲートウェイは、独自のリンクローカル（クライアントのとは異なることがあります）インターフェイスのID、（再認証とCREATE_CHILD_SAメッセージに使用されます）IKEv2のリンクID、およびゼロ以上INTERNAL_IP6_PREFIX属性で応答します。イニシエータによって提案されたトラフィックセレクタはまた、唯一の割り当てプレフィックス（およびリンクローカルプレフィックス）を含むように狭くなっています。
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...] }
TSi = ((0, 0-65535,
FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>)
(0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535,
Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2. The client now configures tentative unicast addresses from the prefixes given by the gateway, and performs Duplicate Address Detection (DAD) for them.
2.クライアントは、ゲートウェイによって与えられたプレフィックスから暫定ユニキャストアドレスを構成し、それらのためにアドレス検出（DAD）を複製行います。
The Neighbor Solicitation messages are processed by the VPN
gateway; if the target address is already in use by some other
VPN client, the gateway replies with a Neighbor Advertisement.
If the target address is not already in use, the VPN gateway
notes that it is now being used by this client and updates its
forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard processing of NS messages (which are used to update the gateway's forwarding state), and performing access control partly outside IPsec.
コメント：この解決策の主な欠点は、（ゲートウェイの転送状態を更新するために使用される）NSメッセージの非標準的な処理であり、部分的にIPsecの外部からのアクセス制御を行います。
A.6.3. Router Aggregation Sketch #2
A.6.3。ルータ集約スケッチ＃2
This is basically similar to the version -00 sketch described above but uses the router aggregation link model. In other words, it combines (1) the router aggregation link model, (2) prefix information distributed in Neighbor Advertisements, (3) unique address allocation with stateless address autoconfiguration (with the VPN gateway trapping NS messages and spoofing NA replies), and (4) access control enforced outside IPsec.
これは基本的に上述したバージョン-00スケッチに類似しているが、ルーターの集約リンクモデルを使用します。換言すれば、（1）ルーターの集約リンクモデル、近隣広告に分布（2）プレフィックス情報（VPNゲートウェイは、NAが返信NSメッセージとスプーフィングをトラップ付き）ステートレスアドレス自動設定（3）固有のアドレス割り当てを組み合わせ、そしてIPsecの外に強制（4）アクセス制御。
1. During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs).
1. IKE_AUTH中に、クライアントは、作成する仮想リンクを要求し、新しい構成属性、INTERNAL_IP6_LINKを送信します。属性は、リンクローカルアドレス（他のアドレスは、他のインターフェイスIDを使用すること）のために、クライアントのインターフェイスIDが含まれています。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's) and an IKEv2 Link ID (which will be used for reauthentication).
VPNゲートウェイは、独自のリンクローカル（クライアントのとは異なることがあります）インターフェイスのIDと（再認証のために使用されます）のIKEv2リンクIDで応答します。
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the link-local addresses.
この時点で、両方のピアは、リンクローカルアドレスを持つ仮想インターフェイスを設定します。
2. The next step is IPv6 stateless address autoconfiguration, that is, Router Solicitation and Router Advertisement messages sent over the IPsec SA.
2.次のステップは、つまり、ルータ要請およびルータ広告メッセージは、IPsecのSAを介して送信されたIPv6ステートレスアドレス自動設定、です。
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: src=FE80::<Gateway's Interface ID> dst=FF02:0:0:0:0:0:0:1, Prefix1, [Prefix2...])
< - ESP（ルータアドバタイズメント：SRC = FE80 :: <GatewayのインタフェースID> DST = FF02：0：0：0：0：0：0：1、PREFIX1、[PREFIX2 ...]）
3. The client now configures tentative unicast addresses from the prefixes given by the gateway and performs Duplicate Address Detection (DAD) for them.
3.クライアントは、ゲートウェイによって与えられたプレフィックスから暫定ユニキャストアドレスを設定し、それらの重複アドレス検出（DAD）を行います。
The Neighbor Solicitation messages are processed by the VPN
gateway; if the target address is already in use by some other
VPN client, the gateway replies with a Neighbor Advertisement.
If the target address is not already in use, the VPN gateway
notes that it is now being used by this client and updates its
forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard processing of NS messages (which are used to update the gateway's forwarding state) and performing access control outside IPsec.
コメント：この解決策の主な欠点は、非標準（ゲートウェイの転送状態を更新するために使用される）NSメッセージの処理およびIPsec外部アクセス制御を行っています。
A.6.4. IPv4-Like Sketch
A.6.4。 IPv4の様スケッチ
This sketch resembles the current IPv4 configuration payloads and combines (1) the router aggregation link model, (2) prefix information distributed in IKEv2 messages, (3) unique address allocation with IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD.
このスケッチは、現在のIPv4設定ペイロードとコンバイン（1）ルーターの集約リンクモデルのIKEv2メッセージで配布（2）プレフィックス情報、のIKEv2メッセージ（3）固有のアドレス割り当て、およびIPsec SADによって強制（4）アクセス制御/似ていますSPD。
1. During IKE_AUTH, the client sends a new configuration attribute, INTERNAL_IP6_LINK, which requests a virtual link to be created. The attribute contains the client's interface ID for the link-local address (other addresses may use other interface IDs).
1. IKE_AUTH中に、クライアントは、作成する仮想リンクを要求し、新しい構成属性、INTERNAL_IP6_LINKを送信します。属性は、リンクローカルアドレス（他のアドレスは、他のインターフェイスIDを使用すること）のために、クライアントのインターフェイスIDが含まれています。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The VPN gateway replies with its own Link-Local Interface ID (which has to be different from the client's), an IKEv2 Link ID (which will be used for reauthentication and CREATE_CHILD_SA messages), and zero or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains one address from a particular prefix.
VPNゲートウェイは、独自のリンクローカルインタフェースID（クライアントの異なるように持っている）、（再認証とCREATE_CHILD_SAメッセージに使用されます）IKEv2のリンクID、およびゼロ以上INTERNAL_IP6_ADDRESS2属性で応答します。各属性は、特定の接頭辞から一つのアドレスが含まれています。
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1),
[INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...],
TSi = ((0, 0-65535,
FE80::<Client's Link-Local Interface ID> -
FE80::<Client's Link-Local Interface ID>)
(0, 0-65535,
Prefix1::<Client's Interface ID1> -
Prefix1::<Client's Interface ID1>),
[(0, 0-65535,
Prefix2::<Client's Interface ID2> -
Prefix2::<Client's Interface ID2>), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
Since the VPN gateway keeps track of address uniqueness, there is no need to perform Duplicate Address Detection.
VPNゲートウェイは、アドレスの一意性を追跡しているので、重複アドレス検出を実行する必要はありません。
2. If the client wants additional addresses later (for example, with a specific interface ID), it requests them in a separate CREATE_CHILD_SA exchange. For example:
2.クライアントは、（例えば、特定のインターフェイスIDで）後に、追加のアドレスを望んでいるなら、それは別のCREATE_CHILD_SA交換でそれらを要求します。例えば：
CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) }
TSi = (0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF>),
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
If the requested address is not currently in use by some other client, the VPN gateway simply returns the same address and the appropriately narrowed traffic selectors.
要求されたアドレスが他のクライアントによって現在使用されていない場合は、VPNゲートウェイは、単純に同じアドレスと適切狭くトラフィックセレクタを返します。
CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID3) }
TSi = ((0, 0-65535,
Prefix1::<Client's Interface ID3> -
Prefix1::<Client's Interface ID3>),
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
Comments: The main advantage of this solution is that it's quite close to the current IPv4 way of doing things. By adding explicit link creation (with Link ID for reauthentication/SPD selection and link-local addresses) and slightly changing the semantics (and also name) of the INTERNAL_IP6_ADDRESS attribute (which can return more attributes than was asked), we get much of the needed functionality.
コメント：このソリューションの主な利点は、それが物事の現在のIPv4の方法に非常に近いということです。 （再認証/ SPDの選択とリンクローカルアドレスのリンクIDで）明示的なリンク作成を追加すると、わずかに（頼まれたよりも多くの属性を返すことができます）INTERNAL_IP6_ADDRESS属性の（名前もと）セマンティクスを変更することにより、我々は多くの取得します必要な機能。
The biggest disadvantages are probably potentially complex implementation dependency for interface ID selection (see Section 3.3) and the multi-link subnet model.
最大の欠点は、おそらく、インタフェースIDの選択（3.3節を参照）、マルチリンクサブネットモデルのための潜在的に複雑な実装依存です。
A.6.5. Sketch Based on
A.6.5。スケッチに基づきます
For completeness: a solution modeled after [RFC3456] would combine (1) the router aggregation link model, (2) prefix information distribution and unique address allocation with DHCPv6, and (3) access control enforced by IPsec SAD/SPD.
完全性のために：をモデルにした溶液[RFC3456]（1）ルーターの集約リンクモデル、（2）プレフィックス情報分布およびDHCPv6のユニークなアドレス割り当て、およびIPsec SAD / SPDによって実施（3）アクセス制御を組み合わせることであろう。
Appendix B. Evaluation (Non-Normative)
付録B.評価（規範性なし）
Section 3 describes the goals and requirements for IPv6 configuration in IKEv2. This appendix briefly summarizes how the solution specified in Sections 4 and 5 meets these goals.
第3節では、IKEv2の中にIPv6構成のための目標と要件について説明します。この付録では、簡単にセクション4および5で指定されたソリューションは、これらの目標をどのように満たしているかをまとめたものです。
o (3.1) Assigning addresses from multiple prefixes is supported, without requiring the client to know beforehand how many prefixes are needed.
O（3.1）複数のプレフィックスからアドレスを割り当てることは必要とされ、事前にどのように多くの接頭語を知っているクライアントを必要とせずに、サポートされています。
o (3.2) Link-local addresses are assigned and can be used for protocols between the VPN client and gateway.
O（3.2）リンクローカルアドレスが割り当てられ、VPNクライアントとゲートウェイとの間のプロトコルのために使用することができます。
o (3.3) The entire prefix is assigned to a single client, so the client can freely select any number of interface IDs (which may depend on the prefix).
クライアントが自由に（プレフィックスに依存し得る）インターフェースIDの任意の数を選択できるようにO（3.3）全体のプレフィックスは、単一のクライアントに割り当てられています。
o (3.4) This document does not specify how the VPN client would share the VPN connection with other devices. However, since the entire prefix is assigned to a single client, the client could further assign addresses from it without requiring coordination with the VPN gateway.
O（3.4）このドキュメントでは、VPNクライアントは、他のデバイスとのVPN接続を共有する方法を指定しません。全体プレフィックスが単一のクライアントに割り当てられているので、クライアントは、さらに、VPNゲートウェイとの連携を必要とせず、それからアドレスを割り当てることができました。
o (3.5) The solution does not add any new periodic messages over the VPN tunnel.
O（3.5）ソリューションは、VPNトンネル経由で任意の新しい定期的にメッセージを追加しません。
o (3.5) Reauthentication works (see Section 4.2).
O（3.5）再認証は（4.2節を参照）動作します。
o (3.5) The solution is compatible with other IPsec uses since the LINK_ID notification makes it unambiguous which CHILD_SAs are related to the virtual link and which are not (see Sections 4.3 and 5.3).
LINK_ID通知が仮想リンクに関連していること明白れるのCHILD_SAsと（セクション4.3および5.3を参照）されていないことができるので、O（3.5）溶液は、他のIPsecと互換性がある使用法。
o (3.5) The new mechanisms do not prevent the VPN client and/or gateway from implementing the INTERNAL_IP6_ADDRESS configuration attribute as well; however, the two mechanisms are not intended to be used simultaneously (see Section 4.5).
O（3.5）ならびにINTERNAL_IP6_ADDRESS構成属性を実装からVPNクライアント及び/またはゲートウェイを妨げない新しいメカニズム。しかし、2つの機構が同時に使用されることが意図されていない（4.5節を参照）。
o (3.5) Implementation dependencies are, obviously, implementation dependent (and their cleanliness somewhat subjective). Possible drawbacks of some alternative solutions are discussed in Appendix A.6.
O（3.5）実施の依存関係は、明らかに、実装依存（およびその清潔やや主観）です。いくつかの代替ソリューションの可能性のある欠点は、付録A.6で議論されています。
o (3.5) The mechanism for configuring the prefixes (configuration payloads) is specific to IKEv2, for reasons described in Appendix A. However, Section 4.1 recommends using DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses).
O（3.5）プレフィックス（構成ペイロード）を構成するための機構は、IKEv2のに特異的である、しかし、付録Aで説明する理由のために、セクション4.1は、（DNSサーバアドレスなど）は、他の構成情報を取得するためのDHCPv6情報要求メッセージを使用することをお勧めします。
Authors' Addresses
著者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Julien Laganier QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ジュリアンLaganier QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121 USA
Phone: +1 858 658 3538 EMail: julienl@qualcomm.com
電話：+1 858 658 3538 Eメール：julienl@qualcomm.com
Cheryl Madson Cisco Systems, Inc. 510 MacCarthy Drive Milpitas, CA USA
シェリルMadsonシスコシステムズ社510マッカーシードライブミルピタス、CA USA
EMail: cmadson@cisco.com
メールアドレス：cmadson@cisco.com