Subject: ID mobileip-ipv6-12.txt and Duplicated Address Detection

From: Francis Dupont <[email-masked]>
Date: Fri, 12 May 2000 18:30:28 +0200

I don't like many things in draft-ietf-mobileip-ipv6-12.txt section 10.19:
 - DAD only for the home address when after it is for all addresses
 - a wrong duplicate case
 - the MUST for the unspecified address as source (incorrect because
   it is not always needed, ugly because the answer will be sent the
   the all-nodes multicast)
 - the MUST NOT for DAD when there are some cases DAD could be performed
   without harm (then it should be performed :-)
 - nothing about the case when the mobile returns at home during the
   DAD procedure performed by the home agent.

First they are many cases:
 - the mobile asked for DAD or not in its (previous) home registration
 - the mobile set a zero or a not zero prefix length in its home registration
 - the mobile returns at home during the DAD procedure done by the home agent
   or after, ie a DAD collision is possible or not (*)
 - the mobile knows or doesn't know the link-layer address of the home agent.

(*) the mobile node should know if a DAD collision is possible because
the home agent sends the acknowledge after DAD:

    -  Finally, if the Duplicate Address Detection (D) bit is set in
       the Binding Update, this home agent MUST perform Duplicate
       Address Detection [27] on the mobile node's home link for the
       home address in this binding (before returning the Binding
       Acknowledgement).

Note this statement should be changed in order to perform DAD for
all addresses if prefix length is not zero as it is described
in the prefix length paragraph. --first point--

A summary about DAD procedure:
DAD uses NS/NA, NSs are special (source is the unspecified address) and
NAs are answers to special NSs (and a bit non-standard too because
they are sent to the all-node multicast address).

During DAD, special NSs are sent with:
 - the unspecified address as source
 - the solicited-node multicast address (of the checked address) as destination
 - checked address as target
 - no source link-layer extension
On reception of NSs:
 - if the source is unicast (ie for standard NSs), the NS is discarded
 - if the source is unspecified (ie for special NSs) and the packet from
   another node, then there is a duplicate.
On reception of NAs:
 - the checked address is a duplicate.

After/without DAD, the only specific processing is for special NSs:
a NA must be sent to the all-nodes multicast destination, in order to
signal to the other node that the address is already used, with a
link-layer address extension (because the destination is a multicast).

Then in short DAD has two phases:
 - DAD itself (special NSs) == "perform DAD"
 - after DAD or without DAD (answer to special NSs) == "defend for DAD"

If the mobile returns at home when the home agent is performing DAD
on mobile addresses, then the mobile will answer to special NDs
and home registration will fail. I believe it doesn't matter because
the mobile has to send a home deregistration but this is another
proof that the mobile must deregister before perform a DAD (see
after the 4th point). --fifth point--

The proposed solution is to fake a DAD for the home agent address
(this is *confusing*) and to get the link-layer address in the NA...

   ... If the mobile node
   does Neighbor Solicitation to learn the home agent's link-layer
   address, in this special case of the mobile node returning home, the
   mobile node MUST set the Source Address of this Neighbor Solicitation
   to the unspecified address.

I think there are better solutions and they are necessary only with a
non-zero prefix length (ie with a zero prefix length the link-local
address can be used, checked by DAD, ..., without problems).
--third point--

The following statement from ID 12 is wrong:

   In particular, a Neighbor
   Solicitation from the mobile node using its home address as the
   Source Address would be detected by the home agent as a duplicate
   address.

because the DAD is using special NDs. In this case the home agent
can log the event (as it should be done for the similar in ARP)
but the problem is not a false duplicate.
The home address (and others if prefix length is not zero) are proxied
by the home agent then the home agent doesn't know how to reach them
(in fact it believes they are at the end of an old tunnel or must be
discarded) until the home agent processes the home deregistration.
This problem occurs only when the mobile needs to do a NS/NA exchange
in order to get the home agent link-layer address and hurts only
with a non-zero prefix length (which makes all the mobile addresses
unusable). --second point--

This statement is not accurate:

   In addition, when returning home and configuring its home address
   on its network interface on its home link, the mobile node MUST NOT
   perform Duplicate Address Detection on its own home address, in order
   to avoid confusion or conflict with its home agent's use of the same
   address.

In fact, the mobile node may perform DAD but after home deregistration:
 - the mobile node sends a binding update for home deregistration
 - the home agent ceases to defend addresses for DAD and flush
   them from its neighbor cache/proxy server
 - the home agent does a NS/NA exchange with the mobile node in order
   to get its link-layer address from its home address
 - the home agent sends a binding acknowledge for home deregistration
 - then the mobile node may perform DAD.
--fourth point--

Here is a proposal for a better (IMHO) solution for the 3rd point:
the mobile recognizes the case (no known link-layer address of
the home agent, non-zero prefix length), creates a temporary
address with a local interface ID, performs DAD for it (mandatory!)
and uses it only for the NS/NA exchange with the home agent.

Regards

[email-masked]

PS: two remarks:
 - the DAD procedure itself is short (DupAddrDetectTransmits(1) *
   RetransTimer(1000ms) ie *one* second for the default)
 - I don't know whether the zero or the non-zero prefix length is the
   common case.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------