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

Re: optimistic dad comments

On 2004-05-31, Pekka Savola wrote:
> Below are my comments on draft-ietf-ipv6-optimistic-dad-00.txt.

Thanks for your feedback Pekka, I've added some thoughts/responses 
below.  All comments welcome!

> 1) The draft specifies that instead of using a tentative address as the
> source address for RS, another address or the unspecified address should be
> used instead.  To me, using the unspecified address would seem shortsighted,
> so I'd like to disallow its use in this context. (This might cause a
> problem, though, because I don't think the nodes typically have an another
> address they can use...)

You're right ... it's used when a node has no alternative.  
Using the unspecified address is allowed by RFC2461 6.3.7
(and this is unchanged in -bis-01) so it's a fallback
behaviour for OptiDAD.  Perhaps I need to be more careful
to explain this?

> 2) I don't think the memo is clear enough how a Tentative address on
> an ON compares to the tentative address on a standard node?  I mean,
> if the communication can proceed immediately, this would imply that
> the address should be flagged as non-tentative, or as
> "permanent-optimistic"  (which would be seen as non-tentative outside
> of Neighbor Discovery).  The point is, how are these addresses to be
> handled at RFC3484 and other documents which reference tentative vs
> non-tentative?

That's a really good point, and one I hadn't considered at all :-(.

I'll have a think.  I guess the obvious solution is to 
s/Tentative Address/Optimistic Address/ throughout.  But this would
add an extra state to neighbour discovery, confusing the issue with
RFC3484 further.  Perhaps I could indicate that Optimistic addresses
can be regarded as equivalent to Deprecated, eg: their use should
be avoided if there is an alternative.

> 3) IMHO, section 3.3 on Address Generation is largely redundant or downright
> inappropriate.  It describes a few useful things, but also goes on to
> specify how to regenerate the addresses if a conflict is found.  This is
> IMHO very much out of scope for oDAD.  At the very least, it should be moved
> to an appendix, but I'd vote for removal completely.

Okay, I can see your point.  Thinking about it, the logical place is
perhaps in 2462-bis ... replacing the 5.4.5 behaviour with something
a little more ... mobile-oriented.  Should I leave it as an appendix
in the meantime?

> What might be useful is specifying with which kind of addresses oDAD should
> be assumed: e.g., those addresses with the universal bit on are a prime
> target.  Also those addresses which are randomly generated (RFC3041 or SEND)
> should be OK.  Manual addresses or DHCPv6 in particular should be disallowed.

Yeah, I've said "The Optimistic algorithm SHOULD NOT be used on 
manually configured addresses [...]" in the aforementioned 3.3.

Which is kind of how all that address configuration stuff got drawn
in to OptiDAD in the first place.

> [various comments about boilerplate &c ]

noted.  I will be certain to fix these for -01.

>        An address collision with a router may cause neighbours'
>         IsRouter flags for that address to be cleared, however the RA
>         sent in response will reset the IsRouter flag.
> ==> s/however/even though/ ?

Hmmm.  Actually, I'm not happy with that clause at all, let
me have a think about it and get back to you all.

Thanks again for your feedback ... well, now there's a couple of
open issues I'll have to make an Issues List!

	more info: <http://www.ctie.monash.edu.au/ipv6/fastho/>

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6