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

[Christian Vogt <chvogt@tm.uka.de>]

 >>> There is no technical reason for optimistic DAD to require that
 >>> the NS be sent before or even after state change AFAIK. Do you
 >>> see a technical reason?
 >>
 >> No, but unfortunately the oDAD document doesn't say anything about
 >> this.
 >
 > I suspect the oDAD document has no need to say anything. It isn't
 > until one tries to combine oDAD with DNA that the issue of separating
 > the optimistic state change and the sending of the NS appears.


Hi Erik, hi all,

yes, there ARE scenarios without DNA where you would want to use a 
tentative/optimistic address before the initial NS is sent.

I am actually working on a little draft that identifies some of those 
situations.  Below is the relevant extract.  (Credits also go to Greg; 
we have been discussing some of this before.)

In essence:  There are (at least) three situations in which having to 
send the NS implies additional delays:  The NS must be preceeded by a 
MLD Report, and there is a delay of up to 1 second for the MLD Report 
after interface re-activation in RFC 2462bis.

There are two possible solutions:

(1)  Allow a MN to send the MLD Report without delay (like it may send 
an RS without delay according to RFC2461bis).
(2)  Allow the MN to use a tentative/optimistic address before the 
initial NS is sent.

I have proposed the first option on the IPv6 list where folks agreed 
that this should probably be attended to within the DNA WG.

I'm at a conference right now, but will try to wrap the draft up in between.

- Christian


++++
2.3.  Situation C

--- Routers on the new IP link do not support the TSLLAO for
RSs.  The mobile node solicits a unicast RA.

Soliciting a unicast RA requires the mobile node to send a RS from an 
optimistic address.

- MN sends a MLD Report for an optimistic address.
- MN sends a NS for the optimistic address, initiating ODAD.
- MN sends a RS from the optimistic address.
- MN receives a unicast RA.

The MLD Report (step 1) is delayed for up to 1 second 
(MAX_RTR_SOLICITATION_DELAY) because it is the first message transmitted 
after (re-) enabling the interface [RFC2462bis].

2.4.  Situation D

--- Routers on the new IP link do not support the TSLLAO for
RSs, but do send unsolicited multicast RAs every 30ms to 70ms according 
to rules in [RFC3775].

- MN receives a multicast RA.
- MN sends a MLD Report for an optimistic address.
- MN sends an initial NS for the optimistic address (ODAD).

The MLD Report (step 2) is delayed for two reasons.  First, it is the 
first message transmitted after (re-) enabling the interface.  This 
calls for a delay of up to 1 second (MAX_RTR_SOLICITATION_DELAY) 
[RFC2462bis].  Second, the MLD Report is sent in response to a multicast 
RA.  This also calls for a delay of up to 1 seconds 
(MAX_RTR_SOLICITATION_DELAY) [RFC2462bis].

2.5.  Situation E

--- Routers on the new IP link do not support the TSLLAO for
RSs.  The mobile node solicits a multicast RA.

The mobile node can send the RS from the unspecified address, 
eliminating the requirement to initiate ODAD at this point.

- MN sends an RS from the unspecified address.
- MN receives a multicast RA.
- MN sends a MLD Report for an optimistic address.
- MN send a NS for the optimistic address, initiating ODAD.

The RS (step 1) may be sent immediately, even though this is the first 
message transmitted after (re-) enabling the interface [RFC2461bis].

The multicast RA (step 2) is delayed for up to 3 seconds (maximum of 
MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) [RFC2461bis].

The MLD Report (step 3) is delayed for up to 1 second 
(MAX_RTR_SOLICITATION_DELAY) because it is sent in response to a 
multicast RA [RFC2462bis].
++++

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/



Erik Nordmark wrote:
> James Kempf wrote:
> 
>>> There is no technical reason for optimistic DAD to require that
>>> the NS be sent before or even after state change AFAIK. Do you
>>> see a technical reason?
>>> 
>> 
>> 
>> No, but unfortunately the oDAD document doesn't say anything about
>> this.
> 
> 
> I suspect the oDAD document has no need to say anything. It isn't
> until one tries to combine oDAD with DNA that the issue of separating
> the optimistic state change and the sending of the NS appears.
> 
>> Most implementors of oDAD will probably send it out when the state
>>  change to Optimistic happens, because the draft says that, but
>> when combined with DNA, I suspect there may be some confusion
>> unless we make it clear.
> 
> 
> Agreed.
> 
>> How about: the node SHOULD avoid sending the NS until after the RS
>> is returned?
> 
> 
> Or. more generally, until it has determined that it has moved to a
> new link. If an RS is returned which indicates that it didn't move,
> then there is no need to send an RS.
> 
>> Note that even if we do change the state to Optimistic, there is
>> still the issue I raised about the node originating packets with a
>> topologically incorrect source address if it has moved to a new IP
>> link. The only way to prevent that from happening is to make the
>> addresses Tentative (and suppress the DAD NS until after the RA
>> returns) until the node actually finds out in the RA whether it
>> actually has moved to a new IP link or not.
> 
> 
> Originating such packets is ok I think. If the host has moved to a
> new link it will not receive any "replies". It might make sense and
> assume that it didn't move in this case until it's discovered that it
> did move.
> 
> Erik