Subject: Re:[mip6]draft-yuchi-mip6-mntomn-improve-00

From: mayuzhi 03573 <[email-masked]>
Date: Tue, 18 Oct 2005 16:28:40 +0800

Hi Brian,
Thanks for you comments. Please find my inline response.

Brian Haley wrote:
>Hi Yuzhi,

>I read your draft about improving MN to MN communications, it seems like 
>a simple thing to implement for certain cases.

>A few comments:

> 3.1. Mobile Correspondent Node 
> 
>    In order to differentiate between the two communicating mobile nodes, 
>    a new concept called "mobile correspondent node" is introduced.

>I don't really like yet another name for a mobile node, you could just 
>refer to it as the stationary mobile node.

According to the Mobile IPv6 basic protocol, A mobile node has dual nature when it communicates with another 
mobile node. Sometimes its role is mobile node, and sometimes its role is correspondent node. 
The dual role result in additional complexity .It is necessary that the role between two communicating mobile nodes
should be differentiated. I think the "stationary mobile node" may not distinctly differentiate the roles.

>    The 
>    initiator of a correspondent registration acts as a mobile node, and 
>    the receiver acts as a mobile correspondent node. The receiver SHOULD 
>    NOT initiate a correspondent registration for the initiator, and both 
>    sides SHOULD maintain this relationship in future communication. A 
>    mobile correspondent node SHOULD inform the mobile node of its new 
>    address, when it moves to a new link. The method for doing this is 
>    specified below.

>Doesn't this SHOULD NOT disable route optimization?  If I'm a MN at home 
>with a binding for another MN I'm communicating with, then move to a new 
>link, I'd want to send a binding update instead of reverse-tunneling.

I mean once their relationship has set up, a mobile correspondent node SHOULD NOT initiate a correspondent registration for the moblie node . But it can initiate a correspondent registration for third moblie node. 

>     A new option called "Correspondent Address Option" is defined for 
>     the BRR message. This option is used to carry the correspondent 
>     address and its format is: 
>      
>        0                   1                   2                   3 
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>                                        |   Type = TBD    |  Length = 16| 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>        |                                                               | 
>        +                                                               + 
>        |                                                               | 
>        +                   Correspondent Address                       + 
>        |                                                               | 
>        +                                                               + 
>        |                                                               | 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

>You should probably state the alignment necessary for this option:

>     The Correspondent Address option has an alignment requirement of
>     8n+6.

Accepted

>Or maybe it would be easier to just extend the definition of the 
>Alternate Care-of Address option already defined in 3775 so it can be 
>used for multiple purposes?  Just a thought.

If it dosn't bring additional confusion, I think this is a good idea.

> 4.3. Mobile Node Operations 
> 
>    When a mobile node receives a BRR message containing a correspondent 
>    address option and the mobile node has a Binding Update List entry 
>    for the address carried by the option, then the mobile node should 
>    start the return routability procedure which is sent to the source of 
>    the BRR message. If the mobile node has a Binding Update List entry 
>    for the source of the BRR, then the mobile node should start the 
>    return routability procedure which is sent to the address carried by 
>    the correspondent address option. 

>I don't think the stationary MN would need to do RR in all cases, it 
>would depend on whether or not it's tokens have expired.  The only 
>message that would have to be sent would be the CoTI from the MN that 
>just moved (and the subsequent CoT).  Section 11.6.1 of 3775 describes 
>this better than I can.

Yes, I agree. Some limit condition should be added in this section. 
I will consider it.

>And to address security concerns, you should use all-caps keywords, for 
>example:

>      Upon receipt of a BRR message containing a correspondent address
>      option, the node MUST verify that there is a corresponding binding
>      update list entry for the address before starting the Return
>      Routability procedure (if necessary), otherwise the packet MUST be
>      dropped.

Accepted

>-Brian

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

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 18 Oct 2005 18:01:46 +0900

IMHO, what is needed to express this scenario is a state machine - not
a new entity name.

Thierry.

On Tue, 18 Oct 2005 16:28:40 +0800
mayuzhi 03573 <[email-masked]> wrote:

> >I read your draft about improving MN to MN communications, it seems
> >like a simple thing to implement for certain cases.
> 
> >A few comments:
> 
> >    In order to differentiate between the two communicating mobile
> >    nodes, a new concept called "mobile correspondent node" is
> >    introduced.
> 
> >I don't really like yet another name for a mobile node, you could
> >just refer to it as the stationary mobile node.
> 
> According to the Mobile IPv6 basic protocol, A mobile node has dual
> nature when it communicates with another mobile node. Sometimes its
> role is mobile node, and sometimes its role is correspondent node. The
> dual role result in additional complexity .It is necessary that the
> role between two communicating mobile nodes should be differentiated.
> I think the "stationary mobile node" may not distinctly differentiate
> the roles.
> 
> 
> >    The 
> >    initiator of a correspondent registration acts as a mobile node,
> >    and the receiver acts as a mobile correspondent node. The
> >    receiver SHOULD NOT initiate a correspondent registration for the
> >    initiator, and both sides SHOULD maintain this relationship in
> >    future communication. A mobile correspondent node SHOULD inform
> >    the mobile node of its new address, when it moves to a new link.
> >    The method for doing this is specified below.
> 
> >Doesn't this SHOULD NOT disable route optimization?  If I'm a MN at
> >home with a binding for another MN I'm communicating with, then move
> >to a new link, I'd want to send a binding update instead of
> >reverse-tunneling.
> 
> I mean once their relationship has set up, a mobile correspondent node
> SHOULD NOT initiate a correspondent registration for the moblie node .
> But it can initiate a correspondent registration for third moblie
> node. 
> 
> 
> >     A new option called "Correspondent Address Option" is defined
> >     for the BRR message. This option is used to carry the
> >     correspondent address and its format is: 
> >      
> >        0                   1                   2                   3
> >        
> >                                        |   Type = TBD    |  Length =
> >                                        |   16| 
> >        |                                                          
    | 
> >        +                                                            
> >          + 
> >        |                                                          
    | 
> >        +                   Correspondent Address                    
> >          + 
> >        |                                                          
    | 
> >        +                                                            
> >          + 
> >        |                                                          
    | 
> >    When a mobile node receives a BRR message containing a
> >    correspondent address option and the mobile node has a Binding
> >    Update List entry for the address carried by the option, then the
> >    mobile node should start the return routability procedure which
> >    is sent to the source of the BRR message. If the mobile node has
> >    a Binding Update List entry for the source of the BRR, then the
> >    mobile node should start the return routability procedure which
> >    is sent to the address carried by the correspondent address
> >    option. 
> 
> >And to address security concerns, you should use all-caps keywords,
> >for example:
> 
> >      Upon receipt of a BRR message containing a correspondent
> >      address option, the node MUST verify that there is a
> >      corresponding binding update list entry for the address before
> >      starting the Return Routability procedure (if necessary),
> >      otherwise the packet MUST be dropped.
> 
> Accepted
> 
> >-Brian
> 
> 
>