Subject: Duplicate Address Detection on a link-local address

From: "Roy Brabson" <[email-masked]>
Date: Fri, 29 Jun 2001 15:31:06 -0400

I've got a question on Duplicate Address Detection for link-local
addresses.  DAD states that a node must join the solicited-node
multicast group for the tentative address before beginning DAD.
Multicast Listener Discovery states that as part of joining a link-scope
multicast groups, other than the all-nodes group, a MLD Report message
must be sent.  MLD also states that the source IP address in the MLD
message must be a link-local address.

So, what should be put in the source address for the MLD Report when the
a link-local address is being assigned and no other addresses exist for
the link?  Since the link-local address is tentative, it shouldn't be
placed as the source address in the MLD Report.  Since the MLD Report
requires a link-local source IP address, an MLD Report can't be sent.

I'm guessing that the correct behavior is as follows when assigning the
initial link-local address to an interface:
- We notify the adapter that we want to receive any packets destined for
  the solicited-node multicast group derived from the link-local
  address.  We do *not* send a MLD Report at this time, though, as we
  do not have a non-tentative link-local address to place in the source
  IP address.

  I've been told that this might cause problems when a LAN is bridged a
  bridge is checking MLD messages to determine where listeners are in an
  effort to avoid forwarding packets when there are no listeners.

- We perform Duplicate Address Detection.  Since we have notified the
  adapter to forward multicast packets for the solicited node multicast
  group, we should receive any Neighbor Solicitations from other nodes
  performing DAD as well (assuming that bridges are forwarding multicast
  packets in the absence of MLD messages).

- If we fail DAD, we would notify the adapter that we no longer want to
  receive packets destined for the solicited-node multicast group which
  we previously registered.  If we succeed with DAD, we send an MLD
  Report for the solicited-node multicast group.

There are some other alternatives which might make sense if bridges are
keying off MLD Reports to determine whether to forward multicast
packets:
- When assigning a tentative link-local address and no other address
  exists for the router, send an MLD Report with the source address set
  to the unspecified address.  This is currently not allowed by MLD and
  might result in the packet failing verification by a bridge/router and
  therefore being discarded.

- Send the MLD report using the tentative link-local address as the
  source IP address.  We aren't supposed to use a tentative address as
  the source IP address, but I don't think it will break anything in this
  case.  If a node already owns the IP address or is itself running DAD,
  this would result in an extra MLD Report being sent to the
  bridge/router.  And if the address is not currently in use and no one
  is performing DAD then I would need to send an MLD Report after
  assigning the link-local address anyway.  Still, I'm not real fond of
  idea of sending a packet using a tentative address as the source IP
  address.

This only applies for the first (and, for us anyway, the only)
link-local address assigned to the interface.  All subsequent addresses
would be processed as described in the RFCs: we would join the
appropriate solicited-node multicast group prior to starting DAD vs.
waiting until DAD is completed.

Roy

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