Subject: Comment on draft-ietf-ipv6-optimistic-dad-06.txt

From: Christian Vogt <[email-masked]>
Date: Mon, 17 Oct 2005 19:14:10 +0200

Hi Nick, hi everybody.

First of all, I take up the cudgels for this draft.  It defines an
optimization which is going to be a prerequisite for efficient mobility
support.  The draft is in excellent shape, too.  Overall, very good work!

One thing, though.  Section 3.3 of the draft says:

>> * (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'.

Requiring the initial NS to be transmitted *before* the Optimistic
Address (OA) becomes operable can imply delays that defeat the purpose
of ODAD.

Specifically, if the initial NS would be the Optimistic Node's (ON)
first message on that link, the ON would have to send an MLD Report
prior to that NS [1].  The MLD Report, in turn, would have to be delayed
by up to a second.  A similar thing happens when configuration of the OA
was triggered by a multicast RA.

The MLD Report ensures that ODAD works over links with snooping
switches.  Its delay serves to avoid collisions when multiple nodes
configure simultaneously [1].

Note that these delays apply, e.g., to mobile nodes handing off to a new
link and configuring a new Mobile IPv6 care-of address by means of ODAD.

We wrote a draft with more details about this issue and also some
solutions [2].  The easiest solution seems to be to allow use of the OA
already prior to transmission of the inital NS.  There has also been a
discussion on the this mailing list [3] and the DNA mailing list [4].

Presumably the reason why the draft currently says that the first NS
must be sent prior to OA configuration is that you want to get the ODAD
process going before the OA is ready for use.  This ensures that the OA
will be in Optimistic state for a pre-defined time period only.  But
there are other ways to limit the duration of the Optimistic state.

Another reason for having to send the initial NS prior to OA
configuration might be that a collision could be revealed before
upper-layer communications make use of the OA.  But since an application
can seize the OA immediately, there is a race condition anyway.
Furthermore, the NS might get lost, which is why Optimistic DAD sends
multiple NSs.

Let me know what you think about this.

Best regards,

- Christian

[1]  IPv6 Stateless Address Autoconfiguration, RFC 2462bis, section
5.4.2, http://www.watersprings.org/pub/id/draft-ietf-ipv6-rfc2462bis-08.txt

[2]  Analysis of IPv6 Relocation Delays,
http://www.ietf.org/internet-drafts/draft-vogt-dna-relocation-01.txt

[3]  "Comment on RFCs 2461bis and 2462bis", Discussion
on the IPv6 mailing list, May 27, 2005,
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html

[4]  "DAD and MLD Interaction", Discussion on the DNA
mailing list, June 13, 2005,
http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-06/msg00098.html

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 19 Oct 2005 21:47:15 +1000

> support.  The draft is in excellent shape, too.  Overall, very good work!

Cheers, thanks.  It's currently waiting on the IESG's final word ...

> Address (OA) becomes operable can imply delays that defeat the purpose

Ah, yes.  I see what you mean.

Actually, even worse, "as soon as [it] is sent" is somewhat
ambiguous given L2 queuing, etc. 

I'm thinking that:

1) Need to clarify this clause: "* The Optimistic Address is available
for use immediately.  The address MUST be flagged as 'Optimistic'."
would probably be sufficient.

2) Need to add a point to address the MLD clauses mentioned in 2461/2.
I'd welcome your suggestions!

Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis,
because it's Standards Track and the -bis documents ain't RFCs just
yet.  This may, of course, change.

-----Nick

---

From: Christian Vogt <[email-masked]>
Date: Wed, 19 Oct 2005 22:53:45 +0200

Hey Nick.

> ambiguous given L2 queuing, etc.

True, but you could consider this to be written from the IP layer's
perspective, where "sending" a message would mean delivering it to the
interface layer.  Anyway...

> would probably be sufficient.

Maybe you add the following text to ensure that the inital Neighbor
Solicitation cannot be delayed indefinitely.  After all, you want to
kick-start the verification process as early as possible in order to
resolve a potential address conflict quickly.  The text below also
addresses the MLD clauses which you mention later in your email.

