Subject: [mobile-ip] Re: MIPv6 - 17 Review

From: "Krishna Kumar" <[email-masked]>
Date: Wed, 29 May 2002 17:17:07 -0700

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

---

From: Brian Haley <[email-masked]>
Date: Thu, 30 May 2002 10:26:23 -0400

>    increase this if they want, but Mobile Specs should be more stringent on

I would agree, but would set the range at 0.05 to 0.15 seconds, although
I've
found .2 to .5 is adequate for MNs on an Ethernet.

>    Is Refresh useful at all ? I don't believe it is.

I don't feel it's necessary either, since the HA can always send a BRR
to the MN if it doesn't feel it's refreshed the binding soon enough.

-Brian