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)
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.
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.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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
Devarapalli & Weniger Standards Track [Page 1]
RFC 5685 IKEv2 Redirect November 2009
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.
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
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