Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]

Tim Hartrick <tim@mentat.com> Fri, 27 April 2007 22:22 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 1HhYpz-00060d-Le; Fri, 27 Apr 2007 18:22:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYpy-0005vo-Ax for ipv6@ietf.org; Fri, 27 Apr 2007 18:22:46 -0400
Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhYnd-0001oJ-DU for ipv6@ietf.org; Fri, 27 Apr 2007 18:20:22 -0400
Received: from alerion.mentat.com (alerion.mentat.com [192.88.122.132]) by roll.mentat.com (Postfix) with ESMTP id 3FF7341141; Fri, 27 Apr 2007 15:19:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id 740533F0021; Fri, 27 Apr 2007 15:20:20 -0700 (PDT)
Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26219-05; Fri, 27 Apr 2007 15:20:19 -0700 (PDT)
Received: from [192.88.122.144] (feller.mentat.com [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 109523F0020; Fri, 27 Apr 2007 15:20:19 -0700 (PDT)
From: Tim Hartrick <tim@mentat.com>
To: bob.hinden@nokia.com
In-Reply-To: <0c126c4f66f44430f54517e287076133@message.md5>
References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <m2mz0xp6je.wl%gnn@neville-neil.com> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com> <0c126c4f66f44430f54517e287076133@message.md5>
Content-Type: text/plain
Organization: Packeteer, Inc.
Date: Fri, 27 Apr 2007 15:20:18 -0700
Message-Id: <1177712418.13779.23.camel@feller>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tim@mentat.com
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


Bob,

On Wed, 2007-04-25 at 17:39 -0700, Bob Hinden wrote:
> 
> We think the question for the IPv6 working group on this topic is  
> does the working group want to do anything to address the issues  
> raised about the Type 0 routing header.  Possible actions include:
> 
>   1) Deprecate all usage of RH0
>   2) Recommend that RH0 support be off by default in hosts and routers
>   3) Recommend that RH0 support be off by default in hosts
>   4) Limit it's usage to one RH0 per IPv6 packet and limit the number  
> of addresses in one RH0.
> 
> These examples are not all mutually exclusive.
> 
> Please respond to the list with your preference and justifications.
> 

I am a bit surprised that the security problems with the routing header
come as some sort of revelation at this stage.  The intent, as I recall,
in including this feature was to duplicate IPv4 source routing
(originally strict source routing was supported) with all the problems,
but get the specification of the processing cleaned up.  That was
accomplished in spades.  As I recall from my conversations with him,
Steve Deering never wanted this mess in the specification in the first
place.  I don't think it was part of SIPP but I don't have the spec
handy.  My recollection of a conversation with Steve on this topic back
in the previous century, at an IPv6 bake-off, was that it was "forced
upon us" by the politics of the IPng "process".  I think we can safely
put to bed the idea that the designers were dolts who didn't learn from
history.  That doesn't mean there weren't dolts involved in the
"process".:-)

That said I am in favor of 2.  It is the easiest to retrofit onto
existing implementations.  The question I have is what action should a
host and/or router take if it receives a datagram with a routing header
while support is disabled:

1) ICMPv6 destination unreachable/admininistratively prohibited.
2) Other ICMPv6 destination unreachable.
3) Silent discard.

I vote for 3 but I could be convinced about 1 or 2.  It appears that
IPv4 is supposed to do the equivalent of 1.


Tim Hartrick


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