Subject: [Mip6] RFC 3775 - CN BU seq no. issue

From: suraj <[email-masked]>
Date: Tue, 01 Mar 2005 19:17:24 +0530

Hi all,

In RFC 3775, the section 11.7.2 described below may not work correctly if
the Correspondent node has Multiple IPv6 address. 

Since a CN will not contain more than one Binding Cache entry for a single
Mobile Node home address, if the MN sends Binding updates (after RR
procedure) to two different addresses on same CN, the MN can generate
"Random values" of sequence numbers for the each of the Binding Updates.

If MN sends seq no #1 to CN address 1 and seq no #2 to CN address 2, where
both #1 and #2 are random numbers the "sequence number check at the CN may
fail" for the second binding update (address 2) received when compared with
the already existing Binding Cache entry (address 1) sequence number.

11.7.2.        Correspondent Registration

.......................

   Each Binding Update MUST have a Sequence Number greater than the

   Sequence Number value sent in the previous Binding Update to the same

   destination address (if any).  The sequence numbers are compared

   modulo 2**16, as described in Section 9.5.1.  There is no

   requirement, however, that the Sequence Number value strictly

   increase by 1 with each new Binding Update sent or received, as long

   as the value stays within the window.  The last Sequence Number value

   sent to a destination in a Binding Update is stored by the mobile

   node in its Binding Update List entry for that destination.  If the

   sending mobile node has no Binding Update List entry, the Sequence

   Number SHOULD start at a random value.  The mobile node MUST NOT use

   the same Sequence Number in two different Binding Updates to the same

   correspondent node, even if the Binding Updates provide different

   care-of addresses.

.....

I think either the MN must continuously keep incrementing the Seq for each
BU 

sent OR it must maintain a mechanism of keeping track of CN addresses
belonging to 

the same node.

Kindly comment on this.

regards,

Suraj.

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Greg Daley <[email-masked]>
Date: Wed, 02 Mar 2005 14:45:15 +1100

Hi Suraj,

suraj wrote:
>  
> 
> Hi all,
> 
>  
> 
> In RFC 3775, the section 11.7.2 described below may not work correctly 
> if the Correspondent node has Multiple IPv6 address.
> 
>  
> 
> Since a CN will not contain more than one Binding Cache entry for a 
> single Mobile Node home address, if the MN sends Binding updates (after 
> RR procedure) to two different addresses on same CN, the MN can generate 
> “Random values” of sequence numbers for the each of the Binding Updates.
> 
>  
> 
> If MN sends seq no #1 to CN address 1 and seq no #2 to CN address 2, 
> where both #1 and #2 are random numbers the “sequence number check at 
> the CN may fail” for the second binding update (address 2) received when 
> compared with the already existing Binding Cache entry (address 1) 
> sequence number.
> 

>  
> 
> *11.7.2.        **Correspondent Registration*
>
[snip included text]
>  
> 
> I think either the MN must continuously keep incrementing the Seq for 
> each BU
> 
> belonging to the same node.
> 
There's an assumption that there's only one BCache here.

There may in fact be BCaches which identify the destination
of BUpdates and RR.  These would effectively have different
sequence number spaces.

In most implementations I've seen (Windows, MIPL), there's no such
distinction.

If the MN already knows that these are the same node, It should probably
keep a single BUlist entry for the destination (for either the one
BCache or partitioned BCache case).

Since signalling only goes to the CN's home address, it's not likely to
be a problem, unless there are multiple home addresses.

There's a potential issue if direct signalling is used  (as in
draft-ewu-mobopts-directsig-00, which is out of scope for this WG),
since the MN may be choosing between a CoA and a HoA to signal to.

If there are partitioned BCaches on the CN, this won't work very well.
Since it's possible to test this before taking the (still research)
optimization, it's not a big issue.

So we're left with a situation where there are partitioned BCaches on
the CN (with one BUlist entry on the MN) or partitioned BUlist
entries, with a single BCache on the CN.

I'd guess that the partitioned BCache on the CN is probably not harmful,
but the sequence numbers will increment based on the MN's previous
BUs to either address (leading to faster sequence churn).

I'd guess that there's likely to be a problem if the MN doesn't know
these are the same host, and has two BUlist entries for the same host.
It will keep getting told to increase its sequence number, after
updating the other address.

There may be other issues with outstanding keygen tokens for RR.

Perhaps it's worth clarifying the issue.

Greg

---

From: Ranjitsinh Wable <[email-masked]>
Date: Wed, 02 Mar 2005 18:15:23 +0530

Hi Suraj & Greg,

