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

From: "Venkata Jagana" <[email-masked]>
Date: Tue, 11 Dec 2001 15:17:59 -0700

>>
>> My problem is only with manual configuration , I agree that
>> 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.

Just wanted to clarify this problem further.

One more thing I must say at this point is that this identified
problem happens not only with the manual configuration of the addresses
of the nodes but may also be with the temporary addresses assigned through
DHCPv6 as long as these assigned addresses do not make use of
the corresponding interface identifier.

Thanks,
Venkat

>
> 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.

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.

>
> > 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.

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

Vijay

>
> 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