Overlall this is a good and important document which I'd like to
see standardized.
Here are some nits and clarifications, as well as some concerns about the
use of unsolicited advertisements.
Applicability question:
I think we understand the implications of having a host use an optimistic
address. But do we know what happens should a router use an optimistic
address (to start forming neighbour adjacencies using a routing protocol)
and then discovers that the address is a duplicate?
Should we limit the applicability to hosts, or explicitly say that
routing protocols should not use optimistic addresses?
Section 2.2 says:
When the DAD timer completes without incident,
the address becomes a Preferred address.
This isn't correct. Whether the address becomes preferred or deprecated
is a function of the preferred and deprecated lifetimes. If the preferred
lifetime is zero it will become deprecated after the DAD completes.
How about saying
When the DAD timer completes without incident,
the address becomes a Preferred or a Deprecated address based on its
preferred lifetime.
As I pointed out elsewhere, I think we should drop section 2.4.
If some predictive scheme needs this it can be specified in the future.
This effects the text in section 4.
Note that I don't see a need to prohibit unsolicited NAs with O=0,
thus the text in section 3.1 regarding them is ok.
I just don't see them as useful hence we shouldn't recommend that they be
sent.
Section 2.5 says:
When the ON wants to contact another neighbour, but it cannot because
the neighbour is not in its NC, it should instead forward the packet
to the router, relying on the router to forward the packet.
This begs the question "instead of what". Also, the ON might have other
non-optimistic addresses it can use to send a NS.
I suggest rephrasing it as
When the ON wants to contact another neighbour, but it cannot because
the neighbour is not in its NC and it has only optimistic address(es)
assigned
to the interface, then it can not send a Neighbour Solicitation message.
Instead it should send the packet
to the router, relying on the router to forward the packet.
Section 2.6 doesn't say anything useful for an implementor.
Do we want to say that optimistic nodes should retransmit the DAD probe 3
times? This wouldn't have much of a performance effect and it would improve
detection in the presence of packet loss. Given that optimstic support
might be common on nodes with wireless interfaces (which have higher packet
loss in many cases) this might be a reasonable improvement.
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.
Note that the procedure of sending a NS and getting a NA is called "address
resultion" in RFC 2461. Also, since the host might have other addresses it
can use for the NS.
I'd suggest:
* (modifies 7.2.2) When a node has a unicast packet to send from an
Optimistic Address to a neighbour, does not know the
neighbour's link-layer address, and only has optimistic addresses
assigned to the interface, it MUST NOT perform Address
Resolution by sending a Neighbour Solicitation message,
but instead SHOULD forward the packet to a default router on the link.
Section 3.1 says:
* When the DAD timer expires on an Optimistic Address, the
'Optimistic' flag MUST be cleared, and the address becomes a
Preferred Address.
I suggest:
* When the DAD timer expires on an Optimistic Address, the
'Optimistic' flag MUST be cleared, and the address becomes a
Preferred or Deprecated Address based on its preferred lifetime.
Section 3.1 says:
* (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)
Since the text in RFC 2462bis is being revised, how about referring to
that document instead of duplicating a probably stale snapshot of the behavior
in this document.
We could simply say:
* (modifies 5.4.5) An Optimistic Address that is determined to be a
duplicate MUST be deconfigured immediately, the same way
a tentative address is deconfigured when found to be a duplicate.
Further implications of an address being found a duplicate are
specified in [RFC 2462].
(Appendix A suggests methods for generating a new address)
Section 4 has:
, and a Neighbour
Advertisement (with the Override flag cleared) for the address. This
NA allows communication with neighbours to begin immediately.
I think this should be dropped if we agree that section 2.4 should be dropped.
The ON can communicate with neighbors by sending packets via a default router,
and neighbors can reach the ON my sending a NS and getting a NA with O=0.
Section 4.1:
After the appropriate DAD delay, the address's Optimistic flag is
cleared and another NA is sent, this time with O=1. This will ensure
that all Neighbour Caches are up-to-date.
I don't see this solving any problem. If the NCEs have stale information
(for whatever reason) NUD will take care of that. And there is nothing
in the operation of optimistic DAD which will create stale information
when there is no duplicate.
Thus sending unsoliciated NAs doesn't seem to help when there is no duplicate.
Section 4.3:
In contrast,
if a node attempts to configure an Optimistic Node's Optimistic
Address, the Optimistic Node will not deconfigure the address, and
instead defend with a Neighbour Advertisement, causing the newcomer
to reconfigure. 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.
I didn't find the details of how this defense works; in fact it seems
inconsistent with the text that says when the address is found to be a
duplicate it must be deconfigured.
In any case, I think trying to defend the address to control who wins is
complex; the risk is that multiple ONs would keep on responding with NAs at
each other to try to win. So simply having the first entity winning (i.e.
reception of a NS/NA when not in tentative or optimistic doesn't make the
address a duplicate, but reception of a NS/NA in those states forces
the address to be unconfigured) should be sufficient.
Section 4.4:
and if two nodes configure simultaneously, they may each miss
the other's NS.
I don't see how this can happen in standard DAD when there is no packet loss.
Thus I think standard DAD has problems when
- there is packet loss
- when nodes has intermittent connectivity to the link (which could be viewed
as a form of packet loss)
- then the link is partitioned (and later heals) since the DAD process is only
run when the addresses are configured and not continiously I suspect
optiDAD has the same limitations.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
