Network Working Group V. Devarapalli
Request for Comments: 5685 WiChorus
Category: Standards Track K. Weniger
Unaffiliated
November 2009
Network Working Group V. Devarapalli
Request for Comments: 5685 WiChorus
Category: Standards Track K. Weniger
Unaffiliated
November 2009
Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
Internet密钥交换协议版本2（IKEv2）的重定向机制
Abstract
摘要
The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent.
Internet密钥交换协议版本2（IKEv2）是一种用于设置从远程位置到网关的虚拟专用网络（VPN）隧道的协议，以便VPN客户端可以访问网关后面网络中的服务。本文档定义了一个IKEv2扩展，该扩展允许过载的VPN网关或为维护而关闭的VPN网关重定向VPN客户端以连接到另一个网关。所提出的机制还可用于移动IPv6，以使归属代理能够将移动节点重定向到另一个归属代理。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。本协议某些部分的版权控制人
material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
材料可能未授予IETF信托允许在IETF标准过程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. IKEv2 Initial Exchange with Redirect ............................3
4. Use of Anycast Addresses with the Redirect Mechanism ............5
5. Redirect during an Active Session ...............................6
6. Redirect during IKE_AUTH Exchange ...............................7
7. Handling Redirect Loops .........................................8
8. Using the Redirect Mechanism with Mobile IPv6 ...................8
9. Redirect Messages ...............................................9
9.1. REDIRECT_SUPPORTED .........................................9
9.2. REDIRECT ..................................................10
9.3. REDIRECTED_FROM ...........................................11
10. Use of the Redirect Mechanism between IKEv2 Peers .............12
11. Security Considerations .......................................12
12. IANA Considerations ...........................................13
13. Acknowledgements ..............................................13
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................14
1. Introduction ....................................................2
2. Terminology .....................................................3
3. IKEv2 Initial Exchange with Redirect ............................3
4. Use of Anycast Addresses with the Redirect Mechanism ............5
5. Redirect during an Active Session ...............................6
6. Redirect during IKE_AUTH Exchange ...............................7
7. Handling Redirect Loops .........................................8
8. Using the Redirect Mechanism with Mobile IPv6 ...................8
9. Redirect Messages ...............................................9
9.1. REDIRECT_SUPPORTED .........................................9
9.2. REDIRECT ..................................................10
9.3. REDIRECTED_FROM ...........................................11
10. Use of the Redirect Mechanism between IKEv2 Peers .............12
11. Security Considerations .......................................12
12. IANA Considerations ...........................................13
13. Acknowledgements ..............................................13
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................14
IKEv2 [2] is used for setting up IPsec-based [7] VPNs. The IP address of the VPN gateway can be configured on the VPN client. But this does not scale well when the number of VPN gateways is large. Dynamic discovery of VPN gateways using DNS is quite widely used too. However, using DNS is not flexible when it comes to assigning a VPN gateway to the VPN client based on the load on the VPN gateways. The VPN client typically tries to connect to the IP address of the VPN gateway that appears first in the DNS response. If the VPN tunnel setup fails, then the VPN client tries to attach to the other VPN gateways returned in the DNS response.
IKEv2[2]用于设置基于IPsec的[7]VPN。VPN网关的IP地址可以在VPN客户端上配置。但是，当VPN网关的数量很大时，这种方法不能很好地扩展。使用DNS动态发现VPN网关的应用也相当广泛。但是，在根据VPN网关上的负载将VPN网关分配给VPN客户端时，使用DNS是不灵活的。VPN客户端通常尝试连接到DNS响应中首先出现的VPN网关的IP地址。如果VPN隧道设置失败，则VPN客户端将尝试连接到DNS响应中返回的其他VPN网关。
This document proposes a redirect mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. The redirect can be done during the IKE_SA_INIT or the IKE_AUTH exchange. Gateway-initiated
本文档提出了IKEv2的重定向机制，该机制允许VPN网关将VPN客户端重定向到另一个VPN网关，例如，基于负载条件。重定向可以在IKE_SA_INIT或IKE_AUTH交换期间完成。网关启动
redirect in the middle of a session is also supported. The redirect mechanism can also be used in conjunction with anycast addresses. In this case, an anycast address for the cluster of VPN gateways is stored in the DNS instead of a list of unicast IP addresses of the VPN gateways.
还支持在会话中间重定向。重定向机制也可以与选播地址结合使用。在这种情况下，VPN网关集群的选播地址存储在DNS中，而不是VPN网关的单播IP地址列表。
The redirect can also happen because of administrative or optimal-routing reasons. This document does not attempt to provide an exhaustive list of reasons for redirecting a VPN client to another VPN gateway.
由于管理或最佳路由原因，也可能发生重定向。本文档并不试图提供将VPN客户端重定向到另一个VPN网关的详尽原因列表。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
This section describes the use of the redirect mechanism during the IKE_SA_INIT exchange. Gateway-initiated redirect during an active session and the use of redirect during IKE_AUTH exchange are explained in subsequent sections.
本节介绍在IKE_SA_INIT交换期间重定向机制的使用。活动会话期间网关启动的重定向以及IKE_身份验证交换期间重定向的使用将在后续章节中解释。
The VPN client indicates support for the IKEv2 redirect mechanism and its willingness to be redirected by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request (see Section 9.1). The gateway MUST keep track of those clients that indicated support for the redirect mechanism and those that didn't.
VPN客户端表示支持IKEv2重定向机制，并愿意通过在初始IKE_SA_INIT请求中包含支持重定向的通知消息进行重定向（见第9.1节）。网关必须跟踪那些表示支持重定向机制的客户端和那些不支持重定向机制的客户端。
To redirect an IKEv2 session to another VPN gateway, the VPN gateway that initially received the IKE_SA_INIT request selects another VPN gateway (how the selection is made is beyond the scope of this document) and replies with an IKE_SA_INIT response containing a REDIRECT notification message (see Section 9.2). The notification includes information about the selected VPN gateway and the nonce data from the Ni payload in the IKE_SA_INIT request. If the IKE_SA_INIT request did not indicate support for the redirect mechanism, the responder MUST NOT send the REDIRECT payload to the VPN client. This is applicable to all REDIRECT scenarios described in this document.
为了将IKEv2会话重定向到另一个VPN网关，最初收到IKE_SA_INIT请求的VPN网关选择另一个VPN网关（选择的方式超出了本文的范围），并使用包含重定向通知消息的IKE_SA_INIT响应进行回复（见第9.2节）。该通知包括关于所选VPN网关的信息以及IKE_SA_INIT请求中来自Ni有效负载的nonce数据。如果IKE_SA_INIT请求未表示支持重定向机制，则响应程序不得将重定向有效负载发送到VPN客户端。这适用于本文档中描述的所有重定向场景。
Note that when the IKE_SA_INIT response includes the REDIRECT notification, the exchange does not result in the creation of an IKE_SA and the responder Security Parameter Index (SPI) will be zero.
请注意，当IKE_SA_INIT响应包含重定向通知时，交换不会导致创建IKE_SA，并且响应程序安全参数索引（SPI）将为零。
Initiator Responder (initial VPN GW)
--------- -------------------------
Initiator Responder (initial VPN GW)
--------- -------------------------
(IP_I:500 -> Initial_IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECT_SUPPORTED)
(IP_I:500 -> Initial_IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECT_SUPPORTED)
(Initial_IP_R:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
(Initial_IP_R:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
When the client receives the IKE_SA_INIT response, it MUST verify that the nonce data matches the value sent in the IKE_SA_INIT request. If the values do not match, the client MUST silently discard the response (and keep waiting for another response). This prevents certain denial-of-service (DoS) attacks on the initiator that could be caused by an attacker injecting IKE_SA_INIT responses with REDIRECT payloads.
当客户端收到IKE_SA_INIT响应时，它必须验证nonce数据是否与IKE_SA_INIT请求中发送的值匹配。如果这些值不匹配，客户端必须默默地放弃响应（并继续等待另一个响应）。这可以防止攻击者使用重定向有效负载注入IKE_SA_INIT响应而对启动器造成的某些拒绝服务（DoS）攻击。
After verifying the nonce data, the client initiates a new IKE_SA_INIT exchange with the VPN gateway listed in the REDIRECT payload, provided this is allowed by its Peer Authorization Database (PAD) entries. In the IKE_SA_INIT exchange with the new VPN gateway, the client MUST include the REDIRECTED_FROM payload (see Section 9.3). The VPN client includes the IP address of the original VPN gateway that redirected the client in the REDIRECTED_FROM notification. The IKEv2 exchange then proceeds as it would have proceeded with the original VPN gateway.
验证nonce数据后，客户机与重定向有效负载中列出的VPN网关发起新的IKE_SA_INIT交换，前提是其对等授权数据库（PAD）条目允许这样做。在与新VPN网关的IKE_SA_INIT交换中，客户端必须包括来自有效负载的重定向_（请参阅第9.3节）。VPN客户端包括在重定向通知中重定向客户端的原始VPN网关的IP地址。然后，IKEv2交换继续进行，就像它将继续使用原始VPN网关一样。
Initiator Responder (Selected VPN GW)
--------- ---------------------------
Initiator Responder (Selected VPN GW)
--------- ---------------------------
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_FROM, Initial_IP_R)
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_FROM, Initial_IP_R)
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The client MAY get redirected again by the new VPN gateway if the new VPN gateway also cannot serve the client. The client does not have to include the REDIRECT_SUPPORTED payload again in the IKE_SA_INIT exchange with the new gateway after a redirect. The presence of the REDIRECT_FROM payload in the IKE_SA_INIT exchange with the new gateway indicates to the new gateway that the client supports the redirect mechanism.
如果新VPN网关也无法为客户端提供服务，则客户端可能会再次被新VPN网关重定向。在重定向之后，客户端不必在IKE_SA_INIT交换中与新网关再次包含重定向支持的负载。IKE_SA_INIT与新网关的交换中存在来自有效负载的重定向_，这向新网关表明客户端支持重定向机制。
When the client gets redirected, it MUST use the same Peer Authorization Database (PAD) and Security Policy Database (SPD) entries as it would have used with the original gateway. Receiving a redirect notification MUST NOT result in the modification of any PAD or SPD entries. In practice, this means the new gateway either has to use the same responder identity (IDr) as the original gateway, or both should be part of a group of responders that are authorized by the same PAD entry. See Section 4.4.3.1 of [7] on using DNS names to represent a group of peers in a PAD entry.
当客户端被重定向时，它必须使用与原始网关相同的对等授权数据库（PAD）和安全策略数据库（SPD）条目。接收重定向通知不得导致修改任何PAD或SPD条目。实际上，这意味着新网关要么必须使用与原始网关相同的响应者标识（IDr），要么两者都应该是由同一PAD条目授权的响应者组的一部分。参见[7]第4.4.3.1节，关于使用DNS名称表示PAD条目中的一组对等方。
This document allows the client to be redirected in several protocol states. In some of them, the gateway is already authenticated at the point of redirect; in others, it is not. We emphasize that the above rules regarding the identity of the new gateway and the PAD and SPD entries apply equally to all these scenarios.
此文档允许在多个协议状态下重定向客户端。在某些情况下，网关已经在重定向点进行了身份验证；在其他国家，情况并非如此。我们强调，上述关于新网关标识以及PAD和SPD条目的规则同样适用于所有这些场景。
Using anycast addresses will avoid the necessity of configuring a particular VPN gateway's IP address in the DNS. Instead, the anycast address that represents the group of VPN gateways is stored in the DNS. When the VPN client performs a DNS lookup for the VPN gateway, it receives the anycast address of the VPN gateway in the DNS response.
使用选播地址将避免在DNS中配置特定VPN网关的IP地址。相反，表示VPN网关组的选播地址存储在DNS中。当VPN客户端对VPN网关执行DNS查找时，它会在DNS响应中接收VPN网关的选播地址。
If an anycast address is returned in response to the DNS resolution of a Fully Qualified Domain Name (FQDN), the VPN client sends the IKE_SA_INIT request to the anycast address. The REDIRECT_SUPPORTED payload is included in the IKE_SA_INIT request sent to the anycast address. The IKE_SA_INIT request is routed to one of the VPN gateways that is part of the anycast group. The VPN gateway that receives the IKE_SA_INIT request responds with an IKE_SA_INIT reply from the anycast address.
如果响应完全限定域名（FQDN）的DNS解析返回了选播地址，VPN客户端将IKE_SA_INIT请求发送到选播地址。支持重定向的有效负载包含在发送到选播地址的IKE_SA_INIT请求中。IKE_SA_INIT请求被路由到属于anycast组的VPN网关之一。接收IKE_SA_INIT请求的VPN网关使用来自选播地址的IKE_SA_INIT回复进行响应。
Initiator Responder (any VPN GW)
--------- -------------------------
Initiator Responder (any VPN GW)
--------- -------------------------
(IP_I:500 -> ANYCAST:500)
HDR(A,0), SAi1, KEi, Ni) -->
N(REDIRECT_SUPPORTED)
(IP_I:500 -> ANYCAST:500)
HDR(A,0), SAi1, KEi, Ni) -->
N(REDIRECT_SUPPORTED)
(ANYCAST:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
(ANYCAST:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
If the destination address on the IKE_SA_INIT request is an anycast address, the VPN gateway that received the IKE_SA_INIT request MUST include the REDIRECT payload to redirect the VPN client to a unicast address of one of the VPN gateways. The VPN gateway that received the IKE_SA_INIT request MAY redirect the client to its own unicast address if it is not overloaded.
如果IKE_SA_INIT请求上的目标地址是选播地址，则接收IKE_SA_INIT请求的VPN网关必须包括重定向有效负载，以将VPN客户端重定向到其中一个VPN网关的单播地址。接收IKE_SA_INIT请求的VPN网关可以将客户端重定向到其自己的单播地址（如果没有过载）。
The rest of the IKEv2 exchange is the same as described in Section 3.
IKEv2交换的其余部分与第3节所述相同。
The redirect mechanism may also be used by a VPN gateway to redirect the client to another VPN gateway in the middle of a session. To redirect a client, the gateway should send an INFORMATIONAL message with the REDIRECT Notify payload. The REDIRECT payload MUST carry information about the new VPN gateway. The gateway MUST NOT include any nonce data in the REDIRECT payload, since it is a gateway-initiated redirect and is protected by the IKEv2 security association. When the client receives this message, it sends a response (usually empty) to the gateway. The gateway retransmits the redirect INFORMATIONAL message as described in [2], until it gets a response. The following illustrates the INFORMATIONAL message exchange for gateway-initiated redirect.
重定向机制也可以被VPN网关用于在会话中间将客户端重定向到另一个VPN网关。要重定向客户端，网关应发送一条带有重定向通知负载的信息性消息。重定向有效负载必须携带有关新VPN网关的信息。网关不得在重定向有效负载中包含任何nonce数据，因为它是由网关启动的重定向，并受IKEv2安全关联的保护。当客户端收到此消息时，它会向网关发送一个响应（通常为空）。网关按照[2]中所述重新传输重定向信息消息，直到收到响应。以下说明了网关启动的重定向的信息性消息交换。
Initiator (VPN client) Responder (VPN GW)
---------------------- ------------------
Initiator (VPN client) Responder (VPN GW)
---------------------- ------------------
<-- HDR, SK {N(REDIRECT, New_GW_ID)}
<-- HDR, SK {N(REDIRECT, New_GW_ID)}
HDR, SK {} -->
HDR, SK {} -->
The INFORMATIONAL message exchange described above is protected by the existing IKEv2 SA between the client and the gateway.
上述信息性消息交换由客户端和网关之间现有的IKEv2 SA保护。
Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an INFORMATIONAL message with a DELETE payload. The gateway MAY also decide to delete the security associations without any
一旦客户端向网关发送确认，它应该通过发送带有删除负载的信息性消息来删除与旧网关的现有安全关联。网关还可以决定删除安全关联，而不进行任何更改
signaling from the client, again by sending an INFORMATIONAL message with a DELETE payload; however, it should allow sufficient time for the client to set up the required security associations with the new security gateway. This time period should be configurable on the gateway.
再次通过发送带有删除有效载荷的信息性消息来从客户端发送信令；但是，它应该允许客户端有足够的时间与新的安全网关建立所需的安全关联。此时间段应可在网关上配置。
If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. The gateway MUST verify the client's AUTH payload before sending the REDIRECT payload, and the client MUST verify the gateway's AUTH payload before acting on the REDIRECT payload. Since the AUTH payloads were exchanged and successfully verified, the IKEv2 security association is valid. When the client receives the IKE_AUTH response with the REDIRECT payload, it SHOULD delete the IKEv2 security association with the gateway by sending an INFORMATIONAL message with a DELETE payload.
如果网关决定在IKE_AUTH交换期间重定向客户端，则基于客户端在IKE_AUTH请求消息中提供的标识，它将阻止创建子SA，并在IKE_AUTH响应中发送重定向有效负载。网关必须在发送重定向负载之前验证客户端的身份验证负载，并且客户端必须在对重定向负载进行操作之前验证网关的身份验证负载。由于已交换并成功验证了身份验证有效负载，因此IKEv2安全关联是有效的。当客户端接收到带有重定向负载的IKE_AUTH响应时，它应该通过发送带有删除负载的信息性消息来删除与网关的IKEv2安全关联。
Initiator Responder (VPN GW)
--------- ------------------
Initiator Responder (VPN GW)
--------- ------------------
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_SUPPORTED)
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_SUPPORTED)
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr} -->
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID)}
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID)}
In case the IKE_AUTH exchange involves Extensible Authentication Protocol (EAP) authentication (as described in Section 2.16 of RFC 4306 [2]) or multiple authentication methods (as described in RFC 4739 [6]), the gateway may decide to redirect the client based on the interaction with the Authentication, Authorization, and Accounting (AAA) server or the external authentication server. In this case, the gateway MUST send the REDIRECT Notify payload in either the first or the last IKE_AUTH response. The client and the gateway MUST verify the AUTH payloads as described above.
如果IKE_身份验证交换涉及可扩展身份验证协议（EAP）身份验证（如RFC 4306[2]第2.16节所述）或多种身份验证方法（如RFC 4739[6]所述），则网关可根据与身份验证、授权和计费（AAA）的交互来决定重定向客户端服务器或外部身份验证服务器。在这种情况下，网关必须在第一个或最后一个IKE_AUTH响应中发送重定向通知有效负载。客户端和网关必须如上所述验证身份验证有效负载。
When EAP is used, the gateway MAY also redirect the client based on the unauthenticated identity presented by the client in the first IKE_AUTH exchange, itself. Since EAP is used as the authentication mechanism, the client does not include AUTH payload to authenticate its identity, but the server MUST still include its own AUTH payload, and the client MUST verify it. Note that the IKEv2 SA is not created in this case and the client does not have to explicitly delete the IKEv2 SA.
当使用EAP时，网关还可以根据客户端在第一次IKE_身份验证交换中提供的未经验证的身份重定向客户端。由于EAP用作身份验证机制，因此客户端不包括用于身份验证的身份验证有效负载，但服务器仍必须包括其自己的身份验证有效负载，并且客户端必须对其进行验证。请注意，在这种情况下不会创建IKEv2 SA，并且客户端不必显式删除IKEv2 SA。
In all of the cases above, the client MUST accept the REDIRECT notification only in the first IKE_AUTH response or the last IKE_AUTH response. It MUST NOT accept the REDIRECT notification in an intermediate IKE_AUTH response.
在上述所有情况下，客户端必须仅在第一个IKE_AUTH响应或最后一个IKE_AUTH响应中接受重定向通知。它不能接受中间IKE_AUTH响应中的重定向通知。
The client could end up getting redirected multiple times in a sequence, either because of a wrong configuration or a DoS attack. The client could even end up in a loop with two or more gateways redirecting the client to each other. This could deny service to the client. To prevent this, the client SHOULD be configured to not accept more than a certain number of redirects (MAX_REDIRECTS) within a short time period (REDIRECT_LOOP_DETECT_PERIOD) for a particular IKEv2 SA setup. The default value for the MAX_REDIRECTS configuration variable is 5. The default value for the REDIRECT_LOOP_DETECT_PERIOD configuration variable is 300 seconds. Client implementations may allow these variables to be configured, depending on a specific deployment or system configuration.
由于配置错误或DoS攻击，客户端可能会在一个序列中多次被重定向。客户机甚至可能在一个循环中结束，有两个或多个网关将客户机重定向到彼此。这可能会拒绝向客户端提供服务。为防止出现这种情况，应将客户端配置为在短时间内（重定向循环检测周期）不接受特定IKEv2 SA设置超过一定数量的重定向（最大重定向）。MAX_REDIRECTS配置变量的默认值为5。重定向循环检测周期配置变量的默认值为300秒。客户机实现可能允许配置这些变量，具体取决于特定的部署或系统配置。
Mobile IPv6 [3] may use IKEv2 for mutual authentication between the mobile node and the home agent, for home address configuration, and for setting up security associations for protecting Mobile IPv6 signaling messages [4]. The IKEv2 exchange, if IKEv2 is used, precedes the exchange of Mobile IPv6 signaling messages. Therefore, the mechanism described in this document can also be used by a Mobile IPv6 home agent to redirect a mobile node to another home agent.
移动IPv6[3]可以使用IKEv2在移动节点和归属代理之间进行相互认证，进行归属地址配置，并建立安全关联以保护移动IPv6信令消息[4]。如果使用IKEv2，则IKEv2交换在移动IPv6信令消息交换之前。因此，本文档中描述的机制也可由移动IPv6归属代理用于将移动节点重定向到另一归属代理。
There is a Home Agent Switch mechanism available for redirecting a mobile node to another home agent, described in [5]. The Home Agent Switch mechanism can only be used after the binding cache has been created at the home agent for the mobile node. The disadvantage with this is that quite a bit of state is created on the home agent before the mobile node can be redirected to another home agent. The mechanism described in this document can be used for redirecting a mobile node before any state related to the Mobile IPv6 binding is created on the home agent.
有一种归属代理切换机制可用于将移动节点重定向到另一个归属代理，如[5]所述。只有在移动节点的归属代理上创建了绑定缓存之后，才能使用归属代理切换机制。这样做的缺点是，在移动节点可以重定向到另一个归属代理之前，在归属代理上创建了相当多的状态。本文档中描述的机制可用于在归属代理上创建与移动IPv6绑定相关的任何状态之前重定向移动节点。
When running IKEv2 between a Mobile IPv6 mobile node (MN) and home agent (HA), redirecting the IKEv2 exchange to another HA is not enough; the Mobile IPv6 signaling also needs to be sent to the new HA address. The MN MAY treat the information received in the IKE_SA_INIT response in a similar way as it would treat HA discovery information received from other unauthenticated (and potentially untrustworthy) sources (such as DNS lookups not protected with DNS Security (DNSSEC)). However, if the MN has authenticated information about its home agent, it MUST NOT be updated based on the IKE_SA_INIT response.
在移动IPv6移动节点（MN）和归属代理（HA）之间运行IKEv2时，将IKEv2交换机重定向到另一个HA是不够的；移动IPv6信令也需要发送到新的HA地址。MN可以以类似的方式处理在IKE_SA_INIT响应中接收到的信息，就像它处理从其他未经验证（并且可能不可信）的源（例如未受DNS安全性（DNSSEC）保护的DNS查找）接收到的HA发现信息一样。但是，如果MN已经验证了关于其归属代理的信息，则不能基于IKE_SA_INIT响应对其进行更新。
If the REDIRECT notification is received during the IKE_AUTH exchange (after the HA has been authenticated; see Section 6), the MN MAY pass the new address to Mobile IPv6 and treat it in a similar fashion as information from the Home Agent Switch message [5].
如果在IKE_身份验证交换期间收到重定向通知（在HA经过身份验证后；参见第6节），MN可以将新地址传递给移动IPv6，并以类似方式将其作为来自归属代理交换消息的信息处理[5]。
Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL exchanges (see Section 5) MUST NOT result in updating any Mobile IPv6 state. In such cases, the Home Agent Switch message specified in [5] is used instead.
在信息交换（见第5节）中交换的网关启动的重定向通知不得导致更新任何移动IPv6状态。在这种情况下，使用[5]中指定的归属代理切换消息。
The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT request by the initiator to indicate support for the IKEv2 redirect mechanism described in this document.
发起方的初始IKE_SA_INIT请求中包含了支持重定向的有效负载，以表明对本文档中描述的IKEv2重定向机制的支持。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association.
“下一个有效负载”、“有效负载长度”、“协议ID”、“SPI大小”和“通知消息类型”字段与[2]第3.10节中所述相同。“SPI大小”字段必须设置为0，以指示此消息中不存在SPI。“协议ID”必须设置为0，因为通知不是特定于特定安全关联的。
The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate the REDIRECT_SUPPORTED payload (16406).
“有效负载长度”字段设置为整个有效负载（包括通用有效负载标头）的长度（以八位字节为单位）。“Notify Message Type”（通知消息类型）字段设置为指示重定向受支持的有效负载（16406）。
When the responder wants to redirect the initiator to another VPN gateway, the REDIRECT payload is included in either an IKE_SA_INIT response from the responder or an INFORMATIONAL message from the responder. The message includes the new responder's IP address or DNS name.
当响应者想要将启动器重定向到另一个VPN网关时，重定向有效负载包含在响应者的IKE_SA_INIT响应或响应者的信息消息中。该消息包括新响应者的IP地址或DNS名称。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW Ident Type | GW Ident Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ New Responder GW Identity ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW Ident Type | GW Ident Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ New Responder GW Identity ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association.
“下一个有效负载”、“有效负载长度”、“协议ID”、“SPI大小”和“通知消息类型”字段与[2]第3.10节中所述相同。“SPI大小”字段必须设置为0，以指示此消息中不存在SPI。“协议ID”必须设置为0，因为通知不是特定于特定安全关联的。
The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate the REDIRECT payload (16407). The 'GW Identity Type' field indicates the type of information that is sent to identify the new VPN gateway. The following values are valid in the REDIRECT payload.
“有效负载长度”字段设置为整个有效负载（包括通用有效负载标头）的长度（以八位字节为单位）。“通知消息类型”字段设置为指示重定向有效负载（16407）。“GW标识类型”字段表示为标识新VPN网关而发送的信息类型。以下值在重定向有效负载中有效。
1 - IPv4 address of the new VPN gateway
1-新VPN网关的IPv4地址
2 - IPv6 address of the new VPN gateway
2-新VPN网关的IPv6地址
3 - FQDN of the new VPN gateway
3-新VPN网关的FQDN
The 'GW Ident Len' field is set to the length of the gateway identity information. The identity of the new VPN gateway is carried in the 'New Responder GW Identity' field. The IPv4 address, the IPv6 address, or the FQDN of the new VPN gateway MUST be encoded as described in Section 3.5 of [2].
“GW Ident Len”字段设置为网关标识信息的长度。新VPN网关的标识包含在“新响应者GW标识”字段中。新VPN网关的IPv4地址、IPv6地址或FQDN必须按照[2]第3.5节所述进行编码。
The 'Nonce Data' field carries the nonce data from the Ni payload sent by the initiator. The size of the nonce MUST be between 16 and 256 bytes, as described in Section 3.9 of [2]. The 'Nonce Data' field is present in the REDIRECT payload only when the REDIRECT payload is sent in the IKE_SA_INIT response message. It MUST NOT be included in the REDIRECT payload if sent in an IKE_AUTH response or in a gateway-initiated redirect message.
“Nonce Data”字段携带发起者发送的Ni有效负载的Nonce数据。nonce的大小必须介于16到256字节之间，如[2]第3.9节所述。只有在IKE_SA_INIT响应消息中发送重定向有效负载时，重定向有效负载中才会出现“Nonce Data”字段。如果在IKE_AUTH响应或网关启动的重定向消息中发送，则它不得包含在重定向有效负载中。
The REDIRECTED_FROM Notify payload is included in the IKE_SA_INIT request from the initiator to the new VPN gateway to indicate the IP address of the original VPN gateway that redirected the initiator. The original VPN gateway's IP address is included in the message. If the IKE_SA_INIT request was sent to any anycast address (see Section 4), then the anycast address is included in the message. This payload also serves the purpose of indicating support for the redirect mechanism to the new VPN gateway after a redirect.
从Notify有效负载重定向的_包含在从启动器到新VPN网关的IKE_SA_INIT请求中，以指示重定向启动器的原始VPN网关的IP地址。消息中包含原始VPN网关的IP地址。如果IKE_SA_INIT请求被发送到任何选播地址（参见第4节），则选播地址包含在消息中。此有效负载还用于指示在重定向后对新VPN网关的重定向机制的支持。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW Ident Type | GW Ident Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Original Responder GW Identity ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GW Ident Type | GW Ident Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Original Responder GW Identity ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association.
“下一个有效负载”、“有效负载长度”、“协议ID”、“SPI大小”和“通知消息类型”字段与[2]第3.10节中所述相同。“SPI大小”字段必须设置为0，以指示此消息中不存在SPI。“协议ID”必须设置为0，因为通知不是特定于特定安全关联的。
The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate the REDIRECTED_FROM payload
“有效负载长度”字段设置为整个有效负载（包括通用有效负载标头）的长度（以八位字节为单位）。“Notify Message Type”（通知消息类型）字段设置为指示来自有效负载的重定向消息类型
(16408). The 'GW Identity Type' field indicates the type of information that is sent to identify the new VPN gateway. The following values are valid in the REDIRECTED_FROM payload.
(16408). “GW标识类型”字段表示为标识新VPN网关而发送的信息类型。以下值在从有效负载重定向的_中有效。
1 - IPv4 address of the original VPN gateway
1-原始VPN网关的IPv4地址
2 - IPv6 address of the original VPN gateway
2-原始VPN网关的IPv6地址
The 'GW Ident Len' field is set to the length of the gateway identity information. The identity of the original VPN gateway is carried in the 'Original Responder GW Identity' field.
“GW Ident Len”字段设置为网关标识信息的长度。原始VPN网关的标识包含在“原始响应者GW标识”字段中。
The redirect mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server.
本文档中描述的重定向机制主要用于客户端网关场景。但是，该机制也可以在任意两个IKEv2对等方之间使用。但该协议是不对称的，这意味着只有原始响应程序才能将原始启动器重定向到另一台服务器。
An eavesdropper on the path between a VPN client and server may send a redirect to the client upon receiving an IKE_SA_INIT message from this client. This is no problem regarding DoS attacks for the VPN connection, since an on-path-attacker can as well drop the IKE_SA_INIT requests to prevent VPN access for the client. But an eavesdropper on the path between VPN client and server can redirect a large number of clients to a victim, which is then flooded with IKE_SA_INIT requests. Flooding only happens if many clients initiate IKEv2 exchange at almost the same time, which is considered a rare event. However, this may happen if a home agent / VPN server is shutdown for maintenance and all clients need to re-establish VPN connections with another home agent / VPN server, or if the on-path attacker forces all IPsec security associations to expire by dropping all received IKEv2 messages.
VPN客户端和服务器之间路径上的窃听者在从该客户端接收IKE_SA_INIT消息时，可以向该客户端发送重定向。这对于VPN连接的DoS攻击没有问题，因为路径上的攻击者也可以丢弃IKE_SA_INIT请求以阻止客户端的VPN访问。但是VPN客户端和服务器之间的路径上的窃听者可以将大量客户端重定向到受害者，然后受害者就会被IKE_SA_INIT请求淹没。只有当许多客户端几乎同时启动IKEv2交换时，才会发生泛洪，这被认为是一种罕见的事件。但是，如果home agent/VPN服务器因维护而关闭，并且所有客户端都需要与另一个home agent/VPN服务器重新建立VPN连接，或者如果路径上攻击者通过删除所有接收到的IKEv2消息迫使所有IPsec安全关联过期，则可能会发生这种情况。
The use of the REDIRECTED_FROM payload is intended to discourage a rogue VPN gateway from redirecting a large number of VPN clients to a particular VPN gateway. It does not prevent such a DoS attack.
使用来自有效负载的重定向_旨在阻止流氓VPN网关将大量VPN客户端重定向到特定VPN网关。它不能阻止这种DoS攻击。
The redirect mechanism MUST NOT update any state on the client apart from the VPN gateway information. When used with Mobile IPv6, care must be taken to ensure that the home agent information that the mobile node has configured is not modified wrongly by the redirect message.
除了VPN网关信息外，重定向机制不得更新客户端上的任何状态。与移动IPv6一起使用时，必须注意确保移动节点配置的归属代理信息不会被重定向消息错误修改。
Redirecting based on the unauthenticated identities from the client might leak out information about the user when an active attacker, pretending to be a VPN client, can get information on the gateway to which the real user was redirected. If redirection is based on some internal information of the user, it might leak information (that might not be available otherwise) about the user to the attacker. To prevent these kinds of attacks, redirection based on unauthenticated IDs should be avoided and should be done only after the client has also authenticated itself.
当假装是VPN客户端的活动攻击者可以获取真实用户重定向到的网关上的信息时，基于客户端未经验证的身份进行重定向可能会泄漏有关用户的信息。如果重定向基于用户的某些内部信息，则可能会向攻击者泄漏有关用户的信息（否则可能不可用）。为防止此类攻击，应避免基于未经身份验证的ID的重定向，并且应仅在客户端自身进行身份验证后进行重定向。
This document defines three new IKEv2 Notify Message Types, as described in Section 9. The three Notify Message Types have been assigned the following values:
本文档定义了三种新的IKEv2通知消息类型，如第9节所述。已为三种通知消息类型分配了以下值：
16406 - REDIRECT_SUPPORTED
16406-支持重定向
16407 - REDIRECT
16407-重定向
16408 - REDIRECTED_FROM
16408-已从
This document creates a new namespace called the "Gateway Identity Type". This is used to indicate the type of information regarding the VPN gateway that is carried in the REDIRECT (Section 9.2) and REDIRECTED_FROM (Section 9.3) Notify payloads. The following values have been assigned.
本文档创建了一个名为“网关标识类型”的新名称空间。这用于指示重定向（第9.2节）和重定向（第9.3节）Notify有效载荷中携带的VPN网关相关信息的类型。已指定以下值。
1 - IPv4 address of the VPN gateway
1-VPN网关的IPv4地址
2 - IPv6 address of the VPN gateway
2-VPN网关的IPv6地址
3 - FQDN of the VPN gateway
3-VPN网关的FQDN
Value '0' is reserved. Values 4-240 are unassigned. New values can be allocated by Expert Review [8]. Values 241-255 are set aside for private use. A specification that extends this registry MUST also mention which of the new values are valid in which Notify payload.
值“0”是保留的。值4-240未赋值。专家评审可分配新值[8]。值241-255留作私人使用。扩展此注册表的规范还必须提到哪些新值在哪个Notify有效负载中有效。
The use of anycast addresses with IKEv2 was first proposed by K. Weniger and F. Dupont in the context of home agent assignment in Mobile IPv6 / Network Mobility (NEMO) bootstrapping. It was then added to an early version of [4] and later removed before the RFC was published. The authors of RFC 5026 are acknowledged.
K.Weniger和F.Dupont在移动IPv6/网络移动性（NEMO）引导中的归属代理分配的背景下，首次提出将选播地址用于IKEv2。然后将其添加到[4]的早期版本中，然后在RFC发布之前将其删除。RFC 5026的作者已被确认。
Thanks to Pasi Eronen, with whom the solution described in this document was extensively discussed. Thanks to Tero Kivinen for suggesting the use of the REDIRECTED_FROM payload and other comments that helped improve the document. The authors would also like to thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir, Richard Graveman, Kanagavel Rajan, Srini Addepalli, Raj Singh, and Arnaud Ebalard for their reviews and comments.
感谢Pasi Eronen，本文档中描述的解决方案与他进行了广泛的讨论。感谢Tero Kivinen建议使用来自有效负载的重定向_和其他有助于改进文档的注释。作者还要感谢亚龙·谢弗、苏尼尔·库马尔、范昭、约阿夫·尼尔、理查德·格拉维曼、卡纳加维尔·拉詹、斯里尼·阿德帕利、拉吉·辛格和阿诺·埃巴拉德的评论和评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[2] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[4] Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[5] Haley，B.，Devarapalli，V.，Deng，H.，和J.Kempf，“移动头归属代理切换消息”，RFC 51422008年1月。
[6] Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006.
[6] Eronen，P.和J.Korhonen，“互联网密钥交换（IKEv2）协议中的多重认证交换”，RFC 4739，2006年11月。
[7] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[7] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Vijay Devarapalli WiChorus 3590 North First St San Jose, CA 95134 USA
Vijay Devarapalli WiChorus 3590北第一圣何塞，加利福尼亚州95134
EMail: vijay@wichorus.com
EMail: vijay@wichorus.com
Kilian Weniger Unaffiliated
基连·韦尼格尔无关联
EMail: kilian.weniger@googlemail.com
EMail: kilian.weniger@googlemail.com