Re: IPv6 Type 0 Routing Header issues

["Ebalard, Arnaud" <Arnaud.Ebalard at eads.net>]

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 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------