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

From: "Greg O'Shea" <[email-masked]>
Date: Mon, 3 Feb 2003 17:42:51 -0000

>Hopefully the L bit will just go away ;-)

I vote for that: if always L=0 and always L=1 are surfacing as
alternative and reasonable behaviours for MN implementations then the
feature starts to look extremely doubtful. 

Aside: another (hopefully moot) point is that my reading of the spec
allows an HA to derive and test the LLA even when L=0 is received - it
says HA should protect the HoA which doesn't prevent it from protecting
the LLA as well. Not that one would, presumably, but one could, so
setting L=0 might not get what you expect from the HA.

>-----Original Message-----
>From: Ed Remmell [mailto:[email-masked]] 
>Sent: 01 February 2003 02:22
>To: Mobile IPv6 mailling list
>Subject: RE: [mobile-ip] MIPv6 v20 question re L bit
>
>
>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
>
>> -----Original Message-----
>> From: [email-masked]
>> [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:
>> >
>> > 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 ;-)
>> >
>>
>> 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: Tue, 4 Feb 2003 14:13:39 -0800

Greg -

> setting L=0 might not get what you expect from the HA.

I expect that if I register with L=0, the HA will not be defending any
link-local address associated with the HoA for that registration. If this is
not the case, I'd like to know why.

When the MN registers with L=0, it is telling the HA that it does *NOT* have
configured a link-local scope home address which matches on the interface ID
with the HoA that it is registering. The HA should only be testing and
defending home addresses that belong to the MN. In this case, the MN has
explicitly told the HA that this link-local scope home address is not one of
its addresses, therefore the HA should not defend that address. If it does,
I'd consider that a broken HA implementation.

Granted, if there are other nodes on the home network that optimize DAD, not
defending the link-local scope address formed from the same interface ID
will be an incomplete defense of the HoA, but then DAD isn't perfect, the
range of random interface IDs to use for RFC-3041 addresses is huge so you
wouldn't expect conflicts on random interface IDs that frequently, the other
style of interface ID is globally unique so you wouldn't expect any
conflicts on it, etc.

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