Subject: [mobile-ip] Re: MIPv6 - 17 Review (Fixed tabs, please ignore earlier mail)

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Jun 2002 00:30:41 +0300

Many thanks Krishna for your in-depth review! Filed the technical
and editorial issues as #40 and #41, then created #42 and #43 for
two of the technical issues that may be perhaps best discussed
separately.

Comments inline below:

> 1. Section 6.1.3 : The Header Len value is incorrect if the option is present.
>    According to the draft, the size would be 2 + size of mobility options in
>    8 octets = 2 + 1 = 3. In reality, the packet would be 12 bytes long till the
>    options, and since the UID aligns at offset of 2n (and 12 happens to be a
>    multiple of 2n), the UID option will fit right at the end of the Message Data
>    field of the MH. So total length is 12 + 4 = 16 bytes = 2 (and not 3). The
>    draft should definitely change the statement to something like :
> 
>    "The Header Length field in the Mobility Header for this message MUST be
>    set to 12 bytes + the length of padding if necessary before possible 
>    options + the total length of all mobility options present, divided by 8,
>    to give a value in units of 8. If no actual options are present in this
>    message, 4 bytes of padding is necessary."

Yes. You know, maybe it's best if we delete the length discussion
from the individual messages, given that it is already described in

the definition of Mobility Header itself. I'll clarify the treatment

of padding there as well. (It may make sense to still mention
how much padding is needed if no options are present.)

> 2. Section 6.1.4 : Same as #1 above.

Yes.

>    Section 6.1.8 happens to be correct in this respect due to following
>    magic :
> 	a. different alignment of option, AND
> 	b. different length of the option. (2 bytes extra in both
> 	   adding to 4 bytes).
> 
> 3. Section 6.1.7 :
> 
>    Clarify in following para, that the address is the Home Address :
> 
>    "When a packet contains both a Home Address destination option and a
>    Binding Update message, the sender MUST use the same *home* address
>    in both."

Yes.

> 4. Section 6.1.8 :
> 
>    In the third last para, the following line :
> 
>    "If no actual options are present in this message, 4 bytes of Pad1 or
>     PadN mobility options are needed"
> 
>    The " 4 bytes of Pad1 or" should be removed, since Section 6.2.2
>    prohibits using multiple Pad1 options.

Fixed.

> 5. Section 6.2.3 :
> 
>    "For N octets of padding, the Option Len field contains the value N ,
>    and the Option Data consists of N-2 zero-valued octets."
> 
> 		should be changed to :
> 
>    "For N octets of padding, the Option Len field contains the value N - 2,
>    and the Option Data consists of N-2 zero-valued octets."
> 
>    This is as per description of Option Len in 6.2.1.

Fixed, see also issue #24 that was brought up later.

> 6. Section 6.2.4 :
> 
>    "2   4   Unique Identifier" should be change to "2   2   Unique Identifier".

>
> 7. Section 6.2.5 :
> 
>    "3   18" should be changed to "3   16"
> 
> 8. Section 6.2.6 :
> 
>    "4   6" should be changed to "4    4"
> 
> 9. Section 6.2.7 :
> 
>    "5   2 + Len" should be changed to "5    Len"
>                And
>    subsequent reference to "2 + Len" should be changed to "Len".

Done, all of the above.

> 10. Section 6.8 : Under description of "Destination Address" :
> 
>    "Otherwise, the mobile node's home address SHOULD be used."
> 
>    Why is that so ? This is unsolicited Prefix Advertisement, so how can
>    the Home Agent find this home address if it is not registered with it (and
>    thus not present in the binding cache) ? And this also conflicts with the
>    first sentence in this section anyway, "A home agent will send a Mobile
>    Prefix Advertisement message to a mobile node to distribute prefix information
>    about the home link while the mobile node is traveling away from the home
>    network."
> 
>    Shouldn't this be removed ?

It does appear to be so. Other mechanisms work on the home link, and
when the mobile node is away, we really need to use either the source or
the care of address.

