Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction

[James Kempf <kempf@docomolabs-usa.com>]

> Doesn't this imply that if the host has moved to a new link, and the
> Confirmed address is a duplicate on that link, that the host might
> accidentally overwrite the neighbor cache entry for the existing user of
> that link-local address?
>
> That would seem to defeat the purpose of DAD.
>

Draft-pentland in Section 5.2.3 says this:

   Hosts MUST include a tentative source link layer address option
   (TSLLAO) in the RS message [13].  The router solicitation message is
   sent to the All_Routers_Multicast address and the source address MUST
   be the link local address of the host.

The router uses the TSLLAO to route back to the host, and the definition of
the TSLLAO means that it won't pollute the neighbor cache if there's a
duplicate. So there should be no effect on the router neighbor cache even if
there is a duplicate, and the router shouldn't send the RS to any other node
even if there is a duplicate because the TSLLAO will allow link routing to
work correctly.

> It is safer to, immediately when the link level event arrives, switch
> all Confirmed addresses to Optimistic.
> Then if it turns out that the host didn't move, it can switch those back
> to Confirmed.
> And if it turns out that the host did move, it can send the actual NS
> DAD probe for all the IP addresses it has (the existing link-local
> addresses, as well as any newly configured IP addresses).
>

I considered that, but the problem is that if the addresses are switched to
"Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about
the "Optimistic" state:

   * (modifies 5.4)  As soon as the initial Neighbor Solicitation is
        sent, the Optimistic Address is configured on the interface and
        available for use immediately.  The address MUST be flagged as
        'Optimistic'.

so what this means to me is that the node would have to send NSes on the
link prior to switching its addresses to Optimistic, even if it is on the
same link, because it doesn't find out that it is on the same link until
after the RA returns. I'm not sure whether the extra traffic overhead on
each move is really necessary or beneficial.

Unfortunately, there's no good solution here. Here are the possible states
and their problems:

- Optimistic: requires NS/DAD signaling even if the host hasn't switched IP
links. If the host has switched IP links, then any packets sent with a
global unicast address while the RS/RA transaction is underway will be sent
with an address that is topologically incorrect (because the host may send
packets while an address is in "Optimistic").

- Confirmed: If the host has switched links, then any packets sent with a
global unicast address will be sent with an address that is topologically
incorrect, as above.

- Tentative: requires NS/DAD signaling even if the host hasn't switched IP
links, but no topologically incorrect addresses will be used if the host has
switched links since a host can't send any packets from a Tentative address.

- Deprecated: not relevant, since the host can continue to use the address
for existing connections and therefore would have the same problem with
topological incorrectness here as with Optimistic and Confirmed.

If we are OK with having the host signal to reconfirm addresses on every
move, then we could switch the link local address used as the source address
on the RS to Optimistic, and the others to Tentative prior to sending the
RS. This would avoid the problem with topological incorrectness for global
unicast addresses. When the RS returns, we could switch everything to
Optimistic if the host is on the same IP link, since no change in topology
has occured. If the IP link has changed, then the link local addresses could
be switched to Optimistic and the unicast global addresses could be dropped
(actually "dropped" is not in the state machine, and Deprecated isn't
appropriate because RFC 2462 allows the host to continue using Deprecated
addresses), and the host would then configure new global unicast addresses.

Any other ideas about how to handle this?

>
>
> > If the returned DNA RA indicates that the host has not moved to a new IP
> > link, no further action is required for multicast addresses to which the
> > host has subscribed.
> >
> > If, on the other hand, the DNA RA indicates that the host has moved to a
new
> > IP link, the host MUST issue MLD [RFC3810] messages to the router for
> > subscribed multicast addresses, including the
> > Solicited_Node_Multicast_Address for any unicast addresses configured.
>
> It actually needs to handle the Solicited node multicast addresses
> before starting any DAD procedure, to ensure that it will receive DAD
> messages when there are MLD snooping L2 switches.
>

Yes, that's true. I'll switch that around to make it clear.

            jak