Subject: [mobile-ip] Home bindings when L=0

From: Brian Haley <[email-masked]>
Date: Wed, 28 Aug 2002 13:56:02 -0400

There seems to be a problem in Section 10.2 of the Mobile IPv6 draft
regarding which addresses should be defended for Home bindings.
There is a paragraph that tells what to do when S=0/1 and L=0/1, the
problem is that when L=0 we should only defend the given home
address in the BU since we cannot derive the interface id from the
address to construct other addresses (for example, the MN is using
a private address).

So I propose that this section can be compressed to three cases:

"The specific addresses which are to be tested before accepting the
  Binding Update, and later to be defended by performing Duplicate
  Address Detection, depend on the settings of the `S' and `L' bits, as
  follows:

    -  L=0:  Defend the given address.  The 'S' bit is ignored in this case
        since we cannot derive other on-link addresses without knowing
        the interface identifier (IID).

    -  S=0 & L=1:  Defend all non link-local unicast addresses possible
       on link and the derived link-local.

    -  S=1 & L=1:  Defend both the given non link-local unicast (home)
       address and the derived link-local."

Furthermore, in Section 11.6.1, the paragraph on setting S=0 should
be updated to say that L MUST be 1 in this case or S will be ignored.
BTW, the very next paragraph (about the L-bit) makes the
recommendation that the L-bit SHOULD NOT be set if using RFC
3041 addresses, maybe that should change to MUST NOT since we
should not defend a link-local address derived from that type of
global address.

I talked with Vlad Yasevich about this, who originally proposed the
L-bit, and this was his intention when he proposed it.

Any comments?

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Aug 2002 13:45:07 -0700

it would be nice to separate the 'L' bit and the 'S' bit.

so, heres another suggestion. what if we specify "the MN MUST
set L=0 and S=1 if it is using RFC 3041 generated home address"

when the MN sets the L=1 or S=0, the HA blindly derives other
addresses and defend them.

Vijay

ps: Brian, I am fine with your suggestions too.

---

From: Brian Haley <[email-masked]>
Date: Wed, 28 Aug 2002 17:11:34 -0400

> it would be nice to separate the 'L' bit and the 'S' bit.

But they are tied together because S=0 relies on being able to
know the IID to derive the other addresses from it.

> set L=0 and S=1 if it is using RFC 3041 generated home address"

That's fine with me, but we also have to specify what to do if
we see the invalid setting, we shouldn't need to drop the packet
for something like this.

> addresses and defend them.

I would hope the HA isn't "blind" about what to do in all cases,
but I'm sure everyone's implementation of S=0 will vary slightly.
The way we figure it, it will take deployment to shake-out this
code anyways, although I'd rather get it right the first time...

> ps: Brian, I am fine with your suggestions too.

That's good :)

-Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 29 Aug 2002 09:09:27 -0400

Vijay

> set L=0 and S=1 if it is using RFC 3041 generated home address"

This is fine with me as well, but hopefully this will not
get us into the rut of specifiying bit values for other different
address types.  That's my only concern...

> ps: Brian, I am fine with your suggestions too.

I agree with Brians' wording as well.  I must have missed this
inconsitency when the we were talking about the L bit.

-vlad

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich	       Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 	       Tel: (603) 884-1079
Nashua, NH 03062	       ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Aug 2002 18:53:36 +0300

I agree with Brian's suggestion for 10.2 and 11.6.1. A
few comments on the discussion:

Vijay wrote:

>set L=0 and S=1 if it is using RFC 3041 generated home address

Yes, we should make this explicit in 11.6.1.

> we see the invalid setting, we shouldn't need to drop the packet

We can't tell if the MN did this wrong, because we can't tell
3041 addresses from other addresses. However, the HA can receive
an L=0 and S=0 which is in a way invalid. But your new 3-entry
table already takes care of this, as it doesn't consider the S bit
at all if L=0. So we should be OK now.

Jari