> 11. Section 7.5 :
> 
>    -  MinRtrAdvInterval       0.05 seconds
>    -  MaxRtrAdvInterval       1.5 seconds
> 
>    This interval is too long, a range of 30 times. If the router is using
>    1.5 seconds (using Advertisement Interval Option), the MN may need a very
>    long time to register the fact that it has moved, probably having to miss
>    a few of these router advertisements. I think suggested values should be
>    in the range of 0.05 to 0.25 seconds at the most, implementors are welcome
>    to increase this if they want, but Mobile Specs should be more stringent
>    on smooth handoff.

Ok - but how do other folks see this? Filed this as a separate issue
#42 for better separation of the discussions.

> 12. Section 8.1 :
> 
>    There has been some discussion on this, but I don't know what the final
>    consensus is. But I feel that the first "MUST" for processing Home
>    Address option should be changed to "SHOULD". If the node is processing this
>    option, it should have a Binding Cache (since the MN would have sent
>    this option only after establishing a Binding Cache). Since the third point
>    is using "SHOULD", this one too should use "SHOULD". Making all three a
>    "MUST" might be restricting some implementation of special mobile devices,
>    which might not need the full functionality, eg a MN which is going to
>    interact with a CN, and never with another MN (this is the scenario where the
>    second bullet is not applicable).

We have another issue #22 and on ongoing discussion about this...

> 13. Section 9.1 : Remove the two bullets under :
> 
>    "-  A flag indicating whether or not this Binding Cache entry represents
>        a mobile node" ...
>                                                     AND
>    " -  The length of the routing prefix for the home address.  This" ...
> 
>    Both of these have been removed since draft 14/15 or so. The second one need
>    not be replaced with the 'S' bit flag, since the implementation of the 'S'
>    bit would create multiple entries in the binding cache anyway. Hence both of
>    these can be removed.

Ok. Done.

> 14. Section 9.4.5 : The last sentence of the second para should be changed to :
> 
>    "When the mobile node receives a packet from some sender containing a Binding
>    Refresh Request option, it MUST confirm that a binding exists in it's BUL for
>    this sender, and then it MAY start a return routability procedure, if
>    necessary, before sending its current binding and a new lifetime in a new
>    Binding Update.

Ok.

> 15. Section 10.2 : The 4th bullet is confusing to me.
> 
>    It looks like a BU to HA MUST have both BU as well as a Home Address option,
>    while to a CN, the BU MUST NOT have the Home Address option. I guess this was
>    a subject of debate on the mailing list, but I didn't follow it if it happened.
>    Is this a conscious decision to have two Home Addresses when sending to HA, and
>    is it really necessary ?

This relates to issue #10.

> 16. Section 10.2 : The 5th bullet should be changed to :
> 
>     "This ensures that no other node on the home link was using the mobile node's
>     home address when the Binding Update arrived".

Ok.

> 17. Section 10.2 : The 5th bullet needs another modification :
> 
>    "When the home agent sends a successful Binding Acknowledgement to the mobile
>    node, in response to a Binding Update with the `D' bit set, the home agent
>    assures to the mobile node that its home address will continue to be kept
>    unique by the home agent at least as long as the lifetime granted for that
>    home address binding is not over, or while the mobile node transmits Binding
>    Updates with new care-of addresses for that home address.

Hmm... I think we can skip the part after "or while". Those are binding
updates too, and the first part applies.

> 18. Section 10.2 : The para about 'S' bit should be changed to :
> 
>    "The set of such home addresses is formed by replacing the routing prefix for
>    the given home address with all other routing prefixes *on the mobile node's
>    home link* that are supported by the home agent processing the Binding Update.

Ok

> 19. Section 10.2 : The para about :
> 
>    "-  The Refresh field MUST be set to a value less than or equal to"
> 
>    Is Refresh useful at all ? I don't believe it is. It seems to imply that it
>    helps in the case of the Home Agent crashing and has only a volatile storage
>    for the binding cache.  But if the Home Agent crashed before the Refresh
>    interval is over, the behaviour is identical to the case where the Refresh
>    field contains the same value as Lifetime.
> 
>    It will be useful only if the HA crashed after the Refresh interval but before
>    the Lifetime interval. Hence it is completely useless in most situations.
> 
>    If this can be removed safely, all references need to be removed in the
>    draft and the Format of the BU section (6.1.8) needs to reflect this.

How do others feel about this? Assigned a separate issue #43.

> 20. Section 10.4 : The first bullet is slightly wrong. It should say :
> 
>    "-  The home agent examines the value of the `S' bit in the new "home
>    registration" Binding Update Packet.  If this bit is nonzero," ...
> 
>    The HA has just got a BU packet from MN, and the Binding Cache entry did
>    not exist. Also the Binding Cache doesn't contain a 'S' bit field. We should
>    specify that the HA looks at the BU packet and not the BC entry.

