Subject: Re: IPv6 Type 0 Routing Header issues

From: "Ebalard, Arnaud" <[email-masked]>
Date: Fri, 27 Apr 2007 14:38:37 +0200

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

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Apr 2007 17:43:04 -0700

On Apr 27, 2007, at 05:38, Ebalard, Arnaud wrote:
> Bob Hinden <[email-masked]> wrote:
>>
>>  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.
>
> 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, ...).

I agree that all transmissions of RH0 should be deprecated, and I  
further recommend the draft standards be amended to require that RH0  
be rejected with an ICMP error when received at the first destination  
and dropped silently in all other cases.  This will allow operators  
to identify and neutralize preemptively exactly those nodes which do  
not comply with the amended standard.

--
j h woodyatt <[email-masked]>