Subject: [mobile-ip] Resolution to issue 37, defending only link local addresses

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Jun 2002 21:13:00 +0300

I'm trying to close the issue 37. After some off-link discussion
with folks, I wonder if the following proposal would work. Let
us know if you have views on this.

Jari
----

Background: Hesham Soliman writes: Fifth bullet in 10.2: Shouldn't DAD
be done for all addresses?  RFC 3041 might be a problem here if we
only do DAD on link-local addresses.

Proposal: Vijay Devaparalli and Vladislav Yasevich have proposed that
a new 'L' bit is needed. If the 'L' bit is set, it means both the MN's
link local address and home address have the same interface id.

The 'L' and 'S' bits are used when defending addresses i.e. when
answering Neighbor Soliciations. The following addresses are defended:

- S=0 & L=0 => Defend all global unicast addresses possible on link.

- S=0 & L=1 => Semantics of S=0 above + the derived link-local.

- S=1 & L=0 => Defend the given address.

- S=1 & L=1 => Defend the given global unicast (home) address +
                the derived link-local.

If the home address was generated using RFC 3041, then there is no
corresponding link local address. Accordingly the MN SHOULD NOT set
the 'L' bit.

The Home Agent SHOULD perform Duplicated Address detection on every
address it is defending on behalf of the mobile node.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Jun 2002 16:41:23 +0200 (CEST)

Editorial nits - I haven't figured out if we know what the right thing(tm)
is for mobile nodes returning home.

> - S=0 & L=0 => Defend all global unicast addresses possible on link.

s/global/non-link-local/
in order to say the right thing for site-locals.

> - S=1 & L=1 => Defend the given global unicast (home) address +

s/global/non-link-local/

> address it is defending on behalf of the mobile node.

   Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Jun 2002 12:09:12 -0700

Hello Erik,

I made your suggested changes.

Regards,
Charlie P.