Thomas, 2nd ping. If you could please reply, that'd be great. I don't think the ship will return back to port to discuss anything related to on-link definition bullets three and four in our draft - that ship has sailed. So now that we have agreed to removing the line mentioned in the email chain below I hope you don't have anything objection to this para (from Introduction section of our draft), do you?
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. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism. Thanks. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hemant Singh (shemant) Sent: Thursday, July 10, 2008 2:28 PM To: Thomas Narten Cc: Brian Haberman; Bob Hinden; [email protected] Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt Thomas, Are you ok with the new paragraph if we removed this sentence from it: "As of the writing of this document, bullets three and four of the on-link definition are being debated and may need further clarification." Further, since Tatuya will not let us add any text that suggests new rules over RFC4861, we cannot accommodate any discussion related to bullet 3 and 4 of on-link definition in our draft. Please reply ASAP. Thanks. Hemant -----Original Message----- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2008 9:52 AM To: Hemant Singh (shemant) Cc: [EMAIL PROTECTED]; Bob Hinden; Brian Haberman; [email protected] Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt "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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
