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

Ignatios Souvatzis <ignatios@cs.uni-bonn.de> Fri, 27 April 2007 12:53 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 1HhPx0-00070b-Sh; Fri, 27 Apr 2007 08:53:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPwy-0006vS-W0 for ipv6@ietf.org; Fri, 27 Apr 2007 08:53:24 -0400
Received: from postfix.iai.uni-bonn.de ([131.220.8.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPwx-0007hi-LO for ipv6@ietf.org; Fri, 27 Apr 2007 08:53:24 -0400
X-IAI-Env-From: <ignatios@cello.cs.uni-bonn.de> : [131.220.4.211]
Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 7A9485C830 for <ipv6@ietf.org>; Fri, 27 Apr 2007 14:53:22 +0200 (MEST) (envelope-from ignatios@cello.cs.uni-bonn.de) (envelope-to ipv6@ietf.org) (1) (internal use: ta=0, tu=1, te=0, am=-, au=-)
Received: from cello.cs.uni-bonn.de (cello.cs.uni-bonn.de [131.220.4.178]) by theory.cs.uni-bonn.de (8.12.9/8.12.9) with SMTP id l3RCrMb6012150 for <ipv6@ietf.org>; Fri, 27 Apr 2007 14:53:22 +0200 (MEST)
Received: (from ignatios@cello.cs.uni-bonn.de) by cello.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb4 7oct2003); Fri, 27 Apr 2007 14:53:22 CEST (sender ignatios@cello.cs.uni-bonn.de)
Date: Fri, 27 Apr 2007 14:53:22 +0200
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Message-ID: <20070427125322.GC952@cs.uni-bonn.de>
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> <CE11116E-DF68-481D-AB30-E592C339CEFB@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CE11116E-DF68-481D-AB30-E592C339CEFB@nokia.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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
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

On Wed, Apr 25, 2007 at 05:39:40PM -0700, Bob Hinden wrote:
> [trimming this to just the IPv6 w.g.]
> 
> 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.

It seems to me 2, maybe combined with 4, would be appropriate for now.

I've read or thought about two theoretical uses:

- use it to enforce a specific path that's less costly (commercially)
  than the default, or to avoid crossing a hostile part of the network.

  It occurs to me that access to such a path would probably be secured
  by IPSec or similar; naked, unsecured redirection would be useless in
  this context.

- use it to access otherwise unrouted to the public networks
  Again, those would either be guarded by IPsec or some other VPN
  technology, or not really useful.

Anyway, if any such setup would need RT0 in a controlled enviroment, it
could be switched back on there. (After controlling RT0 *transmission*
past the environment borders.)

Regards,
	-is

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