Let me put the problem again:

Is it the problem when the MN and CN are communicating with each other in
two sessions
with different CN addresses. Then how the MN will send BU to both the
addresses of CN.

If the statement is correct then I can see the problem in the maintaining
the bcache list.
We need to maintain the bcache at CN with the combination of  HoA, CoA of MN
and CN
 address for the binding cache. I think even MIPL code does it the same way.

This will not only help in checking the binding update messages for
particular combination but will
also help in deciding the destination entry(using bcache) while initiating
the new communication with
particular CN address.

Regards,

Wable

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 02, 2005 9:15 AM
Subject: Re: [Mip6] RFC 3775 - CN BU seq no. issue

Hi Suraj,

[snip included text]

Greg

---

From: Sachin D <[email-masked]>
Date: Wed, 02 Mar 2005 19:30:50 +0530

HI Greg and Wable,

I am not able to get why CN need to maintain partitioned Bcache or why CN
need combination of Bcache with the combination of  HoA, CoA of MN and CN. 

If CN has two home addresses and when MN starts RR for second CN address RR
will succeed and the only issue is for Binding Update and this add request
of MN BU will be considered as update request for CN . If sequence check is
passed then CN will update its old address with this address and MN will
have two BU List entries for same CN node.

And Greg as you have mentioned that "if MN knows that they are same node"
but in the current signaling between CN and MN , MN can never know that RR
being done for the address belong to same CN with multiple home address or
different CN

So as suggested by Suraj the above issue can be resolved if the requirement
of sequence number being sequential per mobile node can be relaxed and MN
always increment the sequence number.In this case CN will update its
existing binding cache and MN will maintain two BU List entries.

So can any issue come because of sequence number being churned at faster
rate ???

Regards,
Sachin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ranjitsinh Wable
Sent: Wednesday, March 02, 2005 6:15 PM
To: [email-masked]
Subject: Re: [Mip6] RFC 3775 - CN BU seq no. issue

Hi Suraj & Greg,

Is it the problem when the MN and CN are communicating with each other in
two sessions with different CN addresses. Then how the MN will send BU to
both the addresses of CN.

If the statement is correct then I can see the problem in the maintaining
the bcache list. We need to maintain the bcache at CN with the combination
of  HoA, CoA of MN and CN  address for the binding cache. I think even MIPL
code does it the same way.

This will not only help in checking the binding update messages for
particular combination but will also help in deciding the destination
entry(using bcache) while initiating the new communication with particular
CN address.

Regards,

Wable

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 02, 2005 9:15 AM
Subject: Re: [Mip6] RFC 3775 - CN BU seq no. issue

Hi Suraj,

suraj wrote:
> single Mobile Node home address, if the MN sends Binding updates 
> (after RR procedure) to two different addresses on same CN, the MN can 
> generate "Random values" of sequence numbers for the each of the 
> Binding Updates.
>
>
>
> where both #1 and #2 are random numbers the "sequence number check at 
> the CN may fail" for the second binding update (address 2) received 
> when compared with the already existing Binding Cache entry (address 
> 1) sequence number.
>

[snip included text]

There may in fact be BCaches which identify the destination
of BUpdates and RR.  These would effectively have different sequence number
spaces.

If the MN already knows that these are the same node, It should probably
keep a single BUlist entry for the destination (for either the one BCache or
partitioned BCache case).

Since signalling only goes to the CN's home address, it's not likely to be a
problem, unless there are multiple home addresses.

There's a potential issue if direct signalling is used  (as in
draft-ewu-mobopts-directsig-00, which is out of scope for this WG), since
the MN may be choosing between a CoA and a HoA to signal to.

If there are partitioned BCaches on the CN, this won't work very well. Since
it's possible to test this before taking the (still research) optimization,
it's not a big issue.

So we're left with a situation where there are partitioned BCaches on the CN
(with one BUlist entry on the MN) or partitioned BUlist entries, with a
single BCache on the CN.

I'd guess that the partitioned BCache on the CN is probably not harmful, but
the sequence numbers will increment based on the MN's previous BUs to either
address (leading to faster sequence churn).

I'd guess that there's likely to be a problem if the MN doesn't know these
are the same host, and has two BUlist entries for the same host. It will
keep getting told to increase its sequence number, after updating the other
address.

Greg

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Mar 2005 11:40:16 +1100

Hi Wable,

> with different CN addresses. Then how the MN will send BU to both the

If there are two sessions with two home addresses on the MN, and two
Home Addresses (or fixed addresses) on the CN, then there are two
separate BUList and BCache entries.

