Subject: Re: [Mip6] MN-HA Reliability Work?

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Aug 2005 16:28:14 +0200

In your previous mail you wrote:

   Could you elaborate how you think this affects Qin's draft idea of having an
   HA be able to initiate the SA?
   
=> the I-D is draft-li-mip6-ha-init-bootstrap-00.txt, isn't it?

I can see some issues with the idea to get the HA as the initiator:
 - as I already wrote, current Mobike proposed protocol assumes the
   initiator is the mobile side, what I summaried by "the initiator decides"
 - IKEv2 itself has less facilities, for instance:
   * IDr from the initiator (shouldn't matter)
   * no EAP for the responder (this should really matter but EAP over IKEv2
     could be extended)
   * no CFG_REQUEST for the responder (this makes sense but should matter too)

Regards

[email-masked]

PS: IMHO it could be better to design some kind of callbacks in order
to launch IKE the "right way".

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Aug 2005 08:56:12 -0700

Your second issue seems a problem, especially the EAP part. I'm not
convinced that MIP necessarily needs to conform with Mobike, though.

Still, it would be useful if we could figure out some way to allow an HA
that is not the current HA to inform a MN that its current HA has gone down
unexpectedly.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Aug 2005 18:52:29 +0200

Your second issue seems a problem, especially the EAP part.

=> the EAP and CF_REQUEST were obviously designed with the
assumption the MN/VPN client is always the initiator...

   I'm not
   
=> I'm convinced that Mobike should conform with MIP in this case (:-).

=> I agree but it seems to reverse the way IKE is used is a bit too much.
Perhaps a new ICMP error to indicate a possible problem is the best solution:
the MN should check the previous is no more available and could get a hint
about the new HA from the ICMP message. In fact, the only reason we can't
reuse a standard unreachable is because we have no real extra info to put
in the message as the triggering packet... If we accept a synthetized BRR,
i.e., for instance:
 ICMP:
  src: new HA
  dst: MN CoA
  type: unreachable (1)
  code: address unreachable (3) ?
 embedded IPv6 "triggering" packet
  src: MN HoA
  dst: previous HA
  MH type: BRR (0)

(there is a problem with the previous HA, binding refreshed is needed,
the 4 involved addresses are in the message at not too stupid positions...)

Regards

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 21:30:04 +0900

Hi James

> that is not the current HA to inform a MN that its current HA has  

This is very limited scenario. Defining only signal is not efficient.

We should consider how to detect the failed HA and how to  know
the mobile nodes which the new HA must send the HAswitch message.
There is no scheme to know which mobile nodes are associated with  
which HA. (except for HAHA).

There are also several issues for this topic. Proxy ND consistency is  
one example.
Before a new HA receiving a new BU, the failed HA must be detached  
from the home link or
stop proxy ND for mobile nodes which bindings were registered on.   
Otherwise, DAD will be
occurred.

Your suggestion is just partial solution for the big problem.
I disagree to work on MN-HA reliability only without investigating  
the whole picture.

ryuji

>>    Could you elaborate how you think this affects Qin's draft idea of
>>
> having an
>
>>    initiator is the mobile side, what I summaried by "the initiator
>>
> decides"
>
>>    * no EAP for the responder (this should really matter but EAP over
>>
> IKEv2
>
>>      could be extended)
>>    * no CFG_REQUEST for the responder (this makes sense but should  
>> matter
>>
> too)
>
>>
>> Regards
>>