Folks, The issue related to "the statement in our draft that says to not issue an address resolution for an IPv6 address that is not on-link" has been addressed by the following new and amended text in Intro section of our 04 draft that has been posted today. I also fixed a few typos in the new text below but the typos do exist in the -04 version.
OLD: A host only performs address resolution for IPv6 addresses that are on-link. Packets to any other address are sent to a default router. If there is no default router, then the node should send an ICMPv6 Destination Unreachable indication as specified in [RFC4861] - more details are provided in the Host Behavior and Rules section. (Note that [RFC4861] changed the behavior when the Default Router List is empty. The behavior in the old version of Neighbor Discovery [RFC2461] was different when there were no default routers.) NEW: IPv6 packets sent using the Conceptual Sending Algorithm as described in [RFC4861] only trigger address resolution for IPv6 addresses that are on-link. Note that transmission of ND messages is not governed by the Conceptual Sending Algorithm. Packets to any other address are sent to a default router. If there is no default router, then the node should send an ICMPv6 Destination Unreachable indication as specified in [RFC4861] - more details are provided in the Host Behavior and Rules section. (Note that [RFC4861] changed the behavior when the Default Router List is empty. The behavior in the old version of Neighbor Discovery [RFC2461] was different when there were no default routers.) Note that ND is scoped to a single link. All Neighbor Solicitation responses are assumed to be sent out the same interface on which the corresponding query was received. Thanks, Hemant -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, May 06, 2009 3:56 PM To: Thomas Narten Cc: erik.nordm...@sun.com; ipv6@ietf.org Subject: RE: comments on draft-ietf-6man-ipv6-subnet-model-03 Thomas, Fine. We will remove bullets 6 and 7 from section 2 of the document. To summarize progress thus far, we have also decided to keep the paragraph on Redirect bullet as is and not take new text. The only pending issue left now (after yours and Jinmei's comments) is what do we do with the statement in our draft that says to not issue an address resolution for an IPv6 address that is not on-link - see my recent email on this one. Thanks, Hemant -----Original Message----- From: Thomas Narten [mailto:nar...@us.ibm.com] Sent: Wednesday, May 06, 2009 3:49 PM To: Hemant Singh (shemant) Cc: JINMEI Tatuya / 神明達哉; Wes Beebee (wbeebee); erik.nordm...@sun.com; ipv6@ietf.org Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03 "Hemant Singh (shemant)" <shem...@cisco.com> writes: > -----Original Message----- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Wednesday, May 06, 2009 2:58 PM > To: Hemant Singh (shemant) > Cc: JINMEI Tatuya / 逾樊・驕泌悼; Wes Beebee (wbeebee); erik.nordm...@sun.com; > ipv6@ietf.org > Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03 > >> "WB> Routers decrement the Hop Limit field. Therefore, there is a > >> Hop Limit (255) that exists that can be used to indicate that > >> packet has not crossed a router. Note, however, that ND Proxy > >> explicitly keeps the Hop Limit the same, so this definition > >> (especially in the presence of networks that use ND Proxy) yields > >> a different notion of on-link than RFC 4861 and a different notion > >> of on-link than reception of link-scoped packets. > >Can you point to an RFC that supports the above? I didn't know proxies > >take liberties with the TTL field. And if they do, I suspect things > >will not work properly. > See the ND Proxy RFC of RFC 4389 and section 4.1. Also, an IPv6 > router is one IPv6 node that is expected to support ND Proxy. I > don't disagree with anything in the ND Proxy RFC. So why should we > not keep this bullet in our document? OK. I thought you were using a different notion of proxy (i.e., as is used by MIPv6, where the P bit is not used). Getting back to the original issue raised w.r.t. this point: draft-ietf-6man-ipv6-subnet-model-03.txt currently says: 7. Note that the receipt of a packet with the Hop Limit field unchanged (the Hop Limit could be specified in a packet-type specific document) which is not an ND packet indicates direct reachability on a link, but is not specifically treated by [RFC4861]. I do not see what value this text adds to the document and think it would be simplest to just remove it. Even now understanding what you meant by "proxy" in your followup response above, my opinion remains that the text in the document is not necessary or helpful. Thanks, Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
