I didn't read this thread sufficiently carefully the first time around,
and looking at draft-ietf-6man-subnet-model-02 there is one change which
isn't necessary and that makes ND a bit inconsistent.
Thomas Narten wrote:
If the original intent of the spec authors was to ignore these
additional conditions in the conceptual sending algorithm, I'll more
strongly agree that removing the third and fourth bullets is the right
way to go.
At least this original author doesn't recall *intending* that the
additional bullets be ignored. That is, I don't recall that we
intentionally put bullets 3 and 4 into the document for a particular
reason. Rather, I think this is just a classic case of imprecise text
not being caught during earlier review cycles. :-(
FWIW I don't remember a good reason either. I might have believed they
would be useful for "large clouds" i.e., non-broadcast multiple-access
links were a node might not be aware of all the on-link prefixes used on
the link. But I've verified that even in for such cases these rules
wouldn't be necessary.
We should also note that invalidating the part of on-link definition
affects other parts of RFC4861. For example, it will invalidate this
point:
If the Source Address is not the unspecified
address and, on link layers that have addresses, the solicitation
includes a Source Link-Layer Address option, then the recipient
SHOULD create or update the Neighbor Cache entry for the IP Source
Address of the solicitation.
(section 7.2.3)
we should also clearly state each affected part is invalidated;
otherwise, the reader will be confused about the discrepancy.
Yes. This makes sense.
That change is what I have a problem with.
This thread has already correctly concluded that the next-hop
determination in the conceptual sending algorithm is unaffected by the
content of the neighbor cache. Thus a node can update and create
Neighbor Cache Entries without any impact on the interface and nexthop
used to send packets. And since the conceptual neighbor cache is per
interface there is no security issue with accepting such packets.
Thus the change isn't necessary to solve the problem at hand.
Furthermore, if the effect of this change is anywhere near to the code
change sugegsted in this FreeBSD comment that was quoted earlier, then
we can create interoperability problems:
+ /*
+ * According to recent IETF discussions, it is not a good idea
+ * to accept a NS from an address which would not be deemed
+ * to be a neighbor otherwise. This point is expected to be
+ * clarified in future revisions of the specification.
+ */
If node A and node B are on the same link and the router advertisements
list prefix P1 as on-link, but node B also is statically configured with
prefix P2 as on-link, then dropping such an NS can lead to A and B
failing to communicate. Node B might send a NS with source P2::B looking
for the target P1::A, and the above text says to drop it.
With this part unmodified the conceptual model in RFC 4861 the effect is
that A creates a NCE for P2::B and responds to the NS with a NA.
Subsequent to that B would send packets directly to A, and A would send
the packets via a router (since A doesn't have P2 as an on-link prefix.)
Thus I suggest we just change the minimal thing to remove the security
concern, which is removing bullet three and four from the on-link
definition in RFC 4861.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
