Subject: [Monami6] Draft Update: Failover for multiple mobile routers

From: Jiho Ryu <[email-masked]>
Date: Tue, 14 Mar 2006 19:29:23 +0900

Hi all,

We submitted the updated version of our draft, the failover for multiple
mobile routers in a mobile network.

In this draft, the fault tolerance of a multihomed mobile network is
provided considering the (n,1,n) and (n,n,n) scenarios of Analysis of
Multihoming in NEMO draft.
We expect that our proposed scheme will be useful when the multiple mobile
routers exist.

http://www.ietf.org/internet-drafts/draft-ryu-nemo-mr-failover-01.txt

Here is an abstract:

This draft proposed the use of multiple mobile routers in a single
NEMO. A failed mobile router is taken over by another mobile router
using "prefix peer" relationship among mobile routers in a NEMO.
"prefix peer" relationship enables a mobile router's prefix to be
handled by another mobile router.

Any questions and comments are welcome at anytime.  :-) 

Regards
Jiho.

-- 
Ryu, Jiho
Master Course
Multimedia and Mobile Communications Lab.,
School of Computer Science and Engineering
Seoul National University

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

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 14 Mar 2006 13:01:02 +0200

Hi all,

I'm having some problems understanding the B flag in:

http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-05.txt

4.3.1. says:

     "When this flag is set, a mobile node can piggyback several Care-of
     Addresses into a binding update.  The mobile node must use a
     Care-of Address stored in an alternate Care-of Address sub-option
     followed by the Binding Unique Identifier sub-option."

Okay so far, but then:

5.5. says:

   "If the B flag is unset in a Binding Unique Identifier
   sub-option, the BID in a Binding Unique Identifier sub-option is
   assigned for the Care-of Address in the Alternate Care-of Address
   sub-option."

6.2. says:

     "*  If the B flag is not set in the Binding Unique Identifier sub-
         option, the Care-of Address must be taken from the Source
         Address field of the IPv6 header."

For me it seems that there is a contradiction, or?

