Subject: Re: [mobile-ip] current issue situation

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 09 Jul 2002 11:14:36 +0900 (JST)

I'm sorry I may have missed the discussion.

From: Jari Arkko <[email-masked]>

> 45 Adopted   HAO keyword same as for RO or MUST?

Let me confirm the conclusion.

As I have said in the mailing-list before, there are four types of
CNs. (Sorry for the duplicated explanation.)

CN0:  has no special MIP6 processing code.
CN1:  processes HAO only if it is protected (by IPsec).
CN2:  processes HAO only if it is protected (by IPsec)
      and accepts a BU only if it is protected (by IPsec).
CN3:  does RR
      and processes HAO if it is verified
      and accepts a BU if it is protected (by RR).

Vijay suggested CN2 capability for all CNs.  There seems no one has
any objection for this.  This means all the IPv6 node must support the
binding cache management (= RO) if the BU/HAO is protected by the
IPsec.  Is it WG consecsus?

http://www.piuha.net/~jarkko/publications/mipv6/issues/issue45.txt

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Joe Lau <[email-masked]>
Date: Thu, 11 Jul 2002 16:14:21 -0700 (PDT)

Hello,

I found some minor inconsistencies and editorial improvements in the 
MIPv6 ID-18 draft.  I am not sure if those itmes have been reported 
before by other people.

Regards,

Joe Lau

-------------------------------------------------------------------------

1. Unique Identifier option allowed on Home Test Init and Care-of Test Init?

   Page 25:
      Mobility options
                                                              ....  This
         specification does not define any options valid for the Home
         Test Init message.
   
   Page 26:
      Mobility options
							      ...   This
         specification does not define any options valid for the Care-of
         Test Init message.

   Page 119:
   If the Binding Refresh Request for which the Binding Update is being
   returned contains a Unique Identifier mobility option, the resulting
   Home Test Init, Care-of Test Init, and Update messages MUST also
   include a Unique Identifier mobility option. 

2. Whether Home Address destination option MUST be included in BUs sent to HA.

   Page 12: 
  	 ...  In order for the home address of the mobile node to be
   visible when the policy check is made, the mobile node MUST use the
   Home Address destination option in Binding Updates sent to the home
   agent.

   Page 116: 
    -  The Home Address destination option MUST be attached to the
       message, unless the Source Address is the home address of the
       mobile node. 

   Page 121 (Returning Home):					 
 							    ... The
   mobile node MUST NOT include a Home Address option in this Binding
   Update.

   It would be nice to have a single statement on when Home Address destination
   option MUST be and when MUST NOT be included in BUs sent to HA. 

3. Purpose of Home Test Init.

   Page 16:
    The mobile node sends a Care-of Test Init message to the
    correspondent node to acquire the care-of cookie.

   But the draft does not state:
    The mobile node sends a Home Test Init message to the
    correspondent node to acquire the home cookie.

4. Binding Authorization Data option is valid for what messages? 

   Page 39:

   The Binding Authorization Data option is valid only in the Binding
   Refresh Request, Binding Update, and Binding Acknowledgment messages.

   [then later, the draft says:]

   				...  For this procedure, this option
   can only appear in a Binding Update message and rules for calculating
       ^^^^
       ????
   the Authenticator value are described in Section 6.1.7.
                                                    ^^^^^
                                                    5.2.6

5. Sequence number modulo arithmatics (15 or 16?) 
   
   Page 64: 2**15
   Page 67: 2**16 
   Page 92: 2**15 
   Page 116: 2**16
   Page 131: 2**15 

6. Duplicated text (about 57 lines)

   Page 100:
			 	    ... On receipt of a valid Router
   Advertisement, as defined in the processing algorithm specified for
   Neighbor Discovery [12], the mobile node performs the following
   steps, in addition to any steps already required of it by Neighbor
   Discovery.

    -  If the Home Agent (H) bit in the Router Advertisement is not set,
       and the sending node currently has an entry in the node's Home
       Agents List, delete the corresponding entry.  Subsequently, skip
       all of the following steps.

    ....

   A mobile node SHOULD maintain an entry in its Home Agents List for
   each such valid home agent address until that entry's lifetime
   expires, after which time the entry MUST be deleted.
   --------------------------------------------------------------------

   The above block of text is almost identical to that on page 84.
   Duplicated text suffers the same problem as duplicated code in programming.

7. Duplicated text

   Page 124:

   11.6.9. Rate Limiting Binding Updates

   A mobile node MUST NOT send Binding Update messages for the
   same binding to any individual node more often than once per
   MAX_UPDATE_RATE seconds.  After sending MAX_FAST_UPDATES consecutive
   messages to a particular node with the same care-of address, the
   mobile node SHOULD reduce its rate of sending these messages to that
   node, to the rate of SLOW_UPDATE_RATE per second.  The mobile node
   MAY continue to send these messages at this slower rate indefinitely,
   in hopes that the node will eventually be able to process a Binding
   Update, and begin to route its packets directly to the mobile node at
   its new care-of address.
   ---------------

   The above block of text is almost identical to that on pag 111.
   It would be nice to have a single paragraph on Rate limiting procedure.

3. Typo error

   Page 15:

    					Due to the nearly simultaneous
   message delivery, the return routability procedure completes in about
   roundtrip between the mobile node and the correspondent.
   ^^^^^^^^^
   How many?

7. Typo error.

   Page 91:
   The rules for maintaining a Home Agents List are same for home agents
   and correspondent nodes, and have been described in Section 10.1.
       ^^^^^^^^^^^^^^^^^^^
          mobile nodes

   		      ...Note that the mobile node SHOULD NOT respond
   Binding Requests from previously unknown correspondent nodes due to ...
          ^
        Refresh

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 03:32:22 +0300

Thanks Joe for your feedback, it is appreciated! Assigned issue #64.
Comments inline.

>    include a Unique Identifier mobility option. 

We missed this. Page 119 is wrong.

>    option MUST be and when MUST NOT be included in BUs sent to HA. 

Yes. Page 116 is right in this case...

>     correspondent node to acquire the home cookie.

But it does! See bullet item 1a above the point you cite.

>    can only appear in a Binding Update message and rules for calculating

The intention was to allow for the Authz Data suboption to be possible on
other messages as well, if some need would arise later. Just that for the
RR procedure, the only one defined now, would use it for BUs and BAs.

But I see now that this is just confusing. Let's clarify that it should be
present in CN BUs and BAs.

>    the Authenticator value are described in Section 6.1.7.

Ok, will be fixed.

> 5. Sequence number modulo arithmatics (15 or 16?) 

Great... I thought we had fixed these. It's 2**16, following the
terminology in e.g. TCP RFC.

>    expires, after which time the entry MUST be deleted.

Right. Let's refer from page 100 to page 84, or put this "code" on its own
little section somewhere.

>    Update, and begin to route its packets directly to the mobile node at

Yes, let's do it.

>    roundtrip between the mobile node and the correspondent.

a single roundtrip. should be fixed.

>    and correspondent nodes, and have been described in Section 10.1.

Right. Thanks.

Jari