Thomas, BTW, Erik sent this email to v6ops on June 25th, 2006 that the receiver should drop such an ND Message - it's snipped between quotes below.
"David Miles wrote: I'd also suggest that in the Message Validation section we include the checks you mention (is the source of the ND or target of the NA an on-link prefix per Prefix List) If you do that, how would communication work in your example? The NS would be dropped since its source isn't covered by an on-link prefix on the receiver, right? Erik" Anyhow, we already sent an email to Erik suggesting the following changes to our subnet-model draft. The gist of our changes are indeed to say that the 4th bullet of on-link definition is not a valid means to determine on-link. For reference, here is the URL to our draft. http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-00 .txt Here are the two changes we have proposed to our draft. 1. In Introduction section, here is new text: [In addition to the Prefix List, individual addresses are on-link if they are the target of a Redirect Message indicating on-link.] 2. In section 2, we reworded bullet 2 as follows: The configuration of an IPv6 address, whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6[RFC3315], or manual configuration MUST NOT imply that any prefix is on-link. A host is explicitly told that prefixes or addresses are on-link through the means specified in the definition of on-link in the Terminology section of [RFC4861]. The source of an ND message is no longer used for on-link determination, which is a change from [RFC4861]. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861]. Do the changes look OK to you and everyone else? Thanks. Hemant -----Original Message----- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 11:34 AM To: MILES DAVID Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org; [EMAIL PROTECTED] Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt "MILES DAVID" <[EMAIL PROTECTED]> writes: > Hemant, > Thanks for your patience. > Given we are now very clear that a receiver should drop any ND message > from a source that it is not in its prefix list, No, I would not go that far. There is no harm in responding to an NS for a target address that is assigned to your interface. Indeed, it is necessary to make communication work in some situtations. What should not happen, however, is to use reciept of an ND message as an indication that the sender of that message is on-link. (i.e., overriding or supplementing information learned from other means). Likewise, receipt of an NA should not be taken as an indication that the sender of that NA is on-link (i.e, anyone could just send out a broadcast NA with bogus info in it). One should NOT create a Neighbor Cache Entry upon receipt of a random (unsolicited) NA. (Luckily, the spec already says you shouldn't do this, though for different reasons.) But if one has issued an NS for a particular address (because one already believes the target is on-link), receipt of an NA should (of course) update the neighbor cache for that entry. > might I suggest the > paragraph in question be amended to say: > In addition to the Prefix List, individual addresses are on-link if > they are the target of a Redirect Message indicating on-link. > Removing the text: > or the > source of a valid Neighbor Solicitation or Neighbor Advertisement > message. > The clarification would be a step in the right direction. IMO, removing that line is the right thing to do. 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. :-) That said, we are clearly talking about an edge case situation here that hasn't come up in practice very often. So the urgency of fixing this is not terribly great, IMO. But going forward (i.e, in any new documents), we should do the right thing. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------