-- 
Tero Kauppinen                                 Tel: +358 9 299 3057
Research Scientist, NomadicLab, IP Networks,   Fax: +358 9 299 5055
Ericsson Research, Corporate Unit.             Mobile: +358 40 590 7560
Oy L M Ericsson Ab
mailto:[email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Mar 2006 22:12:31 +0900

Dear Tero

This is typo. 
Section 5.5 should be changed to "If the B flag is set in...".

The idea is when B flag is set, each CoA is in AltCoA option.
If not, CoA is just taken from the source address field of the IPv6 header.

I'll fix this at the next version.

thanks
ryuji

At Tue, 14 Mar 2006 13:01:02 +0200,

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Thu, 16 Mar 2006 15:59:11 +0200

Hello Ryuji,

> If not, CoA is just taken from the source address field of the IPv6 header.

I see. What about the following case which is perfectly legal according 
to the RFC 3775:

+----+------+-----------+
| BU | ACoA | BID (B=0) |
+----+------+-----------+

Is there a need to put a restriction into the draft which limits the 
order of the options?

Also, in the case of deregistration the MN might send a packet with only 
one ACoA option. This would result in the following packet:

+----+-----------+------+
| BU | BID (B=1) | ACoA |
+----+-----------+------+

So, there is only one CoA even though the bulk registration flag is set.
What I'm trying to say is that maybe the B-flag description ("When this 
flag is set, a mobile node can piggyback several Care-of Addresses into 
a binding update.") is a little misleading, because it in essence means 
only that the ACoA option is to follow the BID option.

If I have interpreted correctly the meaning, what about substituting 
"Bulk Registration" with "ACoA follows"?

Regz,
Tero

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Fri, 17 Mar 2006 13:40:21 +0200

> I'll fix this at the next version.

Hi again,

I started thinking about the case of multiple Alternate Care-of Address 
options when a legacy node receives the packet. The RFC 3775 does not 
explicitly state what should happen if such a packet is received, i.e. 
should it be considered as an error or should only the first or the last 
be taken into account. Anyway, if we want to insure interoperability in 
  the case of a legacy node, we might want to code additional AltCoA 
options in such a way that they are ignored.

I'm not sure if we want to add more complexity to the protocol by 
defining a new option ... and thus it's just a thought.

-- 
Tero

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 21:34:26 +0900

Hi Tero

On 2006/03/16, at 22:59, Tero Kauppinen (JO/LMF) wrote:

> Hello Ryuji,
>
> Ryuji Wakikawa wrote:
>> Dear Tero
>> This is typo. Section 5.5 should be changed to "If the B flag is  
>> set in...".
> I see. What about the following case which is perfectly legal  
> according to the RFC 3775:
>
> Is there a need to put a restriction into the draft which limits  
> the order of the options?

good point.
In such case, the source address should be taken from the ACOA.

> Also, in the case of deregistration the MN might send a packet with  
> only one ACoA option. This would result in the following packet:
>

To me, this should be valid.

> What I'm trying to say is that maybe the B-flag description ("When  
> this flag is set, a mobile node can piggyback several Care-of  
> Addresses into a binding update.") is a little misleading, because  
> it in essence means only that the ACoA option is to follow the BID  
> option.
>
> If I have interpreted correctly the meaning, what about  
> substituting "Bulk Registration" with "ACoA follows"?

I think your interpretation is correct.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 21:37:13 +0900

Hi Tero

MIP6 spec does not prohibit to send multiple ACoA options in a single  
BU.
It depends on implementation, but the last one will be picked in our  
implementation (KAME SHISA).

ACoA option is used for different purpose, so defining a new CoA  
option is possible.
It is open for WG. I just re-use the ACoA to limit the MIP6 extension  
as much as possible.

thanks
ryuji

On 2006/03/17, at 20:40, Tero Kauppinen (JO/LMF) wrote:

> I started thinking about the case of multiple Alternate Care-of  
> Address options when a legacy node receives the packet. The RFC  
> 3775 does not explicitly state what should happen if such a packet  
> is received, i.e. should it be considered as an error or should  
> only the first or the last be taken into account. Anyway, if we  
> want to insure interoperability in  the case of a legacy node, we  
> might want to code additional AltCoA options in such a way that  
> they are ignored.
>

---

From: Martti Kuparinen <[email-masked]>
Date: Tue, 21 Mar 2006 15:30:04 +0200

Ryuji Wakikawa wrote:
> Hi Tero
> 
> MIP6 spec does not prohibit to send multiple ACoA options in a single  BU.

Same here, we take the last ACoA option but there might be implementations which
pick the first one. If this happens the Binding Authorization Data does not match...

Martti

---

From: Brian Haley <[email-masked]>
Date: Tue, 21 Mar 2006 11:15:00 -0500

> pick the first one. If this happens the Binding Authorization Data does not match...

HP's homegrown implementations do the same, but I don't think the Linux 
MIPL code does, I'll look into that so it's consistent.

-Brian

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 27 Mar 2006 13:07:48 +0900

Dear Ryuji,

> Section 5.5 should be changed to "If the B flag is set in...".

I don't think this is a typo. The context is different in each case, and 
section 5.5 explains when AlCoA option can be used. In that case:

refers to the case where you send BU for a specific CoA via an interface 
whose CoA is different (thus you need AltCoA). So what is stated is 
correct: if the B flag is unset, then the correspondant has to look for 
an AltCoA before taking the CoA from the source address.

But I have a concern with the place where the AltCoa should be put: 
before or after Binding Unique ID sub-option? This is not clear:

- in section 4.3:
  "The mobile node must use a
   Care-of Address stored in an alternate Care-of Address sub-option
   followed by the Binding Unique Identifier sub-option."

- in section 5.5:
  "If the B flag is set, the BID in a Binding Unique
   Identifier sub-option is assigned for the Care-of Address in the
   followed Alternate Care-of Address sub-option."

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Mon, 27 Mar 2006 11:43:35 +0300

Romain KUNTZ wrote:
> Dear Ryuji,
> 
> Ryuji Wakikawa wrote:
>> This is typo. Section 5.5 should be changed to "If the B flag is set 
>> in...".
> 

Hello,

Okay, so whenever the AltCoA option is present the information in the 
option will be used. Right? I think in that case the paragraph in 6.2.:

*  If the B flag is not set in the Binding Unique Identifier sub-
    option, the Care-of Address must be taken from the Source
    Address field of the IPv6 header.

should say something like:

*  If the B flag is not set in the Binding Unique Identifier sub-
    option, the Care-of Address is taken from the Alternate
    Care-of Address sub-option. If the Alternate Care-of Address
    sub-option is not present, the Care-of Address must be taken
    from the Source Address field of the IPv6 header.

In addition it should be specified where the AltCoa "should be put", 
i.e. before or after.

Regards,
Tero

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 01:02:01 +0900

Hi Tero

On 2006/03/27, at 17:43, Tero Kauppinen (JO/LMF) wrote:

>> I don't think this is a typo. The context is different in each  
>> case, and section 5.5 explains when AlCoA option can be used. In  
>> that case:
>> refers to the case where you send BU for a specific CoA via an  
>> interface whose CoA is different (thus you need AltCoA). So what  
>> is stated is correct: if the B flag is unset, then the  
>> correspondant has to look for an AltCoA before taking the CoA from  
>> the source address.
>
> Hello,
>
> Okay, so whenever the AltCoA option is present the information in  
> the option will be used. Right? I think in that case the paragraph  
> in 6.2.:
>

Yes for Home Registration:-)

