Subject: [mobile-ip] MIPv6 v20 question re L bit

From: "Greg O'Shea" <[email-masked]>
Date: Fri, 31 Jan 2003 20:37:42 -0000

I can't see any way of automating selection of L bit or writing
reasonable instructions for users who want to set HoA manually. Aside
from the multi-homed issue a user might swap PCMCIA or CF adapters,
yielding different IFIDs, and yet wish to keep the same HoA e.g. because
IPSec is keyed on on HoA. (Maybe that's a good reason for *not* choosing
a stateless config addr as your HoA.)
 
But I can't see that v20 says anything about *not* setting L apart from
the RFC3041 provision (whose "MUST" strikes me as unecessarily harsh).
Therefore one possible tactic might be to set L bit on *all* home
bindings. 
 
Is that legit, or a swamp?
 
Greg
-----Original Message-----
From: Greg O'Shea [mailto:[email-masked]] 
Sent: 11 December 2002 17:08
To: Mobile IPv6 mailling list
Subject: [mobile-ip] MIPv6 question re L bit

         The Link-Local Address Compatibility (L) bit is set when the 
         home address reported by the mobile node has the same interface

         identifier (IID) as the mobile node's link-local address. 

What I fail to follow is that a multi-homed mobile node may have
*several* interfaces, as in more than one, each capable of connecting to
the home net with a different EUI64 LL addr on each.

Presumably then the MN could need to register one HoA for each interface
whose LLA it wants protecting; but then when Ifa is attached to the home
net and Ifb isn't then the HoA for Ifb would nevertheless be "at home"
and so the MN would deregister the Ifb HoA and the HA would stop
defending the LLA for Ifb and someone else could grab the LLA for Ifb
before Ifb attaches to the home net. Or did I miss something?

Apparently L=1 is **mandatory** if S=0, so presumably someone must care
deeply about this [11.7.1]

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 31 Jan 2003 13:29:31 -0800

Greg -

Very interesting. There appears to be a slight disconnect. From MIPv6 draft
20:
"   o  If the mobile node's link-local address has the same interface
      identifier as the home address for which it is supplying a new
      care-of address, then the mobile node SHOULD set the Link-Local
      Address Compatibility (L) bit.

   o  If the home address was generated using RFC 3041 [18], then the
      link local address is unlikely to have a compatible interface
      identifier.  In this case, the mobile node MUST clear the
      Link-Local Address Compatibility (L) bit."

RFC-3041 says:
"Note: because multiple temporary addresses are generated from the same
associated randomized interface identifier, there is little benefit in
running DAD on every temporary address.  This document recommends that DAD
be run on the first address generated from a given randomized identifier,
but that DAD be skipped on all subsequent addresses generated from the same
randomized interface identifier."

I thought the whole point of the L bit is to have your HA defend the
link-local scope address associated with your home address (i.e. they both
share the same interface ID), just in case some other node on your home
network optimizes DAD and only tests the link-local address for duplication
and then goes and configures your home address w/out doing DAD. If that is
the purpose of the L bit, then from the above RFC-3041 text it is clear that
a node that generates a random interface ID per RFC-3041 is likely to
optimize DAD, and therefore if you register a RFC-3041 home address with the
HA you should set the L bit so it will protect/defend you from this
scenario.

I was hoping to avoid BED entirely, and just never set the L bit in our MN
implementation - since for the other type of interface ID (i.e. a globally
unique interface ID formed from an Ethernet MAC address, for example) you
really don't need to worry about duplicate address assignment unless there
is a systems administration problem on your home network.

Based on this, however, I think I need to add back in the capability in our
MN public API for the user to have control over setting the L bit, and then
when I register a binding with the L bit set, I have the extra hassle of the
BED hack when returning home.

Of course, there is the other alternative that Pascal Thubert suggested,
specifically doing DAD on the MN's home address to resolve the link-layer
address of the HA defending the home address. That appears increasingly more
attractive ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg O'Shea
Sent: Friday, January 31, 2003 12:38 PM
To: Mobile IPv6 mailling list
Subject: [mobile-ip] MIPv6 v20 question re L bit

I can't see any way of automating selection of L bit or writing reasonable
instructions for users who want to set HoA manually. Aside from the
multi-homed issue a user might swap PCMCIA or CF adapters, yielding
different IFIDs, and yet wish to keep the same HoA e.g. because IPSec is
keyed on on HoA. (Maybe that's a good reason for *not* choosing a stateless
config addr as your HoA.)

But I can't see that v20 says anything about *not* setting L apart from the
RFC3041 provision (whose "MUST" strikes me as unecessarily harsh). Therefore
one possible tactic might be to set L bit on *all* home bindings.

Greg
-----Original Message-----
From: Greg O'Shea [mailto:[email-masked]]
Sent: 11 December 2002 17:08
To: Mobile IPv6 mailling list
Subject: [mobile-ip] MIPv6 question re L bit

         The Link-Local Address Compatibility (L) bit is set when the
         home address reported by the mobile node has the same interface
         identifier (IID) as the mobile node's link-local address.
