Thomas,
> Somewhat different. From an implementation perspective, one needs
> access to information (e.g., whether the router's link-layer address
> is in the cache) at a place in the implementation where that
> information is not necessarily readily availbale.
>
> But, looking back over the document again, I think I've convinced
> myself that this may not be a big issue after all.
>
OK.
> However, thinking and rereading leads me to two more thoughts:
>
> In off-list mail:
>
> Jari Arkko <[EMAIL PROTECTED]> writes:
>
> > > * Optimistic DAD SHOULD NOT be used to configure addresses unless
the
> > > probability of collision is exceedingly small.
>
>
> > I find it very hard to implement this. More guidance would be
> > needed. Did you mean "... SHOULD NOT when addresses have
> > been configured manually"?
>
> I tend to agree.
>
> Actually, I wonder if what is needed is more of an applicability
> statement saying what types of addresses it is appropriate to use this
> procedure for, and where not. For example, can optimistic DAD be used
> for the LL address? It took me some thinking to decide whether it
> could or not. The answer I believe is yes, but that is not immediately
> obvious, I would assert.
>
> But this all depends on having the link-layer address of a router in
> the cache (as had been discussed already).
>
Well, this brings up the reason why I asked for clarification.
In the DNA WG, we've been discussing how to handle the address state machine
when a host moves from one wireless AP to another, potentially with both APs
on the same IP link or not (the host doesn't know a priori from L2 info
after movement). There's nothing currently in the DNA DT draft on the topic
because we just got to discussing it when the draft was almost complete but
it is on the list of issues.
One way to handle this is for the host to classify the link local address as
"Optimistic" then use that as the source address of a DNA RS that is
multicast to All_Routers_Multicast. The RS is used to test whether the host
has moved, if the RA comes back "yes, you are on the same IP link", then no
additional configuration is necessary, if it comes back "no, you are on a
different IP link" there's configuration information (prefixes, whether
address configuration is stateful or not, etc.).
In this case, there is no need for the router's link address because the
host is sending the RS to an address that goes to the router anyway. And, if
the host can't use "Optimistic", it would have to DAD the link address,
potentially on every AP movement.
In addition, if the host *has* moved to a new IP link, the DNA RA will
provide the host with the router's link address, so it therefore potentially
is able to autoconfigure a new unicast global address on the new link, and,
putting it in "Optimistic" state, start using it for traffic by sending the
traffic directly to the router while the address is being confirmed.
In this case, the ability to use "Optimistic" greatly reduces handover
latency, and there doesn't seem to be an issue with routing through the
router because the RA provides the link address.
Do you see any issues with this that I might have missed?
> The second thought I have is that the security considerations section
> needs some more text, something along the following lines:
>
> Optimistic DAD takes steps to ensure that if another node is already
> using an address, the proper link-layer address in existing Neighbor
> Cache Entries is not replaced with the link-layer address of the
> Optimistic node. However, there are still scenarios where incorrect
> entries may be created, if only temporarily. For example, if a
> router (while forwarding a packet) sends out a Neighbor Solicitation
> for an address, the optimistic node may respond first, and if the
> router has no pre-existing link-layer address for that IP address,
> it will accept the response and (incorrectly) forward any queued
> packets to the optimistic node. The optimistic node may then respond
> in an incorrect manner (e.g., sending a TCP RST in response to an
> unknown TCP connection). Such transient conditions should be
> short-lived, in most cases.
>
OK.
> Likewise, an Optimistic node can still inject IP packets into the
> Internet that will in effect be "spoofed" packets appearing to come
> from the legitimate node. In some cases, those packets may lead to
> errors or other operational problems, though one would expect that
> upper layer protocols would generally treat such packets robustly,
> in the same way they must treat old and other duplicate packets.
>
It is true that an Optimistic attacker can do this, but, really, can't any
IPv6 node do it? An attacking node doesn't have to do DAD, it could simply
come on the link and start sending packets to the Internet with whatever
address it wants. It might not get anything back, of course, since any
response will get sent to the legitimate owner of the address.
jak
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
