[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi James, 

----- Original Message -----
From: James Kempf <kempf@docomolabs-usa.com>
Date: Thursday, June 23, 2005 1:41 am
Subject: Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction

> 
> > Sounds like a reasonable assumption.
> >
> > Should this be tied to the Link-Up indications, or to the DNA 
> reception> and processing of hints?
> >
> > For example, if no link-layer indication is received does the
> > reception of an 'unexpected' RA and subsequent initiation of
> > DNA operations cause Optimistic to be set?
> >
> > I'd guess it's tied to DNA initiation, rather than the Link-Up
> > explicitly.
> >
> 
> Well, there's a couple cases to consider.
> 
> Case 1: Multicast RA
> 
> Suppose the host receives a multicast DNA RA, either as a result 
> of failover
> to multicast mode due to RS overload on the router or simply as a 
> multicastbeacon. If the host can conclude that it has not moved to 
> a new IP link, no
> changes in address state are required. If the host can conclude 
> that it has
> moved to a new IP link, the old addresses should be Deprecated, 
> the host
> should form a new link local address, set state to Optimistic, 
> oDAD it, and
> then form new global unicast addresses, etc., just as if it had 
> moved, even
> if it didn't get a link event indicating movement (the link event 
> may have
> failed for some reason). But the host doesn't need to do anything 
> "prior" to
> sending the RS, because it didn't send one.

It's an interesting point.  I'd guess that for non-authoritative
link-change RA reception, you'd want to initiate DNA procedures and
send RS.

If the content of the RA message was enough to go off and configure
addresses (or check router trust with SEND), then the RS would
be unnecessary, as you say.

I'm interested for the hosts document which may need to touch on 
this (while cutting parts out...).

> Case 2: Unsolicted unicast RA
> 
> This case is pretty unlikely and is probably due to an error (or 
> somebodyplaying a trick on the host by sending an RS with the 
> victim's link address
> in the TSLLAO and the victim's link local address as the source 
> address).I'd say in this case the host should be cautious and 
> should issue a unicast
> DNA RA in order to confirm. But I don't think it should make any 
> changes in
> its address state machine in this case, because there is no link event
> indicating a link change. If a link change actually did occur, of 
> course,the addresses need to be reconfigured.

I guess you mean RS.

> How does that sound?

Sounds OK, with the caveat that we wouldn't leave out the Link-hints
(so we don't have confusion on that point). 

Greg