What I fail to follow is that a multi-homed mobile node may have *several*
interfaces, as in more than one, each capable of connecting to the home net
with a different EUI64 LL addr on each.
Presumably then the MN could need to register one HoA for each interface
whose LLA it wants protecting; but then when Ifa is attached to the home net
and Ifb isn't then the HoA for Ifb would nevertheless be "at home" and so
the MN would deregister the Ifb HoA and the HA would stop defending the LLA
for Ifb and someone else could grab the LLA for Ifb before Ifb attaches to
the home net. Or did I miss something?
Apparently L=1 is **mandatory** if S=0, so presumably someone must care
deeply about this [11.7.1]

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 31 Jan 2003 14:32:04 -0800

> address of the HA defending the home address. That appears increasingly more

I agree with the last part. this is what I has suggested 
to a bunch of folks off the list.

> 
> I had this long discussion with Nicolas Delest. I think we
> like Pascal's suggestion of the MN doing DAD for its own
> address.
> 
> 1. MN realizes it is home (by receiving a router advert
>    with the home prefix)
> 2. it sends a DAD probe with source set to unspecified
>    address and the target set to HoA. Note: this is the
>    natural behaviour. whenever the MN receives a router 
>    advertisement advertising a new prefix, it configures 
>    an address and does DAD for that address.
> 3. the HA responds with a neighbor advertisement.
> 4. the MN gets hold of HA's MAC address
> 5. the MN sends a deregistration BU.
> 
> ofcourse there is one small hack in the above. the MN
> instead of considering the neighbor advertisement from
> the HA as a DAD failure, it considers it a DAD success
> and proceeds to send a deregistration BU. but IMO, this
> is not a big deal. it is a DAD success because, the HA
> was defending it so far and now the MN can take over.
> (Nicolas convinced me on this).

Note: steps 2, 3 and 4 are skipped if the router 
advertisement was sent by the HA which currently has 
binding cache entries for the MN.

> 
> if the HA were not defending MN's home address (because
> the MN was shut off before coming home), then
> 
> 1. MN realizes it is home
> 2. MN looks at its binding update list and knows that
>    the binding at the HA has expired.
> 3. does DAD for the home address.
> 4. if DAD succeeds everything is fine. if it fails, 
>    then someone on the home link has configured its 
>    address.
> 
> we concluded that there is no need for BED (and therefore
> no need for a new ICMP code).
> 

I think the above is sufficient. This also solves the 
issue raised by Greg in another email with subject 
"MIPv6 v20 Question re returning home NA hack".

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 31 Jan 2003 18:21:40 -0800

ALL -

Honestly, I think what has happened is that when S=0 was removed the L bit
has become a bit of a relic. The original intent of the L bit seems to be
(per an earlier email from Brian Haley):
	"... it's set to allow the HA to derive all your other addresses from your
home address."

This implies that it was mainly intended for use with S=0, which is now
removed from the specification.

I had an example to give of a MN setting a random interface ID (per
RFC-3041) on an interface, in which case should the BU for a home address
formed from that IID be sent with L=1 or L=0 since the home address shares
the IID with the link-local scope address auto-configured on the interface,
but I've since decided that this discussion is all a moot point because it
really seems like there is no point to keep the L bit now that S=0 is gone.

The only benefit I can see currently for setting L=1 is that it affords the
MN greater protection/defense of its home address when interoperating with
nodes attached to its home network that optimize DAD. Since nodes that use
RFC-3041 will likely optimize DAD, and since they are picking purely random
interface IDs that are more likely to conflict than globally unique IIDs,
also since the privacy intent of RFC-3041 has the random interface ID (and
the associated home addresses) frequently changing so that a user's Internet
activity cannot be tracked, it seems almost useful to set L=1 when
registering RFC-3041 generated home addresses to avoid DAD conflicts.
almost... not quite.

Hopefully the L bit will just go away ;-) I think my MN implementation will
just pretend that it has (i.e. always set L=0 in the BU).

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

> [mailto:[email-masked]]On Behalf Of Vijay
> Devarapalli
> Sent: Friday, January 31, 2003 2:32 PM
> To: Ed Remmell
> Cc: Greg O'Shea; Mobile IPv6 mailling list
> Subject: Re: [mobile-ip] MIPv6 v20 question re L bit
>
>
> Ed Remmell wrote:
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 31 Jan 2003 18:58:06 -0800

Ed Remmell wrote:
> 
> I think my MN implementation will

which is perfectly acceptable for your embedded systmes 
implementation. but we are not discussing a specification for 
embedded systems here. the specification is for most mobile 
nodes.

removing the L bit does not help returning home. here is why...

the proposal is 

> > 5. the MN sends a deregistration BU.

steps 2, 3 and 4 are just few more lines of code, which are
actually avoided if if the router advertisement (by which the
MN figured out it is at home) was sent by the HA which 
currently has binding cache entries for the MN.

If the HA were not defending the link local address the MN has
to do the following.

1. MN realizes it is home (by receiving a router advert
   with the home prefix)
2. MN does DAD for link local address (it cant use the link
   local address till it does DAD, unless you can be sure 
   that your link local is unique)
3. MN does neighbor discovery to figure out HA's MAC address.
   source address of NS is link local and target is HA's 
   address.
4. The HA responds with a neighbor advertisement
5. the MN gets hold of HA's MAC address
6. the MN sends a deregistration BU.

what did you gain in this? infact the deregistration BU has 
to wait till DAD for the link local completes. or were you 
planning to use the link local address without doing DAD for 
it? I am not sure you can do that, because the MN was off-link 
and nobody was defending the link local address.

Vijay