JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<jinmei_tat...@isc.org> writes:
> Upon request from the author, I've reviewed the I-D, and here are my
> comments.
> I have one top level comment: I'm okay with removing the following two
> bullets from the original "on-link" definition of RFC4861
> - a Neighbor Advertisement message is received for the
> (target) address, or
> - any Neighbor Discovery message is received from the address.
> to address security concerns.
> But then I'd like to further simplify the rule of processing
> incoming NSes by discarding ones if the source address is not
> on-link.
I would be concerned with doing this, because it would lead to failure
cases in situations that I believe will happen in practice. That is,
it would make ND less robust than it is today or needs to
be. Specifically, such a rule would result in Node A not being able to
communicate with Node B, if for some reason Node A thought B was
on-link (and it really is), but Node B for some reason thinks it is
not on-link (whatever it means for a node to think its own address is
not on-link) and thus refuses to respond to a perfectly legitmate NS.
I don't see a good reason to ignore an NS from a neighbor asking about
a target address that is assigned to my interface. Not responding to
such a message could result in loss of connectivity. Sure, you can
argue this is a misconfiguration, but it could also result when RAs
aren't being delivered reliably, and one node has received a
particular RA, but another node has not, so they have differing
information. Or, node A may have been manually configured to assume
node B as on-link (and it is in fact).
> Removing the above bullets while allowing accepting
> incoming NSes from a non-on-link address (and responding to them)
> could make implementation very tricky for very little benefit.
I don't understand this. Nodes should be responding to NS queries for
target addresses that are assigned to the receiving interface. There
is no need for a node to even bother knowing whether that address is
considered "on-link" as a result of PIO options. There just isn't a
reason to do so (and it would be more work!). If someone asks about
one of the addresses you have assigned, just respond Why would you
not?
> - Section 1 doesn't explain the motivation of removing the last two
> bullets of on-link definition. I actually expected such
> incompleteness because it was not in the original goal of this
> draft. That's why I insisted that this part is in a separate
> document.
This is covered in Section 3. Arguably, that text could be made more
clear. Is your concern with the location of the motivation, or the
content?
> - Section 1:
> Due to the tricky implication on on-link vs being neighbor (see
> above), if we wanted to keep it (note that I'm against it) the
> following cannot hold:
> A host only performs address resolution for IPv6 addresses that are
> on-link.
> because the host would have to perform address resolution for a
> "neighbor" but not necessarily an on-link node. (if we also remove
> the tricky implication, this can be automatically solved:-)
I must be missing something. One only runs ND on an address when
sending a packet to an address, and the Conceptual Sending Algorithm
indicates the address is on-link. Right?
> - Section 2: I simply didn't understand the following paragraph at
> all. Please elaborate (I guess I asked the same thing before and it
> hasn't improved)
> 2. Note that Redirects cannot signal that an address is off-link.
> [...]
OK, how about the following text
OLD:
2. Note that Redirects cannot signal that an address is off-link.
In section 8.1 of [RFC4861], a Redirect message is silently
discarded if it does not have an IP source address that is the
same as the current first-hop router for the specified ICMP
Destination Address. An ICMP Destination Address on the same
link would have no current first-hop router. Any Redirect
message received could not have an IP source address that is the
same as the current (null) first-hop router, so the Redirect MUST
be dropped.
NEW:
2. Note that Redirect Messages do not contain sufficient
information to signal that an address is off-link. Rather, they
indicate a preferred next-hop that is a more appropriate
choice to use than the originator of the Redirect. That
alternate next-hop may be the destination itself (in which case
packets would flow directly to a neighbor), or a router closer
the destination. Note, however, that the redirect message
itself does not contain sufficient information to distinguish
these cases. But that does not matter, because the receiver of
such a message does the same in either case, updating its
Neighbor Cache as defined in Section 8.1 of [RFC4861].
> - Section 2, bullet 3. I disagree with this bullet as stated above.
> I won't go into further details on this at the moment because it's a
> rather meta level issue.
>
> - Section 2, bullet 6: I don't understand this at all. Why is this
> mentioned? Why only multicast?
This section says:
6. Note that the receipt of a link-local IPv6 multicast packet which
is not an ND packet indicates direct reachability on a link, but
is not specifically treated by [RFC4861].
I also don't know what this is trying to say or why it needs to be
said. Can we just remove it?
> - Section 2, bullet 7: this rule isn't enforceable. I thought I
> already pointed it out before (please google it).
This section says:
7. Note that the receipt of a packet with the Hop Limit field
unchanged (the Hop Limit could be specified in a packet-type
specific document) which is not an ND packet indicates direct
reachability on a link, but is not specifically treated by
[RFC4861].
I don't understand what this paragraph is trying to say or why it
needs to be said, so I'd support removing it.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
