IETF Logo Mail Archive

Re: IPv6 Type 0 Routing Header issues

james woodyatt <jhw@apple.com> Tue, 01 May 2007 00:43 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 1HigST-0002N7-5L; Mon, 30 Apr 2007 20:43:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HigSR-0002N2-PD for ipv6@ietf.org; Mon, 30 Apr 2007 20:43:07 -0400
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigSQ-00050q-E9 for ipv6@ietf.org; Mon, 30 Apr 2007 20:43:07 -0400
Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l410h5NY005683 for <ipv6@ietf.org>; Mon, 30 Apr 2007 17:43:05 -0700 (PDT)
Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id AADBA29C006 for <ipv6@ietf.org>; Mon, 30 Apr 2007 17:43:05 -0700 (PDT)
X-AuditID: 11807123-a0dd9bb0000013cb-cd-46368d19bdfe
Received: from [17.206.50.218] (il0602f-dhcp218.apple.com [17.206.50.218]) by relay5.apple.com (Apple SCV relay) with ESMTP id 9D57030400B for <ipv6@ietf.org>; Mon, 30 Apr 2007 17:43:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net>
References: <8A6FCC38-EA35-4EC2-A195-B8E327D50DA2@eads.net>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <4E7CB2B0-2AA7-43DB-840A-437240A4B653@apple.com>
Content-Transfer-Encoding: 7bit
From: james woodyatt <jhw@apple.com>
Date: Mon, 30 Apr 2007 17:43:04 -0700
To: IETF IPv6 Mailing List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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

On Apr 27, 2007, at 05:38, Ebalard, Arnaud wrote:
> Bob Hinden <bob.hinden@nokia.com> 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.
>
> 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, ...).

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 <jhw@apple.com>



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

v2.23.0 | Report a Bug | By Email