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
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)
Internet密钥交换协议版本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密钥交换协议版本2（IKEv2）用于远程VPN访问（客户端到VPN网关）时，网关使用IKEv2配置有效负载从内部网络向客户端分配IP地址。RFC 4306中指定的配置有效负载适用于IPv4，但难以使用IPv6的某些功能。本文档为IKEv2指定了新的配置属性，该属性允许VPN网关向客户端分配IPv6前缀，从而使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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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
-------- ---------
Client Gateway
-------- ---------
HDR(IKE_SA_INIT), SAi1, KEi, Ni -->
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 { 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) }
<-- 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
-------- ---------
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 { 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) }
<-- 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".
本文档为IKEv2指定了新的配置属性，该属性允许VPN网关向客户端分配IPv6前缀，从而使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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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]”）；加号表示有效负载可以重复一次或多次（例如，“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地址（来自一个前缀）。该规范允许客户端在其请求中包含多个内部_IP6_地址属性，但网关不能分配比客户端请求的更多的地址。
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.
这种方法使加密生成地址（CGA）[CGA]的使用复杂化。使用CGAs，在知道前缀之前无法计算接口ID。客户端可以首先获取非CGA地址以确定前缀，然后发送单独的CFG_请求以获取具有相同前缀的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].
类似的问题也适用于客户机对正在使用的接口ID感兴趣的其他情况，例如基于哈希的地址[HBA]和隐私地址[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].
如果没有CGA和HBA，VPN客户端将无法充分使用IPv6功能，如[SHIM6]或增强型移动IPv6路由优化[RFC4866]。
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或蓝牙）与其他设备共享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）。然而，当前的模型（每个地址分别被请求）可能很复杂，无法与使用无状态地址自动配置[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.
当其他主机使用无状态地址自动配置时，该解决方案应支持通过局域网连接共享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用于其他用途（使用其他地址）。具体地，对等方可以具有与虚拟链路不相关的安全策略数据库（SPD）条目和对等方授权数据库（PAD）子SA授权数据条目；创建子_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节建议使用DHCPv6信息请求消息来获取其他配置信息（如DNS服务器地址）。
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客户端共享的前缀中分配IPv6地址，则会产生某种多链路子网。[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.
最初的3GPP IPv6规范为每个移动电话分配了一个IPv6地址，类似于当前的IKEv2有效负载。[RFC3314]描述了这种方法的问题，并导致3GPP更改规范，为每部电话分配唯一/64前缀。
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) -->
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.
如果客户端已发送内部_IP6_链路配置属性，则VPN网关应忽略请求中存在的任何内部_IP6_地址配置属性。
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网关必须通过在内部_地址_失败消息中包含通知有效负载，从而使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（VPN网关选择的标识符，客户端将其视为不透明的八位字节字符串——这将用于重新验证和创建子SA消息）的内部_IP6_链路配置属性进行响应，网关的链路本地接口标识符，以及零个或多个内部_IP6_前缀属性。发起者建议的流量选择器也被缩小，仅包含分配的前缀和客户端链接本地地址（FE80:：<client's Interface 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)
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:：<client's Interface 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.
当客户端执行重新身份验证（并希望继续使用相同的“虚拟链接”）时，它会在内部_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(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标识的链路。当客户端希望继续使用具有内部_IP4_地址配置属性的相同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前缀。通常，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.
创建子_SA时，对等方需要确定该子_SA使用了哪些SPD条目和PAD子SA授权数据条目。在基本的客户端到VPN网关使用中，情况很简单：所有匹配的SPD条目和子SA授权数据条目都与VPN客户端和VPN网关之间的“虚拟链路”相关。但是，如果相同的对等方也将IPsec/IKEv2用于其他用途（IKEv2内未分配地址），则它们还将具有与虚拟链路无关的SPD条目和PAD子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
如果其中一个对等方请求一个CHILD_SA并提出覆盖所有内容的流量选择器（如图2所示），那么这些流量选择器应该缩小到配置有内部_IP6_前缀的前缀，还是缩小到
the other SPD/PAD entries? While some kind of heuristics are possible (see Appendix A for discussion), this document specifies an explicit solution:
其他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.
对等方必须在与虚拟链接相关的所有创建子SA请求（包括密钥）中包含包含IKEv2链接ID的链接ID通知。链接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].
对于配置为IKEv2交换一部分的全局单播前缀形成的全局单播地址，不需要重复地址检测，因为这是一个点对点链路，VPN网关不从全局单播前缀分配任何地址。链路本地地址可能需要重复地址检测，例如，当客户端根据[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交换的一部分配置的全局单播前缀形成的全局单播地址，可以跳过重复地址检测。但是，必须按照某些其他规范的要求执行链路本地单播地址的重复地址检测，例如[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.
本文档中描述的机制不打算与现有的内部_IP6_ADDRESS属性同时使用。为了与仅实现内部_IP6_地址的网关兼容，VPN客户端可以在CFG_请求中包含这两种机制的属性。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_地址（和内部_地址_到期日）之外的所有其他属性仍然有效，包括名称有些混乱的内部_IP6_子网（有关讨论，请参见[RFC4718]第6.3节）。
The INTERNAL_IP6_LINK configuration attribute is formatted as follows:
内部_IP6_链路配置属性的格式如下：
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位）-内部IP6链接（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个八位字节）-值字段的八位字节长度（链路本地接口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时，可能为空）。VPN网关选择链路ID，客户端将其视为不透明的八位字节字符串。
The INTERNAL_IP6_PREFIX configuration attribute is formatted as follows:
内部_IP6_前缀配置属性的格式如下：
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 |
+-+-+-+-+-+-+-+-+
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位）-内部_IP6_前缀（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.
链接ID通知包含在CREATE_CHILD_SA请求中，以指示正在创建的SA与虚拟链接相关。如果未包含此通知，则创建子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大小字段设置为零。与此通知相关联的数据是在“内部_IP6_链接配置”属性中返回的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配置属性，其值已从“IKEv2配置有效负载属性类型”命名空间[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]
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通知消息类型-状态类型”命名空间[IKEv2]中分配：
Value Notify Messages - Status Types Reference
------ ------------------------------- ---------
16414 LINK_ID [RFC5739]
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、Yingzhe 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
许多与受IPsec保护的“虚拟接口”相关的挑战之前已经被识别，例如，在使用IPsec[RFC4891]提供程序保护IPv6-in-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]。[RFC3314]中确定了分配单个IPv6地址的一些限制。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，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 42912006年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无状态地址自动配置”，RFC 48622007年9月。
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2006.
[CGA]Aura，T.，“加密生成地址（CGA）”，RFC 39722006年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 33151003年7月。
[HBA] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[HBA]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC 55352009年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 48612007年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移动和多址协议（MOBIKE）”，RFC4552006年6月。
[Multilink] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[Multilink]Thaler，D.，“多链路子网问题”，RFC 49032007年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，“邻居发现代理（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.，“第三代合作伙伴项目（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 41932005年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]Erenen，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的移动IPv6操作和修订的IPsec架构”，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保护IPv4隧道中的IPv6”，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中无状态地址自动配置的隐私扩展”，RFC 49412007年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 51212008年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，“代理移动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 55332009年6月。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
[VLINK]Duffy，M.，“PPVPN的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.
o 链接不是单个IKE SA；为了支持重新验证，必须能够在另一个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子网前缀和链路本地流量（特别是链路本地多播）之间的关系是如何组织的。
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 第三层访问控制是如何完成的；换句话说，用于防止客户端地址欺骗的机制是按体系结构放置的。
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子网前缀和链路本地流量之间的关系，至少有三种主要选择：
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客户端分配一个或多个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前缀。一个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 “路由器聚合”链路模型：“多链路”子网[Multilink]的一种形式，其中多个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客户端（即，当前未发送或接收应用程序流量）可以从其他客户端接收大量多播数据包（取决于连接的其他客户端数量）。当客户端由电池供电时（例如PDA），这种情况尤其不可取，因为PDA会使VPN连接保持24/7的活动状态。因此，拒绝使用多址链路模型。
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.
在“多访问”和“路由器聚合”链路模型中（在多个VPN客户端之间共享一个IPv6前缀），需要有机制来确保一个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网关只需要知道哪个客户端正在使用哪个前缀就可以正确地转发数据包。
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客户端发送带有另一个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 第三层访问控制可以通过IPsec安全关联数据库（SAD）/SPD来实现；分配给VPN客户端的地址/前缀将反映在IPsec安全关联和安全策略数据库条目中使用的流量选择器中，如IKEv2中协商的。
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节中指定的机制使用前一种方法。
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网关中所需的状态信息量不仅取决于客户端数量，还取决于一个客户端使用的地址数量。对于隐私地址和可能使用的加密生成地址（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.
重新身份验证需要在创建第二个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通常是可在多台主机上同时使用的用户身份）或对等外部IP地址（由于NAT遍历和[MOBIKE]）唯一标识的。
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使用的兼容性可能需要在创建子_SA时，两个对等方都可以确定子_SA是应用于虚拟接口（在虚拟链接的末尾）还是应用于发送IKEv2消息的真实接口。这需要选择正确的SPD，以用于流量选择器缩小和SA授权。
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).
一个简单的解决方案是添加额外的负载来创建包含虚拟链接标识符的\u CHILD\u 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.
另一种解决方案是要求请求子节点的对等方提出识别链路的流量选择器。例如，如果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.
这些启发式算法可以在许多情况下工作，但在IPv4隧道中的IPv6[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
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.
请求（或者，换句话说，将其缩小为一个空集），因为它没有允许joe的SPD/PAD条目。user@example.com请求这样的孩子。
(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.)
（但是，它可能有SPD/PAD条目，允许“neighbor router.example.com”创建这样的SA，以保护某些使用链路本地地址的路由协议。）
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已验证并发送的内部_IP6_链路将具有不同的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）在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) -->
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)
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无状态地址自动配置，即通过IPsec SA发送路由器请求和路由器广告消息。
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
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(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节相同；客户端将IKEv2链接ID包含在内部_IP6_链接属性中。
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节中的工作方式基本相同；客户端将IKEv2链接ID包含在与虚拟链接相关的子_SA请求中。
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堆栈来自不同的公司时，它的实现不必要地复杂。此外，与当前的IPv4解决方案相比，在IPsec之外实施访问控制是一个重大的体系结构变化。
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消息中的前缀信息，（3）具有无状态地址自动配置的唯一地址分配（使用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) -->
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（必须与客户端的不同）、IKEv2链路ID（将用于重新验证和创建\u CHILD \u SA消息）以及零个或多个内部\u IP6 \u前缀属性进行响应。发起者提出的流量选择器也被缩小，只包含分配的前缀（和链路本地前缀）。
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)
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消息（用于更新网关的转发状态）的非标准处理，以及部分在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）具有无状态地址自动配置的唯一地址分配（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) -->
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)
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无状态地址自动配置，即通过IPsec SA发送路由器请求和路由器广告消息。
ESP(Router Solicitation:
src=::,
dst=FF02:0:0:0:0:0:0:2) -->
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(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) -->
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（必须与客户端的不同）、IKEv2链路ID（将用于重新验证和创建\u CHILD\u SA消息）以及零个或多个内部\u IP6\u 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)
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) -->
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)
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）分配链路本地地址，并可用于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).
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）该解决方案与其他IPsec用途兼容，因为链接ID通知可以明确哪些子节点与虚拟链接相关，哪些子节点与虚拟链接无关（请参见第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客户端和/或网关实现内部_IP6_地址配置属性；但是，这两种机构不打算同时使用（见第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诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Julien Laganier QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
Julien Laganier高通公司美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
Phone: +1 858 658 3538
EMail: julienl@qualcomm.com
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号
EMail: cmadson@cisco.com
EMail: cmadson@cisco.com