[要約] RFC 5739は、IKEv2でのIPv6構成に関するガイドラインであり、IPv6アドレスの割り当てやトンネリングの設定方法を提供しています。このRFCの目的は、IKEv2を使用してIPv6ネットワークをセキュアに構成するための手順を定義することです。
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".
Internet Key Exchange Protocolバージョン2（IKEV2）がリモートVPNアクセス（クライアントからVPNゲートウェイ）に使用されると、GatewayはIKEV2構成のペイロードを使用して内部ネットワークからIPアドレスをクライアントに割り当てます。RFC 4306で指定された構成ペイロードは、IPv4ではうまく機能しますが、IPv6の特定の機能を使用することを困難にします。このドキュメントは、VPNゲートウェイがIPv6プレフィックスをクライアントに割り当てることができるIKEV2の新しい構成属性を指定し、IPv6のすべての機能をクライアントゲートウェイの「仮想リンク」で使用できるようにします。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc5739.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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、ker、nr、[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 { 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 { 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".
このドキュメントは、VPNゲートウェイがIPv6プレフィックスをクライアントに割り当てることができるIKEV2の新しい構成属性を指定し、IPv6のすべての機能をクライアントゲートウェイの「仮想リンク」で使用できるようにします。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
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アドレス（ES）を使用する方法を説明するときに「仮想インターフェイス」という用語を使用します。既存のIPSECドキュメントはこの用語を使用していませんが、新しい概念ではありません。VPNゲートウェイによって割り当てられたアドレスを使用するために、現在のVPNクライアントは、インターフェイスに割り当てられたアドレスのみを使用できるため、TCP接続のソースアドレスとして使用できるため、現在のVPNクライアントはすでにローカル「仮想インターフェイス」を作成します。この「インターフェイス」の定義は、特定の実装が「インターフェイス」と呼ぶものと必ずしも同一ではないことに注意してください。
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アドレス（単一のプレフィックスから）のみが割り当てられています。この仕様により、クライアントは要求に複数の内部_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.
複数の接頭辞は、サイトの変更、ホストベースのサイトMultihoming [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クライアントとGateway間のプロトコルに使用できるようにする必要があります。
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.
このアプローチは、暗号化されたアドレス（CGA）[CGA]の使用を複雑にします。CGASを使用すると、プレフィックスがわかる前にインターフェイスIDを計算することはできません。クライアントは最初に非CGAアドレスを取得してプレフィックスを決定し、次に別のCFG_REQUESTを送信して、同じプレフィックスを持つCGAアドレスを取得できます。ただし、このアプローチでは、IKEV2ソフトウェアコンポーネントがCGAを管理するコンポーネントにインターフェイスを提供する必要があります。避けるのが最善の醜い実装依存関係。
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]やプライバシーアドレス[RFC4941]など、クライアントが使用されているインターフェイスIDに何らかの関心を持っている他のケースにも適用されます。
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とHBASがなければ、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.
明らかに、VPNアクセスの共有には複数のアドレスが必要です（NATが使用されない限り）。ただし、各アドレスが個別に要求される現在のモデルは、おそらくStatelessアドレスAutoconfiguration [AutoCONF]を使用するローカルエリアネットワークと統合するために複雑です。したがって、VPNクライアントのプレフィックス全体を取得し、ローカルリンク（[ndproxy]に似たもの）にそれを宣伝することが望ましいでしょう。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.
このソリューションは、他のホストがStatelessアドレス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の使用と互換性があるはずです。仮想IPv6リンク（IKEV2で割り当てられたアドレスを含む）の構成は、同じピアが他の用途にIPSEC/IKEV2を使用することを防ぐべきではありません（他のアドレス付き）。特に、ピアには、仮想リンクに関係のない子SA承認データエントリ（PAD）のセキュリティポリシーデータベース（SPD）エントリとピア認証データベース（PAD）がある場合があります。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スタック（通常はオペレーティングシステムの一部）の大幅な変更を必要としないか、IKEV2実装者にIPv6スタックの部分を再実装する必要があります（たとえば、現在ではない機能にアクセスまたは制御するために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).
o [IPConfig]に記載されているように、既存のメカニズムを可能な限り再利用します。付録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アドレス（ES）が割り当てられている場合、これにより何らかのマルチリンクサブネットが得られます。[MultiLink]は、マルチリンクサブネットに関連する問題を説明し、回避することを推奨しています。
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 Convergence Sublayer [RFC5121]およびProxy Mobile 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ゲートウェイがクライアントが提案したLink-Localインターフェイス識別子を受け入れられない場合、VPNゲートウェイは、Internal_Address_Failureメッセージに通知ペイロードを含めることにより、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（クライアントによって不透明なオクテット文字列として扱われるIKEV2リンクID（VPNゲートウェイによって選択された識別子）を含むInternal_IP6_Link構成属性で応答します。-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属性のGATEWAYで指定された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) -->
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 Configuration属性を使用して同じIPv4アドレスを使用し続けたい場合、[IKEV2]で同じ状況が発生します。通常、ゲートウェイはリンクIDを使用して関連するローカル州を検索し、IKE_SAの認証されたピアアイデンティティをローカル状態と比較します。
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プレフィックス（ES）を送信します。通常、IPv6プレフィックス（ES）も以前と同じですが、これは必須ではありません。
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が作成されると、ピアはこのchild_saに使用されるSPDエントリとパッドチャイルドSA認証データエントリを決定する必要があります。Basic Client-to-VPN-Gatewayの使用では、状況は簡単です。すべての一致するSPDエントリとチャイルドSA認証データエントリは、VPNクライアントとVPNゲートウェイの間の「仮想リンク」に関連しています。ただし、同じピアが他の用途にIPSEC/ IKEV2を使用している場合（IKEV2内に割り当てられていないアドレスを使用）、仮想リンクに関連しないSPDエントリとPAD Child 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:
ピアのいずれかがChild_Saを要求し、すべてをカバーするトラフィックセレクターを提案している場合（図2のように）、それらを内部_IP6_PREFIXで構成したプレフィックスまたは他のSPD/PADエントリに絞り込む必要がありますか？ある種のヒューリスティックが可能ですが（議論については付録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要求（rekeysを含む）に、ikev2リンクIDを含むlink_id通知を含める必要があります。link_id通知は、create_child_sa応答に含まれていません。
Neighbor Discovery [IPv6ND] specifies the following mechanisms:
Neighbor Discovery [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 Exchangeの一部として構成されたグローバルユニキャストプレフィックス（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のみを実装するGatewaysとの互換性のために、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]の内部_IP6_ADDRESS（およびIntenal_Address_expiry）を除く他のすべての属性は、ディスカッションについては、やや混乱して名前が付けられた内部_IP6_SUBNET（[RFC4718]のセクション6.3を参照）を含む、有効なままです。
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オクテット） - 値フィールドのオクテットの長さ（Link -Local Interface 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 Link-Local Interface ID（8オクテット） - Link-Localアドレスに使用されるインターフェイス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オクテット） - 値フィールドのオクテットの長さ。この場合、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通知は、create_child_saリクエストに含まれており、作成されている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の通知メッセージタイプは16414です。プロトコルIDおよびSPIサイズフィールドはゼロに設定されています。この通知に関連付けられたデータは、Internal_IP6_Link構成属性で返されるIKEV2リンクIDです。
This document defines two new IKEv2 configuration attributes, whose values have been allocated from the "IKEv2 Configuration Payload Attribute Types" namespace [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通知メッセージタイプ-Satuseタイプ」という名前から割り当てられた新しい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.
著者は、Patrick Irwin、Tero Kivinen、Chinh Nguyen、Mohan Parthasarathy、Yaron Sheffer、Hemant Singh、Dave Thaler、Yinghzhe Wu、およびFan Zhaoに貴重なコメントに感謝します。
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 Provisioned VPNs ([VLINK], [RFC3884]), and Mobile IPv6 [RFC4877]. Some of the limitations of assigning a single IPv6 address were identified in [RFC3314].
IPSECで保護された「仮想インターフェイス」に関連する課題の多くは、たとえば、IPSEC [RFC4891]を使用してIPv6-in-IPV4トンネルを保護するというコンテキストで、以前に特定されています。、およびモバイルIPv6 [RFC4877]。単一のIPv6アドレスを割り当てることの制限のいくつかは、[RFC3314]で特定されました。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Addr] Hinden、R。およびS. Deering、「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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[AUTOCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[Autoconf] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「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.、Thaler、D.、Andersson、L。、およびS. Cheshire、「インターネットホスト構成の原則」、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.、Simpson、W。、およびH. Soliman、「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.、Haskins、D。、およびE. Allen、「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] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[Mobike] Eronen、P。、「IKEV2 Mobility and Multihoming Protocol（Mobike）」、RFC 4555、2006年6月。
[Multilink] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[MultiLink] Thaler、D。、「Multi-Link Subnet Issues」、RFC 4903、2007年6月。
[NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[Ndproxy] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「第3世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[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] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884] Touch、J.、Eggert、L。、およびY. Wang、「動的ルーティングのためのIPSEC輸送モードの使用」、RFC 3884、2004年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4478] NIR、Y。、「インターネットキーエクスチェンジ（IKEV2）プロトコルでの繰り返し認証」、RFC 4478、2006年4月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P。およびP. Hoffman、「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.、Vogt、C。、およびW. Haddad、「モバイル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. Dupont、「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.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「IPSECを使用してIPv6-in-IPV4トンネルを保護する」、RFC 4891、2007年5月。
[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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Patil、B.、Xia、F.、Sarikaya、B.、Choi、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.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 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] Duffy、M。、「IPSECのフレームワークPPVPNの仮想リンクのフレームワーク」、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 SASがある場合があります。
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.
o リンクは単一のIKESAではありません。再認証をサポートするには、別の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).
o ピア間のすべてのIPSECで保護されたトラフィックが仮想リンクに必ずしも関連しているわけではありません（ただし、最も単純なVPNクライアントからゲートウェイへのシナリオでは、そうです）。
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サブネットプレフィックス、およびLink-Local Traffic（特にLink-Local Multicast）間の関係がどのように編成されているかです。
o How information about the IPv6 prefix(es) is distributed from the gateway to the clients.
o IPv6プレフィックス（ES）に関する情報がゲートウェイからクライアントにどのように配布されるか。
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.
これらのそれぞれについて次に説明します。
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サブネットプレフィックス、およびリンクローカルトラフィック間の関係を整理する方法には、少なくとも3つの主要な選択肢があります。
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クライアントが送信したLink-Localマルチキャストパケットは、他のVPNクライアントによって受信されます（VPN Gatewayはパケットを転送し、おそらくマルチキャストリスナーディスカバリー（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プレフィックスを共有する「マルチリンク」サブネット[MultiLink]の1つの形式。Link-Local Multicastは、他の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時間年中無休でVPN接続を保持するPDAなど、クライアントがバッテリー駆動の場合、特に望ましくありません。このため、マルチアクセスリンクモデルの使用が拒否されました。
The configuration attributes specified in Section 4 use the point-to-point link model.
セクション4で指定されている構成属性は、ポイントツーポイントリンクモデルを使用します。
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:
CGAなどのいくつかのタイプのアドレスは、アドレスを生成する前にプレフィックスに関する知識を必要とします。プレフィックス情報は、次の方法でクライアントに配布できます。
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 DHCPV6メッセージ（IPSECトンネルを介して送信）
In Section 4, the prefix information is distributed in IKEv2 messages.
セクション4では、プレフィックス情報はIKEV2メッセージで配布されています。
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 クライアントは、Stateless Address Autoconfigurationを使用してアドレスを構成し、複製アドレス検出（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ゲートウェイは、パケットを正しく転送するためにどのプレフィックスを使用しているかを知る必要があります。
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.
ほとんどの場合、1つのVPNクライアントが別の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によって実施される可能性があります。VPNクライアントに割り当てられたアドレス/プレフィックスは、IKEV2で交渉された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 Ingressフィルタリング機能は、IPSECの外側に配置できます。SAD/SPDエントリのトラフィックセレクターは、イングレスフィルタリングによって後でドロップされるトラフィックをカバーします。
The former approach is used by the current IPv4 solution and the mechanism specified in Section 4.
前者のアプローチは、現在のIPv4ソリューションとセクション4で指定されたメカニズムによって使用されます。
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人のクライアントが使用するアドレスの数にも依存します。プライバシーアドレスと、暗号化されたアドレス（CGA）のいくつかの使用が可能な場合、単一のクライアントは多数の異なるアドレスを持つことができます（特に異なるプライバシーアドレスが異なる宛先で使用される場合）。
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.
再認可には、2番目のIKE SAが作成されたときに仮想リンクを一意に識別する方法が必要です。いくつかの可能な選択肢は、仮想リンクが「作成」されたIKE SAのIKEセキュリティパラメーターインデックス（SPI）です（同じIKE SA内に複数の仮想リンクがないと仮定）、リンクが作成されたときに割り当てられた新しい識別子が、または、生涯にわたってリンクに割り当てられたままの一意のプレフィックスまたはアドレス。セクション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]).
リンクは、IKEピアアイデンティティ（IDIが複数のホストで同時に使用できるユーザーIDであることが多い）またはピアの外側のIPアドレス（NAT Traversalと[Mobike]のために使用できるユーザーIDであることが多いため）によって一意に識別されないことに注意してください。）。
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).
簡単なソリューションの1つは、仮想リンク識別子を含む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アドレスが含まれている場合、仮想インターフェイスではなく、実際のインターフェイスに関連している可能性があります。または、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-in-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ゲートウェイが物理イーサネットインターフェイスに関連付けられたcreate_child_saリクエストを受信し、（tsi = fe80 :: monthing、dst =*）のsaを要求する場合、通常は要求を拒否します（または、それを空に絞りますset）joe.user@example.comがそのようなchild_sasを要求できるようにする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.)
（ただし、「Neighbourd-Router.example.com」を可能にするSPD/PADエントリがある場合があります。たとえば、Link-Localアドレスを使用するいくつかのルーティングプロトコルを保護するようなSASを作成します。）
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が別のSPD/PADを持ち、joe.user@example.comがこのSAを作成できるようになります。
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）IPSECECESTの外部で実施されるアクセス制御の組み合わせです。。
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ゲートウェイは、独自のLink-Local Interface 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. 次のステップは、IPv6 Stateless Address Autoconfigurationです。つまり、IPSEC SAを介して送信されたルーターの勧誘とルーター広告メッセージです。
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...])
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 SASの作成と再キーリングは、基本的にセクション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ソリューションと比較して、大きなアーキテクチャの変更です。
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 Singhは、バンクーバーでのIETF 70会議で、次のソリューションをスケッチするのを手伝いました。（1）ルーター集約リンクモデル、（2）IKEV2メッセージで配布される（2）プレフィックス情報、（3）statelessアドレスAutoconfigurationを使用した一意のアドレス割り当て（VPNゲートウェイNSメッセージをトラップし、NA応答をスプーフィングする）、および（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ゲートウェイは、独自のLink-Local Interface ID（クライアントのものとは異なる必要がある）、IKEV2リンクID（再認証およびCreate_Child_Saメッセージに使用される）、およびゼロ以上の内部_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.
近隣の勧誘メッセージは、VPNゲートウェイによって処理されます。ターゲットアドレスが他のVPNクライアントによって既に使用されている場合、ゲートウェイは近隣広告で返信します。ターゲットアドレスがまだ使用されていない場合、VPNゲートウェイは、このクライアントが現在使用されていることを指摘し、それに応じて転送状態を更新します。
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メッセージの非標準処理（Gatewayの転送状態の更新に使用される）と、IPSECの外で部分的にアクセス制御を実行します。
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）近隣広告で配布されるプレフィックス情報、（3）ステートレスアドレスAutoconfiguration（VPNゲートウェイをトラップし、NSメッセージをトラップし、NA応答をスプーフィングする）を使用した一意のアドレス割り当てを組み合わせ、（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) and an IKEv2 Link ID (which will be used for reauthentication).
VPNゲートウェイは、独自のLink-Local Interface 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. 次のステップは、IPv6 Stateless Address Autoconfigurationです。つまり、IPSEC SAを介して送信されたルーターの勧誘とルーター広告メッセージです。
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...])
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.
近隣の勧誘メッセージは、VPNゲートウェイによって処理されます。ターゲットアドレスが他のVPNクライアントによって既に使用されている場合、ゲートウェイは近隣広告で返信します。ターゲットアドレスがまだ使用されていない場合、VPNゲートウェイは、このクライアントが現在使用されていることを指摘し、それに応じて転送状態を更新します。
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の外でアクセス制御を実行することです。
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）ルーター集約リンクモデル、（2）IKEV2メッセージで配布されるプレフィックス情報、（3）IKEV2メッセージによる一意のアドレス割り当て、および（4）IPSEC SAD/によって施行されたアクセス制御を組み合わせています。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ゲートウェイは、独自のLink-Local Interface ID（クライアントのものとは異なる必要がある）、IKEV2リンクID（再認証およびCreate_Child_Saメッセージに使用される）、およびゼロ以上の内部_IP6_Address2属性で応答します。各属性には、特定のプレフィックスから1つのアドレスが含まれています。
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 Exchangeでそれらを要求します。例えば：
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を使用）を追加し、内部_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を参照）とマルチリンクサブネットモデルです。
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によるプレフィックス情報分布と一意のアドレス割り当て、および（3）IPSEC SAD/SPDによって施行されたアクセス制御を組み合わせます。
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）Link-Localアドレスが割り当てられ、VPNクライアントとGatewayの間のプロトコルに使用できます。
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).
o （3.3）プレフィックス全体が単一のクライアントに割り当てられているため、クライアントは任意の数のインターフェイスID（プレフィックスに依存する場合がある）を自由に選択できます。
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).
o （3.5）link_id通知により、どのchild_sasが仮想リンクに関連していて、いないかが明確であるため、ソリューションは他のIPSECの使用と互換性があります（セクション4.3および5.3を参照）。
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）新しいメカニズムは、VPNクライアントおよび/またはGatewayがinternal_ip6_address構成属性を実装することを妨げません。ただし、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）接頭辞（構成ペイロード）を構成するためのメカニズムは、付録Aで説明されている理由により、IKEV2に固有のものです。ただし、セクション4.1では、DHCPV6情報 - リクエストメッセージを使用して他の構成情報（DNSサーバーアドレスなど）を取得することをお勧めします。
Authors' Addresses
著者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Julien Laganier QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
Julien Laganier Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 USA
Phone: +1 858 658 3538
EMail: julienl@qualcomm.com
Cheryl Madson Cisco Systems, Inc. 510 MacCarthy Drive Milpitas, CA USA
Cheryl Madson Cisco Systems、Inc。510 Maccarthy Drive Milpitas、CA USA
EMail: cmadson@cisco.com