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

["Premec, Domagoj" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Vijay Devarapalli
> Sent: 14. veljaca 2008 17:58
> To: George Tsirtsis
> Cc: [e-mail]
> Subject: Re: [MEXT] [Fwd: I-D 
> Action:draft-krishnan-mext-ha-redirect-00.txt]
> 
> George Tsirtsis wrote:
> > 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?
> 
> 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
> > 
> > On Wed, Feb 13, 2008 at 6:37 PM, Suresh Krishnan 
> > <[e-mail]> wrote:
> >> 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: [e-mail]
> >>  Reply-To: [e-mail]
> >>  To: [e-mail]
> >>
> >>  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-0
> >> 0.txt
> >>
> >>  To remove yourself from the I-D Announcement list, send a 
> message to  
> >> [e-mail] 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:
> >>         [e-mail].
> >>  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
> >>  [e-mail]
> >>  http://www.ietf.org/mailman/listinfo/mext
> >>
> >>
> > _______________________________________________
> > MEXT mailing list
> > [e-mail]
> > http://www.ietf.org/mailman/listinfo/mext
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mext