Protocol Action: 'Redirect Mechanism for IKEv2' to Proposed Standard

The IESG <> Thu, 17 September 2009 16:23 UTC

Return-Path: <>
Received: by (Postfix, from userid 30) id 15EF228C29E; Thu, 17 Sep 2009 09:23:19 -0700 (PDT)
X-idtracker: yes
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Redirect Mechanism for IKEv2' to Proposed Standard
Message-Id: <>
Date: Thu, 17 Sep 2009 09:23:20 -0700
Cc: ipsecme mailing list <>, ipsecme chair <>, Internet Architecture Board <>, RFC Editor <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Sep 2009 16:23:20 -0000

The IESG has approved the following document:

- 'Redirect Mechanism for IKEv2 '
   <draft-ietf-ipsecme-ikev2-redirect-13.txt> as a Proposed Standard

This document is the product of the IP Security Maintenance and Extensions Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:

Technical Summary

This document defines a redirect mechanism for IKEv2. The main use
case is scalability of large deployments of remote access VPN gateways. 
The proposed mechanism can also be used in Mobile IPv6, where
signaling is protected by IKE/IPsec, to support the home agent in 
redirecting the mobile node to another home agent.

Working Group Summary

The document represents the consensus opinion of the ipsecme WG.

Document Quality

We are not aware of any implementations, and no vendors have announced
implementation plans.


   Yaron Sheffer is the Document Shepherd for this document.  Tim Polk
   is the Responsible Area Director.  The IANA Expert for the Gateway
   Identity Type registry (created by this document) is Tero Kivinen.

RFC Editor Note

Please append the following text as a new paragraph at the end of Section

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, and 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.