>>>>> On Fri, 09 Jul 2004 05:58:48 -0400,
>>>>> Brian Haberman <[EMAIL PROTECTED]> said:
> This note starts the IPv6 WG Last Call on:
> Title : Optimistic Duplicate Address Detection for IPv6
> Author(s) : N. Moore
> Filename : draft-ietf-ipv6-optimistic-dad-01.txt
> Pages : 17
> Date : 2004-6-29
> as a Proposed Standard. The Last Call will end on July 23, 2004.
My substantial comments are basically based on the view that we only
accept this kind of approach if the impact on non-optimistic
implementations is limited very carefully and as small as possible.
SUBSTANTIAL COMMENTS
1. overall, this approach depends on reasonably small reachable time
(per Section 4.2 of RFC2461). If this value happens to be set to a
large value (say, a few to 10 minutes?) via RA, a duplicate
link-layer address of an optimistic node can mistakenly be stored
for the unreasonaly large period. While this is a general issue on
the reasonable value of reachable time, I think this draft should
explicitly note that since it is going to modify the existing
protocol and affect implementations. Perhaps we even need to define
the upper limit of reachable that to allow the optimistic behavior.
2. the optimistic behavior can cause (temporary) disruption when the
optimistic address collides with an address available via proxy ND
(as described in section 4.2). I think we need to make an explicit
consensus on whether this is acceptable (rather than an implicit one
like "no objections in the last call"). Perhaps the wg session in
San Diego is a good chance for this.
3. I don't think the advantage for the optimistic node when two nodes
simultaneously perform DAD is justified (Section 4.3).
This gives the Optimistic Node a slight advantage
over Standard nodes, however this is justified since the Optimistic
node may have already established connections to Optimistic
Addresses.
As we discussed in rfc2462bis, address duplication may in some cases
indicate hardware address duplication. Since continuing operation
under hardware address duplication can cause additional confusing
situation (even if one of the colliding node stops using the
duplicate IP address), I think no exception can be justified.
Additionally, we should have assumed actual duplication for an
optimistic address is very unlikely to happen. If so, giving
advantage under a nitch duplicate condition does not seem to provide
much actual benefit.
So, I'd request to simply remove the special privilege.
4. the optimistic behavior basically assumes routers send RAs with
SLLAO (e.g., the first sentence of section 2). But I'm not really
sure what the node should do if this assumption does not hold
(the last paragraph of Section 4.4 talks about this a little bit,
but it's still unclear and I'm not sure if this applies to the
entire behavior or it is just limited to the particular section).
5. I'm still not really comfortable with unsolicited NAs at the
beginning of the optimistic DAD procedure. This can increase the
possibility of disruption at the non-optimistic side. Since the
typical usage of the optimistic behavior assumes RAs with an SLLAO,
we don't really need such NAs for optimistic nodes to operate. I'd
rather prohibit these NAs.
SEMI SUBSTANTIAL COMMENTS
6. In section 2.2, the draft says:
[RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated
(in 5.5.4) Addresses. Addresses which are neither are said to be
Preferred. Tentative addresses may not be used for communication,
and Deprecated addresses should not be used for new communications.
These status flags may also be used by other standards documents, for
example Default Address Selection [RFC3484] uses these flags.
But at least RFC2462 does not define the notion of "Tentative" or
"Deprecated" as "flags". (and RFC3484 does not contain a word
"flag").
7. In section 2.2
Protocols which do not understand this state should
treat it equivalently to 'Deprecated', to indicate that the address
is available for use but should not be used if another suitable
address is available.
I don't really understand what "protocols which do not understand this
state" actually means. BTW, can an application (using the standard
socket API) perform the bind(2) system call for an optimistic address?
8. In section 2.2, the draft says:
When the DAD timer completes without incident,
the address becomes a Preferred address.
As far as I know, no RFCs define the notion of "DAD timer". Please be
more accurate on this. (The same comment should apply to some other
parts of the draft).
Additionally, even after the DAD procedure (successfully), the address
does not necessarily become a preferred one; the preferred lifetime
can be 0 from the beginning. (The same comment should apply to
Section 3.2)
9. In section 3.1
* (modifies 7.2.2) When a node has a unicast packet to send from an
Optimistic Address to a neighbour, but does not know the
neighbour's link-layer address, it MUST NOT perform Neighbour
Discovery but instead SHOULD forward the packet to the router of
that network.
"SHOULD" means there can be an exception, but in this case I don't see
a possibility of exception: what can the node do if it does not
perform ND or forward the packet to the router? Perhaps we can simply
say "MUST" instead of "SHOULD" here.
10. In section 3.2
* (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
its address from the unspecified address with a Neighbour
Advertisement to the All Nodes address. If the solicitation is
for an Optimistic Address, the reply MUST have the Override flag
cleared (O=0).
Does the first sentence apply to all nodes including "Standard" ones,
or is it limited to optimistic nodes? (I'd object to this
modification in the first place, BTW - see comment 5).
11. In section 3.2
* (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
an Optimstic Address from a unicast address, but the reply MUST
have the Override flag cleared (O=0).
Just a note: this may be a controversial change (see comment 2 above).
12. In section 3.2
* (modifies 5.4.5) An Optimistic Address that is determined to be a
duplicate MUST be deconfigured immediately. If the address is a
link-local address formed from an interface identifier based on
the hardware address (e.g. EUI-64), the interface SHOULD be
disabled. Otherwise, if the address was automatically
configured, DAD SHOULD be restarted with a new address.
(Appendix A suggests methods for generating a new address)
Just a note: we are going to clarify this case in rfc2462bis. Not
sure if it requires a change to the optimistic DAD draft though.
13. In section 4
The ON will immediately send out a Neighbour Solicitation to
determine if its new address is already in use, and a Neighbour
Advertisement (with the Override flag cleared) for the address. This
NA allows communication with neighbours to begin immediately.
What does "immediately" mean? Are you saying a random delay before
the first NS (in some situation) should be removed? The same comment
should apply to NA, while I object to sending such NAs in the first
place (see comment 5 above).
14. In section 4.1
The Optimistic Node already has the link-layer address of the router
(from the RA), and the router either already knows the link-layer
address of the ON from the unsolicited NA, or can determine it
through standard NUD.
I don't understand how the router can determine the link-layer address
through NUD...do you mean "ND" here?
EDITORIAL COMMENTS
15. this draft uses the term "Neighbour", but for this particular term,
I guess we should stick to the US standard "Neighbor", because the
base documents such as RFC2461 use the latter, and people may search
for related documents with (e.g.) "grep -i neighbor rfc*.txt".
(In this sense, I don't care about "behaviour":-)
16. the draft uses the term "suffix" to form an address with a prefix,
but I think it should rather be "interface identifier" based on the
formal definition used in other IPv6 related documents.
17. there appears to be a mixture on the notation between "an SLLAO" and
"a SLLAO". Those should be consistent. Also, if "an" is the
intended one, I guess phrase "a NC" (which occurs several times in
the draft) should actually be "an NC".
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
