Below are my comments on draft-ietf-ipv6-optimistic-dad-00.txt.
substantial
-----------
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...)
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?
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.
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.
semi-editorial
--------------
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
==> the current requirement is to have an updated boilerplate referring to
RFC3668. See some newer I-D's.
==> also the boilerplates at the end need to be added. These are:
Intellectual Property Statement
Disclaimer of Validity
Copyright Statement
Acknowledgment
Definitions of requirements keywords are in accordance with the IETF
Best Current Practice - RFC2119 [RFC2119]
==> this should be moved to Introduction because the Status of this Memo
section will be overwritten by the RFC editor and this would get lost here.
RFC References
Internet Draft References
==> rename to 'Normative' and 'Informative' References. The former should
include only Proposed Standard (or higher) or BCP RFCs which must be
understood to understand this spec. This could include e.g., RFC2119, 2373
(update to 3513!), 2461, 2462, 2464; 3041 would be OK. The rest would be
over in Informative (whether RFCs or drafts).
editorial
---------
Optimistic Duplicate Address Detection
==> should this be like 'Optimistic IPv6 Duplicate Address
Detection' or 'Optimistic Duplicate Address Detection for IPv6' ?
It is not the intention of this draft to improve the security,
==> s/draft/memo/ (so that no editing is needed after publication :)
(same later, 3-4 times)
2. Optimistic Behaviours
==> s/Behaviours/Behaviour/ ?
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/ ?
To avoid having to wait for
Neighbour Discovery, the ON may wish to send unsolicited
Neighbour Advertisements (with the Override flag set
appropriately), but for this to be effective the Neighbour must
either:
==> s/set appropriately/cleared/ ?
The ON may choose to send unsolicited NAs to the All Nodes Multicast,
to the All Routers Multicast, or Unicast to the source of the RA
which alerted it to this new prefix.
==> s/this/a/ (or 'the') ?
The case where the ON wants to contact its router is handled by the
SLLAO of the RA, where this is supplied.
==> 'this' is an ambiguous reference
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
