Subject: [mobile-ip] dialogue problem in some particular cases between the Mobile Node and the corresponding Node

From: Frédéric Roudaut <[email-masked]>
Date: Fri, 13 Dec 2002 11:45:11 +0100

Hi,

perhaps I misinterpreted something but I think there could be a dialogue problem 
in some particular cases between the Mobile Node and the corresponding Node.
Consider the 3 extracts hereafter:

9.5.2. Requests to Cache a Binding
...
The lifetime for the Binding Cache entry is initialized from the
Lifetime field specified in the Binding Update, although this
lifetime MAY be reduced by the node caching the binding; the lifetime
for the Binding Cache entry MUST NOT be greater than the Lifetime
value specified in the Binding Update. 

9.3.1. Receiving Packets with Home Address Destination Option
...
Packets containing a Home Address option MUST also be dropped if
there is no corresponding Binding Cache entry for the given home
address.  A corresponding Binding Cache entry MUST have the currently
registered care-of address equal to the source address of the packet.
These tests MUST NOT be done for packets that contain a Binding
Update and a Home Address option.   
If the packet is dropped due the above tests, the correspondent node
SHOULD send the Binding Error message as described in Section 9.3.3.
The Status field in this message should be set to 1 (unknown binding
for Home Address destination option).

9.5.5. Sending Binding Refresh Requests
...
If the sender knows that the Binding Cache entry is still in active
use, it MAY send a Binding Refresh Request message to the mobile node
in an attempt to avoid this overhead and latency due to deleting and
recreating the Binding Cache entry.  The Binding Refresh Request
message is sent in the same way as any packet addressed to the mobile
node (Section 9.3.2).

With a little exemple it will be easier to understand. We consider a 
Mobile Node which has already an entry in the binding cache of a 
Correspondant Node. Nevertheless for a specific reason the Lifetime in 
the binding cache entry is reduced from the Lifetime sent in the 
corresponding Binding Update. When the Lifetime will be expired, the 
Mobile Node will not know this if the Correspondant Node don't send a 
Binding error Message or a Binding Refresh Request. So because it is not 
an obligation to send one of these messages, all packets sent from the 
Mobile Node to the Correspondant Node with a home address destination 
option will be dropped.

So I think there should be a MUST in one of these extracts (especialy 
concerning the sending of the Binding Error) or you have to add a 
specific part for the specific case where the correspondent Node decide 
to reduce the Lifetime. If people implementing a Correspondent Node with 
this particular feature are not aware about this, this Node could 
rejected all packets sent during the end of the Lifetime periode. 

Moreover I noticed an editorial mistake in the format of the Home 
Address Option p41. Because the alignement requirement for the Home 
Address Option is 8n+6, you must have 4 Bytes between the field "Header 
Ext Len" of the Destination Options Header and the field "Option Type" 
in the Home Address Option. The option format written in draft 19 was 
the following  :

 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header | Header Ext Len  |  Option Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                          Home Address                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards,

-- 
Frédéric ROUDAUT
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 44, Fax: +33 (0) 2 99 84 71 71

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 13 Dec 2002 08:24:03 -0700

Frédéric -

I agree with you about this potential MN to CN dialogue issue, good catch.

It looks like the easiest fix is (as you suggest) to change the wording of
the requirement regarding the CN sending the BE from SHOULD to MUST:

"9.3.1. Receiving Packets with Home Address Destination Option
...
If the packet is dropped due the above tests, the correspondent node MUST
send the Binding Error message as described in Section 9.3.3. The Status
field in this message should be set to 1 (unknown binding for Home Address
destination option)."

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Frédéric
> Roudaut
> Sent: Friday, December 13, 2002 3:45 AM
> To: [email-masked]
> Cc: Cesar Viho; Sebastien Barbin
> Subject: [mobile-ip] dialogue problem in some particular cases between
> the Mobile Node and the corresponding Node
>
>
> Hi,
>
>

---

From: Brian Haley <[email-masked]>
Date: Fri, 13 Dec 2002 13:03:52 -0500

...
> Mobile Node to the Correspondant Node with a home address destination

Hi Frederic,

The other workaround for this is to have the MN request an
Ack, that way it will know the lifetime.  I would agree with
the sending of a BError being a MUST though since it will
signal the MN to start the binding process again quicker.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 13 Dec 2002 14:23:37 -0800

> in the Home Address Option. The option format written in draft 19 was 

he is right. because of the alignment requirement there is always
a 4 byte padding between the destination options header and option
type in a home address option.

anyway, the above format is wrong. it should just show the home
address option. it should exclude the fields "Next Header" and
"Header Ext Len".

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |  Option Type  | Option Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                          Home Address                         +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

this is how it used to be before. I dont know when it changed to the
format in draft 19.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Dec 2002 21:39:13 +0200

> type in a home address option.

Yes, this appears to happen unless there are some other options
involved as well.

> address option. it should exclude the fields "Next Header" and

Right.

This is a bug introduced in draft 19 ;-( but now it is fixed.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Dec 2002 21:49:46 +0200

Yes, the SHOULD is now changed to a MUST. I think the original
reason why it was a SHOULD was about the desire to allow for
rate limitation etc. But since 9.3.3 already talks about this
then a MUST reference to 9.3.3 is quite appropriate. Thanks
for catching this.

Jari