"Hemant Singh (shemant)" <[email protected]> writes: > Thomas,
> Did you see the reply Wes gave to respond to bullets 6 and 7 of > section 2 to the mailer? Anyway, please see in line below where I > have snipped in quotes what Wes explained bullets 6 and 7 were > about. Yes, I did see it. > -----Original Message----- > From: Thomas Narten [mailto:[email protected]] > Sent: Wednesday, May 06, 2009 1:28 PM > To: JINMEI Tatuya / ç¥æéå > Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email protected]; > [email protected] > Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03 > >> > >> - Section 2, bullet 6: I don't understand this at all. Why is this > >> mentioned? Why only multicast? > >This section says: > > 6. Note that the receipt of a link-local IPv6 multicast packet which > > is not an ND packet indicates direct reachability on a link, but > > is not specifically treated by [RFC4861]. > >I also don't know what this is trying to say or why it needs to be > >said. Can we just remove it? > "WB> This was mentioned because the all-nodes link-scope multicast > address FF02::1 can be used to map out all the nodes that are > accessible on a link, and thus be used to determine on-link. Yes. But so? > However, that is a different definition of on-link than RFC 4861 > uses. It may be applicable to MANET and other groups at IETF. I don't think it is wise for us to get involved with things that MAY be applicable to something else that is not yet defined. Since we are not preventing them from doing something, that is good enough. IMO, mentioning this sort of thing just adds confusion and doesn't help us get closure on this document. > Therefore, for the sake of completeness on the topic of on-link > determination, we chose to describe it here so that future IETF'ers > who will expand Neighbor Discovery to include MANET may use it as > reference. However, upon another read of the text, it's clear that > any reception of a link-local packet will yield the same definition > - so we can drop the word "multicast" from this bullet." I'd prefer the entire bullet be removed. It adds nothing to the real purpose of this document (IMO), which is clarifying the ND spec. > >> - Section 2, bullet 7: this rule isn't enforceable. I thought I > >> already pointed it out before (please google it). > >This section 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 don't understand what this paragraph is trying to say or why it > >needs to be said, so I'd support removing it. > "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. > Also, this fact has been mentioned by the MANET team - and I expect > that they can use this notion as they explore what a "link" means in > the MANET world. Further, please note that this bullet is in the > Host Behavior section and is treated as an observation for the > benefit of those who will modify Neighbor Discovery in the future > (the MANET/LOWPAN team)," Let us please not get distracted by what the MANET team may or may not be thinking. IMO, this text is a distraction and doesn't help this document. It would be better/easier to just omit it. I.e, the fact that were are discussing this text (which doesn't add any real value that I can see) is presumably one reason why this document is still not done... :-( Thomas
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
