Subject: [mobile-ip] minor comments on draft 18

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jul 2002 11:43:34 -0700

1) 
Section 6.1.2
>    When a mobile node receives a
>    packet containing a Binding Refresh Request message and there
>    already exists a Binding Update List entry for the source of the
>    Binding Refresh Request, it MAY start a return routability procedure
>    (see Section 5.2) if it believes the amount of traffic with the
>    correspondent justifies the use of route optimization.

remove 'if it believes the amount of traffic with the correspondent 
justifies the use of route optimization'. it is already a MAY. it
is very often difficult to figure out (from the kernel) the amount
of traffic than an application might generated.

anyway, the previous line says 'it MAY start a return routability 
procedue'. I dont think we have to supply the reason not to do it.

2)
Section 6.1.6
> 
>       Reserved
> 
>          The two 16-bit fields are reserved for future use.  These
>          values MUST be initialized to zero by the sender, and MUST be
>          ignored by the receiver.

remove this. there is no reserved field in the CoT message.

3)
Section 6.1.8
>             135   Sequence number out of window

invalid sequence number(?)

>             136   Route optimization unnecessary due to low traffic

I didnt find this used anywhere. do we need this?

4)
Section 10.2
>    -  The Refresh field MUST be set to a value less than or equal to
>        the Lifetime value being returned in the Binding Update.  If the
>        home agent stores the Binding Cache entry in nonvolatile storage
>        (that survives the crash or other failure of the home agent),
>        then the Refresh field SHOULD be set to the same value as the
>        Lifetime field; otherwise, the home agent MAY set the Refresh
>        field to a value less than the Lifetime field, to indicate that
>        the mobile node SHOULD attempt to refresh its home registration
>        at the indicated shorter interval (although the home agent will
>        still retain the registration for the Lifetime period, even if
>        the mobile node does not refresh its registration within the
>        Refresh period).

The refresh field is no longer there in the BU/BA. you should probably
describe the Binding Refresh Advice option here.

5)
Section 10.9.1
>    To avoid possible security attacks from forged Mobile Prefix
>    Advertisements all such Advertisements MUST be authenticated to the
>    mobile node by its home agent using IPsec [4, 5, 6].

is 'MUST' the right keyword? because in another place

>          If a Security Association for the IP Authentication Header
>          exists between the sender and the destination address, then the
>          sender SHOULD include this header.  [subject to change]

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Jul 2002 16:14:15 +0200 (CEST)

> procedue'. I dont think we have to supply the reason not to do it.

I personally see great benefits in providing these suggestions to
implementors. I'm concerns that without them implementors of MNs might
think that it is best to always immediately initiate the BU procedure
with any CN. Such an approach would lead to a performance loss (e.g. if
done before every DNS query is sent to a DNS server, or for other short
transactions). If MIPv6 RO causes a performance loss for short transactions
yet is "advertised" to be a performance improved (and delivers performance
improvements for long transactions) it would be unfortunate.

   Erik

---

From: "Zhang haofeng" <[email-masked]>
Date: Sat, 20 Jul 2002 21:49:02 -0700

Hi,
   I am also wondering how can the MN know the amount of traffic with CN
justifies the use of route optimization or not. In my opinion, once a MN
receives a Binding Refresh Request it SHOULD start a RR procedure. If that,
is it proper?
  Regards

Haofeng