At Tue, 29 May 2007 21:37:39 +0300 (EEST), Pekka Savola <[EMAIL PROTECTED]> wrote:
> > - section 3.1 > > > > IPv6 implementations are no longer required to implement RH0 in any > > way. > > > > I don't understand why we bother to say this. Isn't it enough to > > state "IPv6 nodes MUST NOT originate IPv6 packets containing RH0."? > > Only commenting on this as I feel rather strongly on this.. > > I don't think the wording you propose is good. That begs the > question, is a compliant IPv6 node required to prevent origination of > RH0? I.e., if a user, through a raw socket for example, were to send > RH0, would the node be required to drop it? What about if the IPv6 > API is used to try to originate such a RH0 packet? > > I don't think this is what you're suggesting, and a "MUST NOT > originate" seems to be on the borderline of the past Robert Elz's > RFC3513 appeal of unclarity in the spec. > > However, I agree that the current wording could probably be better. Please let me clarify my comment. I didn't *propose* the "MUST NOT" sentence; I simply cited it from the draft. The following is a verbatim and complete copy of Section 3.1 of the candidate draft: =========================== from here =========================== 3.1. Origination IPv6 nodes MUST NOT originate IPv6 packets containing RH0. IPv6 implementations are no longer required to implement RH0 in any way. ============================ to here ============================ I understand the intent of the first sentence; but as you might point out I agree this statement may be debatable (see below). What I wanted to say in my previous message is that I don't understand the intent of the second sentence while having the first sentence. Hopefully this time I'm clearer. In any event, to be possibly a bit more productive I guess I agree with you. I don't think specifying the originating side makes much sense; attackers would still originate RH0 anyway (e.g., via a raw socket, BPF, etc) in a hope of attacking non-updated packets whatever the deprecation document states. It sounds to me like "a node MUST NOT send a packet containing a digital virus that can exploit the receiving node". Meanwhile, new implementations will naturally and eventually stop including a code path that originates RH0 (e.g., by deprecating the corresponding API knob) upon the deprecation of RH0 even if the document does not explicitly specify the originating side behavior. It just looks sufficient to me. So, if I were to ask, I'd simply suggest removing section 3.1 altogether. (But I don't necessarily oppose to specifying the originating side; it just looks meaningless to me, but I agree it at least doesn't do harm). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------