Thomas Narten wrote:
It is clear to me that bullet four in RFC 4861:
on-link - an address that is assigned to an interface on a
specified link. A node considers an address to be on-
link if:
- it is covered by one of the link's prefixes (e.g.,
as indicated by the on-link flag in the Prefix
Information option), or
- a neighboring router specifies the address as the
target of a Redirect message, or
- a Neighbor Advertisement message is received for
the (target) address, or
- any Neighbor Discovery message is received from
the address.
Is wrong and needs tweaking. We should fix that on the next update of
the ND spec. :-)
I agree that bullet four doesn't seem useful.
But I think the same thing applies to the third bullet above; I know of
no case where it is necessary or useful, and I think it is a potential
security issue if implemented on multi-interfaced nodes, since the
receipt of an NA on interface B could conflict with the fact that the
while prefix is on-link on interface A.
Popping up a level, we set out to clarify the subnet model in this
draft. Until recently I considered David's on-link issues to be separate
from the subnet model. But after catching up on this whole thread it
seems the two issues are closely related.
Hence my question for the WG. Should we expand the scope of
draft-ietf-6man-ipv6-subnet-model to also clarify/change the on-link
handling in RFC 4861?
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
