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!
-----Nick
more info: <http://www.ctie.monash.edu.au/ipv6/fastho/>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