ryuji

> In addition it should be specified where the AltCoa "should be  
> put", i.e. before or after.
>
>> But I have a concern with the place where the AltCoa should be  
>> put: before or after Binding Unique ID sub-option? This is not clear:
>> - in section 4.3:

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 29 Mar 2006 09:39:39 +0300

Ryuji Wakikawa wrote:
>>> I don't think this is a typo. The context is different in each case, 
>>> and section 5.5 explains when AlCoA option can be used. In that case:
>>> interface whose CoA is different (thus you need AltCoA). So what is 
>>> stated is correct: if the B flag is unset, then the correspondant has 
>>> to look for an AltCoA before taking the CoA from the source address.
>>
>> Hello,
>>

I'm sorry, but I don't get it. Are you saying that the Alternate Care-of 
Address sub-option is not included in Binding Updates sent to the CN?

/Tero

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 16:01:43 +0900

At Wed, 29 Mar 2006 09:53:48 +0300,
Tero Kauppinen (JO/LMF) wrote:
> 
> Ryuji Wakikawa wrote:
> > At Wed, 29 Mar 2006 09:39:39 +0300,
> > ??
> > RFC3775 said ACoA is required only for home registration.
> 
> 9.  Correspondent Node Operation
> 9.5.1.  Receiving Binding Updates
> 
>     The specified care-of address MUST be determined as follows:
> 
>     o  If the Alternate Care-of Address option is present, the care-of
>        address is the address in that option.
> 
>     o  Otherwise, the care-of address is the Source Address field in the
>        packet's IPv6 header.
> 
> What does this mean?

You can set an ACoA option in the BU for CN, but not MUST.
ACoA is used to protect CoA since ESP doesn't protect Source address.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 15:51:09 +0900

??

ryuji

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 29 Mar 2006 09:53:48 +0300

What does this mean?

/Tero

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 29 Mar 2006 10:10:21 +0300

> You can set an ACoA option in the BU for CN, but not MUST.

True, but I think I have not said that it is a MUST, I'm just saying 
that it might be included. I believe that is exactly what the following 
says:

"the Care-of Address is taken from the Alternate Care-of Address 
sub-option. If the Alternate Care-of Address sub-option is not present, 
the Care-of Address must be taken from the Source Address field of the 
IPv6 header."

i.e. use the Alternate Care-of Address option if present, otherwise use 
the Source Address field.

However, I believe we both are now pretty much on the same "frequency". 
If you get my meaning :)

/Tero

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 16:14:36 +0900

On 2006/03/29, at 16:10, Tero Kauppinen (JO/LMF) wrote:

>
>>>>> I'm sorry, but I don't get it. Are you saying that the  
>>>>> Alternate Care-of Address sub-option is not included in Binding  
>>>>> Updates sent to the CN?
>>>> ??
>>>>
> True, but I think I have not said that it is a MUST, I'm just  
> saying that it might be included. I believe that is exactly what  
> the following says:
>
> sub-option. If the Alternate Care-of Address sub-option is not  
> present, the Care-of Address must be taken from the Source Address  
> field of the IPv6 header."
>
> i.e. use the Alternate Care-of Address option if present, otherwise  
> use the Source Address field.
>
> However, I believe we both are now pretty much on the same  
> "frequency". If you get my meaning :)

I got your point now :-)

thanks
ryuji