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

From: mayuzhi 03573 <[email-masked]>
Date: Tue, 18 Oct 2005 09:43:48 +0800

Dear  all,
  I have submitted a new internet draft to the mip6 working group. Abstract of this draft is as follow:
Any node communicating with a mobile node in Mobile IPv6 is referred to as a "correspondent node" of the mobile node, and may itself be 
either a stationary node or a mobile node. Communication between mobile nodes has additional complexity. This document specifies a 
solution to improve communication procedure between mobile nodes.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yuchi-mip6-mntomn-improve-00.txt

 I would appreciate any feedback and comments.

Regards,
Yuzhi Ma

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

---

From: Brian Haley <[email-masked]>
Date: Tue, 18 Oct 2005 00:53:23 -0400

>  I would appreciate any feedback and comments.

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.

>    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.

>     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.

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.

> 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.

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.

-Brian