Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

Brian Haberman <brian@innovationslab.net> Thu, 10 May 2007 14:16 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9RJ-0008RD-MR; Thu, 10 May 2007 10:16:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm92K-0000Qi-1s for ipv6@ietf.org; Thu, 10 May 2007 09:50:28 -0400
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm92I-0003Sa-RA for ipv6@ietf.org; Thu, 10 May 2007 09:50:28 -0400
Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.28898846; Thu, 10 May 2007 09:50:02 -0400
Message-ID: <46432309.1020902@innovationslab.net>
Date: Thu, 10 May 2007 09:50:01 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: IETF IPv6 Mailing List <ipv6@ietf.org>
References: <31D43DED-5BEE-4730-8FCB-476FA9EE1A97@eads.net>
In-Reply-To: <31D43DED-5BEE-4730-8FCB-476FA9EE1A97@eads.net>
X-Enigmail-Version: 0.94.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
X-Mailman-Approved-At: Thu, 10 May 2007 10:16:15 -0400
Subject: Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

>> 3.  Implementation
>>
>>    Compliant IPv6 hosts and routers MUST NOT transmit IPv6 datagrams
>>    containing RH0.
>>
>> ==> does 'transmit' include both 'originate' and 'forward' or just the
>> former?
> 
> I hope it is 'originate' (resulting from processing of a routing header
> addressed to the router).
> 
> 
>> I'd be interested in seeing comments from router vendors on the
>> feasibility of the blocking forwarding for type 0 routing headers (but
>> not other types).

Does a former router vendor count? :)

One problem I see with this is that there could be some confusion with
the word "forward".  That is, does it mean forward if the node receives
it as an arbitrary router along the path?  Or does it mean forward it
since it received it via one of its addresses being in the destination
address field?

> 
> Me too, but just for fun. This would imply possible processing of the
> whole extension headers chain. Even if it was possible from a
> performance standpoint, does anyone want that kind of filtering in the
> core ?
> 

RFC 2460 explicitly states that intermediate routers do not examine or
process extension headers while the packet is in transit.

What happens if the packet is encrypted?

> 
>> Would that include packets where the routing header wouldn't be the
>> immediate next-header (e.g., you'd put a hop-by-hop header or
>> something like that first, only then routing headers)?  That's even
>> more difficult as the implementation would need to skip through all of
>> them, possibly with a 'lookup depth' of the maximum packet size.
>>
>> AFAIK, usually the amount of bytes of the header available to ACLs is
>> limited, unless you punt the whole packet to the control processor
>> which is probably a treatment worse than the disease.
> 
> And this goes against one of the aim of IPv6 : limiting the work
> performed by routers.
> 
> 
> The sentence could be modified in :
> 
> "Compliant IPv6 hosts and routers MUST NOT process RH0 in packets
>   addressed to them. Those packets MUST be dropped without further
>   processing. In particular, the value of the Segments Left field
>   MUST not be considered."
> 

This is much clearer and easier to implement.

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------