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. 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.
Some implementations have already adopted this "simplification" to
address the security concern, and, realistically, I don't think we can
convince the maintainer to cancel the change and introduce a
trickier patch to support the very minor case. The end result would
be the same: we'll lose interoperability. Of course, we could blame
such implementations for being "non compliant", but IMO it's more
productive to plug the tricky corner case as we'll probably never need
it in practice.
Other technical comments:
- 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.
- 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:-)
- Section 2: the section title "Host Behavior" is not very indicative
to me.
- 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.
[...]
- Section 3, 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 3, bullet 6: I don't understand this at all. Why is this
mentioned? Why only multicast?
- Section 3, bullet 7: this rule isn't enforceable. I thought I
already pointed it out before (please google it).
- Section 4, last para:
Using cached on-link determination information without first
[...]
This doesn't address my previous concern. Besides, this is not
really a "rule" even if it's in the "host rules" section.
- Section 6: I guess there should be a reference to the security
problem (cert advisory or something).
Editorial comments:
- Section 1 first para
s/a address/an address/
- Some of the acronyms should be expanded beforehand (ND, RA, etc)
- there are some redundant white spaces, e.g. "on- link" (should be
on-link)
- Section 3, bullet 4, there seems to be an indentation problem:
Similarly, the following text from section 6.2.5 of [RFC4861]
I suspect it's not part of citation.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
