Subject: Re: [mobile-ip] Question on performing DAD for BU's

From: "Krishna Kumar" <[email-masked]>
Date: Fri, 7 Dec 2001 18:33:07 -0800

Hi Vijay & Francis,

I didn't state the complete problem (though Francis did correctly guess
what I meant), so let me add a few lines to describe that. When the MN goes
to a FN, another node (which already had it's address autoconfigured,
thereby having it's own link local address) configured the MN's home
address manually, unintentionally or maliciously. When the HA does DAD on
the link local address, the new node does not respond to the NS, since it
has a different link local address. Now there will be a conflict for
packets destined to either the MN or the new node. Isn't it needed to do
DAD in this case for every address ?

My problem is only with manual configuration , I agree that
autoconfiguration doesn't create this problem at all.

Also, the 'S' bit doesn't solve the problem, it is not defending all the
addresses, the 'S' bit is used for tunnelling packets with any of the many
home addresses values based on the prefixes supported, instead of just the
home address.

> this is based on the common policy where DAD is only performed on
link-local addresses *and* no address uses a different interface ID.

If this restriction is enforced, this problem does not exist. But that is
exactly what I am trying to find out. If a node can configure an address
with a different interface identifier, then DAD should be done on all
addresses values.

Please let me know if this is wrong in any way.

Thanks,

- KK

                    Vijay Devarapalli                                                                                            
                    <[email-masked]>         To:     [email-masked]                                        
                    Sent by:                        cc:                                                                          
                    [email-masked]       Subject:     Re: [mobile-ip] Question on performing DAD for BU's             
                    ng.sun.com                                                                                                   

                    12/06/2001 05:20 PM                                                                                          
                    Please respond to                                                                                            
                    mobile-ip                                                                                                    

Hi KK,

I think this comes from RFC 2462 which says if you have stateless
address configuration, its enough if you do duplicate address
detection on just the link local address. the other addresses are
a MAY.

heres the relevant text from RFC 2462, section 5.4

---------------

      - Each individual unicast address SHOULD be tested for uniqueness.
        However, when stateless address autoconfiguration is used,
        address uniqueness is determined solely by the interface
        identifier, assuming that subnet prefixes are assigned correctly
        (i.e., if all of an interface's addresses are generated from the
        same identifier, either all addresses or none of them will be
        duplicates). Thus, for a set of addresses formed from the same
        interface identifier, it is sufficient to check that the link-
        local address generated from the identifier is unique on the
        link. In such cases, the link-local address MUST be tested for
        uniqueness, and if no duplicate address is detected, an
        implementation MAY choose to skip Duplicate Address Detection
        for additional addresses derived from the same interface
        identifier.

---------------

And I guess the intention was that Mobile IPv6 did not want to
specify anything in addition to what is there in RFC 2462.

and regarding more than prefix on the home link there is
something specified in draft 15 for that. if the 'S' bit in the
BU is set, the Home Agent defends just the home address
specified in the home address option. if the 'S' bit is not set,
the home agent forms a home address from each prefix on the home
link and defends all of them. and even in this case, by RFC 2462,
its enough if you do DAD from just the link local address if
stateless address configuration is being used.

one more thing, in your example below node 'X' MUST configure a
link local address. it cant configure a site local address alone
and not configure a link local address. it is there in some RFC,
I forgot which.

regards
Vijay

Krishna Kumar wrote:
>
> Hi Charlie,
>
> I feel there is a small problem in the Draft 15 regarding the address
used
> for performing DAD.
>
> 1. Page 67 for BU processing says that DAD should be performed on the
Link
> Local Address.
> 2. Pg 94 says that : If some time elapses during which the mobile node
has
> no binding at the home agent, it might be possible for another node to
> autoconfigure the mobile node's home address.
>
> A new node 'X' can configure it's address either through
autoconfiguration
> (in which case #1 is sufficient), or by manual means. Since the address
can
> be configured manually, I feel the specification should be changed to
state
> that  DAD should be performed on the Link Local address and all Home
> Addresses (if Prefix Length is > 0) based on different prefixes supported
> by the Home Agent.
>
> The reason is that the MN might configure a site local address as it's
home
> address and move to a foreign network. Before HA gets the BU, another
node
> 'X' manually configures it's address to the site local address used by
the
> MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation
> on the Link Local Address, and since X has not configured that link local
> address, it doesn't respond to the NS. Now packets meant for 'X' get
> wrongly tunneled to the MN. The node X doesn't even need to take the same
> site local address for this to fail, it can configure any other address
> based on the prefixes supported and the interface identifier. In this
case,
> after the BU succeeds, any packets meant for this different address will
> still be tunnelled wrongly by the HA to the MN since Prefix Length was
> greater than zero. Hence I feel HA must perform DAD on all addresses (can
> be done parallely and probably take almost the same time as it would take
> for one DAD) if Prefix Length > 0.
>
> Secondly, is it a good idea for Mobility to change the value of
> RetransTimer to a smaller value like 0.5 seconds or smaller ? This means
> faster handoff for the MN.  Otherwise the MN has to wait for
> 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before
the
> MN gets a response, and before it is allowed to send BU's to CN's.
Reducing
> this time ensures faster movement mechanism for the MN.
>
> Thanks,
>
> - KK

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Dec 2001 11:32:38 -0800

hi KK,

> address manually, unintentionally or maliciously. When the HA does DAD on

lets assume unintentionally. if you have a malicious node on your home
link, lot more things (worse?) could happen.

> autoconfiguration doesn't create this problem at all.

you are right. but it comes from somebody making mistake while
manually configuring the address on the MN.

> home addresses values based on the prefixes supported, instead of just the

acutally section 9.1 talks about creating a binding cache entry for 
each address that can be derived from other prefixes on the home link.
and when you talk about creating a binding cache entry, it also means
that the home agent is defending that particular address. it answers
to neighbor solicitations for that address. otherwise the packets
would never reach the home agent and would never be tunneled to the
mobile node. 

so we can assume the if the 'S' bit is not set in the BU, the home agent
defends and creats a binding cache entry for each address that can be 
derived from other prefixes on the home link. if the wording is not
clear
maybe we can add some text. 

> with a different interface identifier, then DAD should be done on all

I am not sure about the answer to this question. maybe others can 
comment on this.

Vijay