Re: IPv6 Type 0 Routing Header issues

"Ebalard, Arnaud" <Arnaud.Ebalard@eads.net> Fri, 27 April 2007 12:39 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 1HhPj4-0003WV-4m; Fri, 27 Apr 2007 08:39:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPj2-0003WO-LV for ipv6@ietf.org; Fri, 27 Apr 2007 08:39:00 -0400
Received: from ns2.its.eads.net ([193.56.40.67] helo=mx2.its.eads.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPj1-0001jB-87 for ipv6@ietf.org; Fri, 27 Apr 2007 08:39:00 -0400
Received: from fr-gate2.mailhub.intra.corp ([53.154.16.34]) by mx2.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Apr 2007 14:36:36 +0200
Received: from sfrsu800.hq.corp ([10.21.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Apr 2007 14:41:51 +0200
Received: from [172.16.23.99] (10.251.5.23 [10.251.5.23]) by gecko.hq.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H92ZK7JH; Fri, 27 Apr 2007 14:48:49 +0200
X-Mailer: Apple Mail (2.752.2)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 27 Apr 2007 14:38:37 +0200
Message-ID: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IPv6 Type 0 Routing Header issues
Thread-Index: AceIymbYA+ItkeiOTE2Pclpc/4UQeg==
From: "Ebalard, Arnaud" <Arnaud.Ebalard@eads.net>
To: Alun Evans <alun@cisco.com>
X-OriginalArrivalTime: 27 Apr 2007 12:41:51.0812 (UTC) FILETIME=[6DF7F840:01C788C9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: ipv6@ietf.org, Gert Doering <gert@space.net>, Tony Hain <alh-ietf@tndh.net>
Subject: 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

Hi Alun, Hi *,

Le 27 avr. 07 à 11:04, Alun Evans a écrit :

>> I would be interested in a list of cases FOR the Type 0 Routing
>> Header.  If there are no good cases for it, it seems to me that
>> removing it is the best thing to do.
>
> I quite like traceroute for the return path.
>
> Which would also explain why Hosts are meant to process the routing
> header.

The thing is that we are dealing here with IPv6, the network layer  
protocol that we expect to carry most of the data and communications  
exchanged in the world in a near future.

What we want that protocol to provide is an efficient and resilient  
service. As we all know (i hope so), this can only be achieved by  
keeping its basis light and simple, and preventing useless extensions  
to pollute routers' stacks (especially core routers). This has been a  
design goal of IPv6, to limit the processing performed by routers (no  
checksum in IPv6 header, fixed size, limited number of fields, no  
fragmentation in the network, smart address aggregation, ...). IMHO,  
having RH0 in the specification is an error.

You more than many others should agree on the fact that complexity  
and stability/security do not fit well together, especially in  
stacks' implementations :

- Cisco IOS had implementation issues regarding RH0,
- all *BSD stacks (including Mac OS X) also made mistakes regarding  
RH0 processing,
- Linux just prevented its use even in router mode (2.6.20.9).

And those points are only implementation issues. So if you add to  
those facts that the mechanism is also potentially impacting at the  
infrastructure level, I think this clearly outweighs the  
"convenience" of remote traceroutes and co., which by the way seem to  
be used by 3 geeks around the world.

 From my perspective, RH0 should be deprecated to simplify IPv6  
specification, stacks' implementations and suppress associated  
threats. Keeping the generic RH mechanism will be sufficient for new  
protocols to __carefully__ provide associated functionalities (if  
any), just like the designers of Mobile IPv6 did with RH2 (IMHO,  
processing limited to MIPv6 implementations, no external forwarding,  
one address max, ...).

Cheers,

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026


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