"Hemant Singh (shemant)" <[EMAIL PROTECTED]> writes: > Tatuya,
> Erik suggested some new text to us related to bullets 3 and 4 of on-link > definition in the Terminology section of RFC4861. He is busy this week - > we are sending this on his behalf. As you know bullet 4 is being debated > in 6man. Erik thinks even bullet 3 is suspect. We don't want such > suspect information to be lost in archived emails of 6man. So we added > the information to our draft. Please see the new paragraph from us: > The on-link definition in the Terminology section of [RFC4861] > defines the complete list of cases where an address is > considered on-link. Note, in particular, that Redirect Messages > can also indicate an address is off-link. As of the writing of > this document, bullets three and four of the on-link definition > are being debated and may need further clarification. > Individual address entries can be expired by the Neighbor > Unreachability Detection mechanism. > Please let us know if the new text works for you? It does not work for me. Looking at the bullets 3 & 4: > 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. IMO, bullets 3 & 4 MUST NOT be taken to indicate an address is on-link. Nowhere in the ND specification does receipt of an NA or NS result in the creation of a Destination Cache Entry that overrides the first two bullets. The first 2 bullets are the only way (excluding manual configuration) that an address is indicated to be on-link. Yes, there are cases where and NS will create or update a Neighbor Cache Entry, but that is NOT the same thing as indicating that the address is on-link. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
