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

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

>> This also solves the
>> issue raised by Greg in another email with subject
>> "MIPv6 v20 Question re returning home NA hack".

Yes, this looks much better than what is there now.

>> > 2. MN looks at its binding update list and knows that
>> >    the binding at the HA has expired.

Can it cope with MN rebooting on home net during lifetime of HA binding?

Greg

>-----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).
>> >
>>
>> This also solves the
>> issue raised by Greg in another email with subject
>> "MIPv6 v20 Question re returning home NA hack".
>>
>> Vijay
>>
>
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Feb 2003 10:35:22 -0800

> Can it cope with MN rebooting on home net during lifetime of HA binding?

yes, if the lifetimes are not too long. otherwise we need 
something new for this. the MN can use RFC 3041 generated 
home address. or we could have the following

1. MN reboots at home. does not remember if it had a binding
   at its HA.
2. when the MN receives an RA, it realizes it is at home
3. does DAD for the home address. DAD fails if HA is still 
   defending the MN's address
4. MN cant differentiate between HA defending its address
   and some other node configuring its address
5. attempts a deregistration with its HA.
6. HA deletes the binding cache entry. if HA was not 
   defending MN's address, it responds with status 133 (Not 
   home agent for this mobile node)
7. if the MN receives a bind ack with status 133, it 
   concludes somebody on the home link has configured its 
   address.

the probability of this happening is very remote especially 
with smaller binding lifetimes. I am not sure it is worth 
solving this by introducing new mechanisms.

Vijay