Subject: [MEXT] [Fwd: I-D Action:draft-krishnan-mext-ha-redirect-00.txt]

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Feb 2008 13:37:40 -0500

Hi Folks,
   We submitted a draft about redirecting MNs to other HAs for overload 
prevention, load balancing or other purposes. We would appreciate any 
comments and suggestions on this document.

Thanks
Authors

-------- Original Message --------
Subject: I-D Action:draft-krishnan-mext-ha-redirect-00.txt
Date: Wed, 13 Feb 2008 10:30:01 -0800 (PST)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Redirecting Binding Updates in MIPv6
	Author(s)       : S. Krishnan, et al.
	Filename        : draft-krishnan-mext-ha-redirect-00.txt
	Pages           : 9
	Date            : 2008-02-13

This document specifies a new Home Agent Redirect mechanism, where an
initially contacted Home Agent can let the Mobile Node knows that it
needs to connect to an alternate Home Agent to get mobility services
for overload prevention and/or load balancing purposes.  This
document proposes a new error code for the binding acknowledgement
message and a new mobility option to be carried on the binding
acknowledgement message for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnan-mext-ha-redirect-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-krishnan-mext-ha-redirect-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-krishnan-mext-ha-redirect-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 14 Feb 2008 14:54:28 +0000

Hi Suresh,

Your proposal seems to be based on the fact that RFC5142 (HA-switch)
is not sufficient since it only works for MNs already registered in
the HA. You argue then that an HA should be able to redirect an MN
during initial registration (to which I agree).
So, while this sounds reasonable, when IPSEC is used to secure MIP6
signaling, would it not make more sense to get this information
earlier? e.g., during the IKEv2 exchange?

It is also worth noting that depending what kind of bootstrapping
mechanism used the MN may already know a number of alternative HAs, in
which case a BA with appropriate status (e.g., 130 Insufficient
resources) would also work.

Again, however, I am not saying that your suggestion is wrong, but
that it is possibly applied to the wrong protocol.

Thoughts?
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 14 Feb 2008 08:58:03 -0800

> that it is possibly applied to the wrong protocol.

Agree. When RFC 5026 was being standardized, there was proposal
to re-direct the mobile node during the IKEv2 exchange using
IKEv2 anycast addresses. There were some issues found with the
mechanism during the IESG review. It was about the destination
address on the outgoing IKE_SA_INIT (anycast address) not
matching the source address of the IKE_SA_INIT response (unicast
address of the selected HA). Firewalls or NATs could drop these
packets. So it was removed from the document during the IESG
review.

In some offline discussions, it was decided to move that mechanism
to a separate draft and also introduce an explicit REDIRECT payload
in the IKE_SA_INIT response from an anycast address. I was supposed
to have submitted this document months ago, but due to various
reasons, I haven't yet. I am planning to submit it by this Monday.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 19 Feb 2008 17:59:31 +0100

Hi Suresh,

Yet another alternative (in addition to what George and Vijay already suggested) would be: the HA could accept the initial BU, send BAck with the very short lifetime and then send the HA switch message. Using this method the HA would still be able to get rid of the MN in a matter of seconds. Though not very elegant. 

regards
domagoj

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: 14. veljaca 2008 17:58
> To: George Tsirtsis
> Cc: [email-masked]
> Subject: Re: [MEXT] [Fwd: I-D 
> Action:draft-krishnan-mext-ha-redirect-00.txt]
> 
> George Tsirtsis wrote:
> > Hi Suresh,
> > 
> Agree. When RFC 5026 was being standardized, there was 
> proposal to re-direct the mobile node during the IKEv2 exchange using
> IKEv2 anycast addresses. There were some issues found with 
> the mechanism during the IESG review. It was about the 
> destination address on the outgoing IKE_SA_INIT (anycast 
> address) not matching the source address of the IKE_SA_INIT 
> response (unicast address of the selected HA). Firewalls or 
> NATs could drop these packets. So it was removed from the 
> document during the IESG review.
> 
> In some offline discussions, it was decided to move that 
> mechanism to a separate draft and also introduce an explicit 
> REDIRECT payload in the IKE_SA_INIT response from an anycast 
> address. I was supposed to have submitted this document 
> months ago, but due to various reasons, I haven't yet. I am 
> planning to submit it by this Monday.
> 
> Vijay
> 
> > George
> > 
> >>    We submitted a draft about redirecting MNs to other HAs for 
> >> overload  prevention, load balancing or other purposes. We would 
> >> appreciate any  comments and suggestions on this document.
> >>
> >>  Thanks
> >>  Authors
> >>
> >>  This document specifies a new Home Agent Redirect 
> mechanism, where 
> >> an  initially contacted Home Agent can let the Mobile Node 
> knows that 
> >> it  needs to connect to an alternate Home Agent to get mobility 
> >> services  for overload prevention and/or load balancing purposes.  
> >> This  document proposes a new error code for the binding 
> >> acknowledgement  message and a new mobility option to be 
> carried on 
> >> the binding  acknowledgement message for this purpose.
> >>
> >> [email-masked] with the word unsubscribe in 
> the body 
> >> of  the message.
> >>  You can also visit 
> >> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >> http://www.ietf.org/shadow.html  or 
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>         "FILE 
> /internet-drafts/draft-krishnan-mext-ha-redirect-00.txt".
> >>