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

From: Krishna Kumar <[email-masked]>
Date: Wed, 29 May 2002 18:04:57 -0700 (PDT)

Hi all,

My other mailer from where I sent this mail earlier (Lotus Notes!) removes all
tabs and puts spaces (UGH!), and hence it is quite un-readable. I am sending the
same mail from my unix mailer. Sorry about sending this twice.

Thanks,

- KK

Hi folks,

I have read all but the Security related sections of the draft, and have
the following comments.

Thanks,

- KK

*************************** Technical Comments ****************************

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

2. Section 6.1.4 : Same as #1 above.

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

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.

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.

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

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 ?

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.

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

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.

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.

   This is to prevent Denial of service attacks.

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 ?

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

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.

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.

   This is correctly stated 2 bullets below in the "However, if the 'S' bit" ...
   para ...

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.

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.

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

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.

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.

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

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.

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.

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

*********************************** Typos ************************************

1. Section 6.1.6 :

   In the description of the Reserved field, remove the "and the one 32-bit
   field" since that field does not exist.

2. Section 6.1.7 :

   In the description of the Reserved field, change the statement to :

   "These fields are unused. ......"

3. Section 6.1.7 :

   In the description of the Sequence # field, the Section number 4.5 is
   wrong, it should be 5.5

4. Section 6.3 :
   In the 3rd last line of the first para, "MUST not" should be changed to
   "MUST NOT".

5. Section 6.8 :

   The first sentence under description of "Destination Address" should
   be rephrased as :

   "If this message is a response to a Mobile Prefix Solicitation, this field
   contains the Source Address field from that packet."

6. Section 7.6 :

   Last para, change the "it" to "it's" :

   "on it's current link, until its movement detection algorithm"

7. Section 10.1 :

   In the second para, the "SHOULD NOT" should be changed to "MUST NOT". Conflicts
   with Section 9.5

8. Section 10.2 : An extra "," at the beginning of :

   "-  , However, if the `S' bit field in the Binding Update is zero,"

9. Section 11.1 : In the second bullet item, add a "of".

   "* one of the mobile node's home addresses for typical Binding Updates
   (Sections 11.6.1 and 11.6.2), or"

10. Section 11.2.1 : Clarify home address means any of the home addresses
in :

   "Likewise, if the mobile node uses any address other than its home address as
   the source of a packet sent while away from home"

   can be changed to :

   "Likewise, if the mobile node uses any address other than any of its home
   addresses as the source of a packet sent while away from home"

11. Section 11.6.1 : Change last Character of this section from "B" to "C"
   (appendix reference).

12. Section 11.7 : The last sentence seems to be mis-formed. Needs rephrasing.