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

[Christian Vogt <[e-mail]>]

Hey Nick.

> Ah, yes.  I see what you mean.
>
> Actually, even worse, "as soon as [it] is sent" is somewhat
> 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...

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

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.

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

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

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

Right.

- Christian

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



Nick 'Sharkey' Moore wrote:
> On 2005-10-17, Christian Vogt wrote:
> 
>>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!
> 
> 
> Cheers, thanks.  It's currently waiting on the IESG's final word ...
> 
> 
>>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.
> 
> 
> 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


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