This occurs whether the CoA is shared or not.

MN                                   CN
BUlist:                              BCache
CN1: HoA1->CoA                      (CN1:?) HoA1->CoA
CN2: HoA2->CoA                      (CN2:?) HoA2->CoA

It doesn't matter in this case if the MN knows they are the same
address or not, nor whether the

If there is only one home address for the MN, then there's only
one

>  address for the binding cache. I think even MIPL code does it the same way.

The CN address wasn't used in the bcache in MIPL 1.1.
I'm not sure what's happened in MIPL 2.

I'm not sure that it does mean that BCaches partitioned by CN address
are required, but it's worth thinking about.

> the new communication with

I'm not sure I get this. The BUlist is used for communicating to CNs.
The BCache is used for sending packets to MNs.
The BUlist already has a CN address specification.

So for communicating to a CN, there's already a mechanism for
identifying the destination entry.

Greg

---

From: Henrik Petander <[email-masked]>
Date: Thu, 03 Mar 2005 12:08:09 +1100

Hi,

I have a short comment on this: MIPL 1.1 and MIPL 2.0 use both the home 
address of MN and the local address of CN as lookup keys for the binding 
cache entries.  There are good reasons to do this, for example a HA 
acting also as CN on another address.

This was discussed previously either on this or the old mobile ip 
mailing list or possibly during an interop, and as far as I can 
remember, the consensus was that also the local address of CN/HA should 
be used for looking up the BC entries.

Regards,

Henrik

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Mar 2005 12:56:08 +1100

Hi Henrik,

> acting also as CN on another address.

Sorry about that.

I see now (from mipv6_bcache_add):

  hashkey.a1 = home_addr;
  hashkey.a2 = our_addr;

I was confused by the fact that there's no indication of that
in mipdiag, nor in the /proc entries in MIPL1.1.

> be used for looking up the BC entries.

You're right again.

section 9.1 of 3775.

    "... A separate Binding Cache SHOULD be
    maintained by each IPv6 node for each of its unicast routable
    addresses.  ..."

Then the point is moot.

Only CNs not following the recommendations are likely to cause
problems, and only for themselves and a peer node.

Greg

---

From: Ranjitsinh Wable <[email-masked]>
Date: Thu, 03 Mar 2005 10:05:18 +0530

Hi Hernrik & Daley,

Thank you Henrik, you made point more clear.
The same point precisely I wanted to convey.
So I think there should not be any problem.

Regards,
Wable

---

From: suraj <[email-masked]>
Date: Thu, 03 Mar 2005 11:12:07 +0530

HI Henrik & Greg,

I suppose the following section creates this confusion about the Binding
Cache lookup:

RFC 3775 - section 9.1 :
   o  The home address of the mobile node for which this is the Binding
      Cache entry.  This field is used as the "key" for searching the
      Binding Cache for the destination address of a packet being sent.

Still I agree with the point that in most places the RFC does say that the 
Binding Cache for a Mobile Node Home address is unique per unicast routable
Ipv6 address of a node.

It would certainly help if the RFC is more clear in this. Take for example
Section  9.5.1, which states :
....
Before accepting a Binding Update, the "receiving node" MUST validate
   the Binding Update according to the following tests:

   o  The packet MUST contain a unicast routable home address, either in
      the Home Address option or in the Source Address, if the Home
      Address option is not present.

   o  The Sequence Number field in the Binding Update is greater than
      the Sequence Number received in the previous valid Binding Update
      "for this home address", if any.

   If the "receiving node" has no Binding Cache entry for the indicated
   home address, it MUST accept any Sequence Number value in a received
   Binding Update from this mobile node.
.....

This contradicts the current situation where there may be more than one
binding cache for the same home address at the receiving node.

Also, in section 9.3.1.  Receiving Packets with Home Address Option
There is no statement mandating that the CN address must be verfied while 
Receiving packets from a Home address. (same with section 9.3.2 while
sending route 2 header packets).

I think we could make this more clear OR even consider the case of multiple
IPv6 addresses sharing the same Home address Binding Cache as Greg mentioned
about partitioned Binding Cache.
 
Kindly comment on this.

Thanks and regards,
Suraj.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
Daley
Sent: Thursday, March 03, 2005 7:26 AM
To: Henrik Petander
Cc: [email-masked]
Subject: Re: [Mip6] RFC 3775 - CN BU seq no. issue

Hi Henrik,

Sorry about that.

  hashkey.a1 = home_addr;
  hashkey.a2 = our_addr;

You're right again.

section 9.1 of 3775.

Then the point is moot.

Greg