[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00
From:       JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
Date:       2007-05-30 17:57:12
Message-ID: m11wgykxdz.wl%jinmei () isl ! rdc ! toshiba ! co ! jp
[Download RAW message or body]

At Tue, 29 May 2007 21:37:39 +0300 (EEST),
Pekka Savola <pekkas@netcore.fi> 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.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]