Yes.

> 21. Section 10.4 : Part of the last para should be changed to :
> 
>    "In addition, the Router (R) bit in the Advertisement MUST be set to zero.
>    Acting as a proxy ....".

Ok

> 22. Section 10.5 : First sentence of the second para should be changed to :
> 
>    "While the mobile node is away from home and this node is acting as the
>    mobile node's home agent, the home agent intercepts any packets on the
>    home link addressed to the mobile node's home address (including addresses
>    formed from other on-link prefixes, if the 'S' bit was zero in the Binding
>    Update), as described in Section 10.4."
> 
>    Prefix Len is removed.

Ok.

> 23. Section 11.2.3 :
> 
>    "-  The segments left field in the RH is either 0 or 1."
> 
>    This should be 1 since that is the value set. Also, section 6.4.1 confirms
>    that.

This has been separately discussed. Are you happy with Erik's clarification?

> 24. Section 11.6.2 : Do we need to mention that the binding to CN be done
>    only after getting a success BA from the HA. I am referring to :
> 
>    "When a mobile node sends a Binding Update to its home agent to register a new
>    primary care-of address (as described in Section 11.6.1), the mobile node SHOULD
>    also start a return routability procedure to each other node for which an entry
>    exists in the mobile node's Binding Update List, as detailed below.  Upon 
>    successful return routability procedure, a Binding Update message is sent." ...
> 
>    The last sentence could be changed to :
> 
>    "Upon successful return routability procedure and after receiving a successful
>    Binding Acknowledgement from the Home Agent, a Binding Update message is sent
>    to all other nodes".

Sounds good.

> 25. Section 11.6.2 : When the BU packet is formed, should it be specified that
>     a Home Address option MUST NOT be included ? This is relevant to my comment
>     on item #15.

Latest discussion points to that HAO must be included.

> 26. Section 11.6.4 : In the second last para, the last sentence should be changed
>     to :
> 
>     "In this case, the mobile node instead SHOULD return a Binding Update to
>     the sender, in which the Lifetime field is set to zero and the care-of
>     address (using a Alternate Care-Of Address option) is set to the mobile
>     node's home address."
> 
>     The source address cannot be set to the Home Address due to ingress filtering,
>     and this should be made more clear.

Ok.

> 27. Section 11.6.7 : The last sentence of the second para should include some
>     re-transmission policy in case the NS is lost. Otherwise the MN cannot
>     send a BU to the Home Agent after returning to the Home Network. Some
>     values need to be specified for timeout and number of retransmissions before
>     the MN can assume that the Home Agent is dead (and possibly continue using
>     it's home address and also continue to finish the returning home procedure).

I've been assuming regular NS retransmission would apply. Should we clarify that,
is that somehow not possible?
 
> *********************************** Typos ************************************

 > (1-12 snipped)

Thanks, fixed!

Jari

---

From: Krishna Kumar <[email-masked]>
Date: Mon, 3 Jun 2002 17:26:22 -0700 (PDT)

Hi Jari,

Thanks for your comments.

Regarding  :

1.
> This has been separately discussed. Are you happy with Erik's clarification?

Yes, I agree with Eric's clarification.

2.
> is that somehow not possible?

You are right about that, the regular NS would handle this case and it doesn't need
to be specified here.

Thanks,

- KK

### Jari Arkko writes : ###

-- 
*******************************************************************************
                                       ,-~~-.___
                                      / |  '    \
                                     (   )       0
"On the Internet no one               \_/-, ,---'
knows you're a dog"                      ====           //
                                         /  \-'~;    /~~~(O)
                                        /  __/~|   /       |
                                     ==(  _____| (_________|

Krishna Kumar                                      Ph  : (503) 578-3602 (W)
Software Engineer, IBM NUMA-Q Server Division            (503) 356-9217 (H)
15450 SW Koll Parkway, Beaverton, OR 97006         Fax : (503) 578-3228
*******************************************************************************