"The initial Neighbor Solicitation MUST be transmitted as early as
possible after the Optimistic Address has been flagged as 'Optimistic',
but it MUST NOT violate any delays or rate limitations set forth by
RFC2461 or RFC2462.  In particular, if the initial Neighbor Solicitation
is the first message to be sent from an interface after interface
(re)initialization, the node should delay this message by a random delay
between 0 and MAX_RTR_SOLICITATION_DELAY [RFC2461] as specified in
RFC2461.  Furthermore, if sending the initial Neighbor Solicitation
requires prior transmission of a Multicast Listener Discovery (MLD)
report message [RFC2710] [RFC3810], which then is the first message to
be sent from the interface after interface (re)initialization, both the
MLD report message and the initial Neighbor Solicitation should be
delayed by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY
[RFC2461]."

Note that the reasons for possibly having to delay the initial Neighbor
Solicitation are already given in RFC2461.  This, in turn, is cited, so
you don't need to repeat the reasons in the ODAD draft.

> I'd welcome your suggestions!

As mentioned before, this is also addressed within the text above.

> yet.  This may, of course, change.

Right.

- Christian

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 31 Oct 2005 14:12:02 +1100

On 2005-10-19, Christian Vogt wrote:
> RFC2461 or RFC2462.

Actually, I disagree.  In order to provide timely address configuration,
we MUST violate these delays.  

As I understand it, until we've performed the MLD report, we can't
reliably receive NSes ... and thus we may not be able to send our
NA(O=0) and can't respond to communications!

Also, the longer we delay the NS, the longer we have to wait to discover
a collision.  This is a big disadvantage to the arriving node, because
in the case of a collision it's not getting any traffic.  It's also
a small disadvantage to the collidee, because it may get traffic 
which was meant for the arriving ON.

I think L2 collision avoidance is best left to L2 in any case.
Elimination of these delays was proposed by some "Fast RS" draft
or another at some point, although I don't think I ever wrote up
the Soft vs. Hard Handover draft I'd been intending to ...

-----Nick

---

From: Christian Vogt <[email-masked]>
Date: Mon, 31 Oct 2005 13:48:00 +0100

> Actually, I disagree.  In order to provide timely address
 > configuration, we MUST violate these delays.

Nick,

my assumption in writing the above text passage was that the
delays for MLD Reports should be relaxed elsewhere, e.g. as part of 
RFC2462bis.

On the other hand, thinking more about this...

...there was consensus on the IPv6 mailing list [1] not to include any
specific support for mobility into the successors to RFC2461/2462.  At
least, this was said in the context of delays imposed on MLD Report
transmissions.

(Note:  IMO, this is a bit of a bummer, because RFC2461bis already
explicitly allows mobile nodes to forego the delay for Router
Solicitations; see section 6.3.7 in RFC2461bis.  So it could 
theoretically include an equivilant passage for the MLD Report, too. 
Anyway...)

Instead, the discussion in [1] yielded that mobility optimizations ought
to be specified in separate documents.  And thinking about this, 
draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document.  So 
it could/should allow Optimistic Nodes to forego the delays defined in 
RFC2461[bis] or RFC2462[bis] where necessary and feasible.

This said, the revised text passage for 
draft-ietf-ipv6-optimistic-dad-06.txt could look like this:

"The initial Neighbor Solicitation MUST be transmitted as early as
possible after the Optimistic Address has been flagged as 'Optimistic'. 
  Where other standards require the Optimistic Node to delay sending the 
initial Neighbor Solicitation for the purpose of contention resolution, 
it is RECOMMENDED that the Optimistic Node omit such delays if 
sufficient means for de-synchronization are provided otherwise.  E.g., a 
mobile node can omit delaying the first message sent upon arrival at a 
new link [RFC2461] [RFC2462] because mobility generally serves to 
de-synchronize signaling to an appropriate extent already.  Care must be 
taken, however, not to confuse an initial link attachment after boot-up 
with a link attachment after movement."

Note that this text implicitly attends to delays on MLD Reports as 
specified in RFC2462bis.  It is also general enough to deal with L2 
technologies that have no collision avoidance (even though I agree with 
you that L2 collision avoidance should be left to L2 in any case).

One could argue for changing "it is RECOMMENDED that the Optimistic Node 
omit such delays if..." to "the Optimistic Node MUST omit such delays 
if...", but I'd prefer the less strict version.

Regards,
- Christian

[1]  "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6
      mailing list, May 27, 2005, <http://www1.ietf.org/mail-archive/
      web/ipv6/current/msg05084.html>.