Subject: [Mip6] Regarding L Bit settings of BU

From: Sachin D <[email-masked]>
Date: Wed, 02 Feb 2005 13:12:00 +0530

Hi All ,

I wanted to clarify the behavior of Home Agent in the following scenario
(though MN should not be doing this but what if HA receives)

First HA receives BU Add request from an MN without L bit set. 

Here it will only do DAD for its global address and will act proxy only for
global address

Now for some reason MN sends BU with L bit set so what should be behavior of
HA in such a scenario because RFC only says

"Unless this home agent already has a binding for the given home

address, the home agent MUST perform Duplicate Address Detection [13]

on the mobile node's home link before returning the Binding

Acknowledgement.  "

So now HA will update its flag here and will not do DAD for link local
address. So in such a case though binding entry state in HA is defending
link local address but actually it is not acting as proxy for that address
and that address can be configured by any node on the network

Can someone suggest how this second BU update request should be treated? 

Also what should be behavior in reverse case i.e when initially BU had L bit
sent and in update request L bit was not should HA leave the solicited node
multicast address for that link local address ?

Regards

Sachin

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Wed, 02 Feb 2005 15:15:13 -0500

Hi Sachin,

Yes, I agree it's not exactly clear what to do in this case, someone 
should add it to the issues list when 3775 is revised.

My implementation follows the rule a little farther down in 10.3.1:

    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 setting of the Link-Local Address
    Compatibility (L) bit, as follows:

    o  L=0: Defend only the given address.  Do not derive a link-local
       address.

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

adds and does DAD on the "new" link-local address.

It also does the opposite when it gets L=0 when the current binding has 
L=1 and stops defending the link-local address.

I checked TAHI and couldn't find anything that tests this, so there is 
no standard way to do it.

Linux seems to ignore the bit change.

-Brian

Sachin D wrote:
> Here it will only do DAD for its global address and will act proxy only 
> for global address
> 
>  
> 
>  
> 
> Now for some reason MN sends BU with L bit set so what should be 
> behavior of HA in such a scenario because RFC only says
> 
>  
> 
>  
> 
> “Unless this home agent already has a binding for the given home
> 
> Acknowledgement.  “
> link local address but actually it is not acting as proxy for that 
> address and that address can be configured by any node on the network
> 
>  
> 
> Also what should be behavior in reverse case i.e when initially BU had L 
> bit sent and in update request L bit was not should HA leave the 
> solicited node multicast address for that link local address ?
> 
>  
> 
> Regards
> 
> Sachin
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
>