Re: New Routing Header!!!

Dow Street <dow.street@linquest.com> Fri, 31 August 2007 15:11 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 1IR8AB-0003oe-9r; Fri, 31 Aug 2007 11:11:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8AA-0003jw-0O for ipv6@ietf.org; Fri, 31 Aug 2007 11:11:58 -0400
Received: from smtp167.iad.emailsrvr.com ([207.97.245.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8A8-0000Gm-Qp for ipv6@ietf.org; Fri, 31 Aug 2007 11:11:57 -0400
Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTP id 2C4A36A9883; Fri, 31 Aug 2007 11:11:55 -0400 (EDT)
In-Reply-To: <46D7DDEB.6040701@piuha.net>
References: <77ead0ec0708280131q74d7041fod779e907b589b3d@mail.gmail.com> <200708291408.l7TE8eJO029246@cichlid.raleigh.ibm.com> <46D5D148.6080701@gmail.com> <20070830084658.GA241@cs.uni-bonn.de> <46D72930.3020402@gmail.com> <77736C78-4837-4949-A732-9137504DEE6A@linquest.com> <46D740C9.1050103@gmail.com> <F8DF4E6C-42FB-4B42-9B2A-42D68076E324@linquest.com> <46D7DDEB.6040701@piuha.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <3CE2E174-7B18-4344-B4E4-00092B11A447@linquest.com>
Content-Transfer-Encoding: 7bit
From: Dow Street <dow.street@linquest.com>
Date: Fri, 31 Aug 2007 08:11:39 -0700
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: IPv6 WG <ipv6@ietf.org>
Subject: Re: New Routing Header!!!
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 Aug 31, 2007, at 2:22 AM, Jari Arkko wrote:

>> - If a "consenting nodes only" model is adopted, is any arbitrary
>> behavior by those consenting nodes deemed acceptable by the
>> non-consenting nodes?  Previous discussions seemed to indicate  
>> that at
>> least some folks would answer "no" to this question.
>>
>> In other words, how is using RH 253 between consenting nodes (allowed
>> to behave arbitrarily) any different than allowing consenting  
>> nodes to
>> run RH0, and non-consenting nodes disabling RH0?  One difference
>> (cynical hat on) is that opponents of source routing now force
>> proponents to get new functionality implemented and deployed -  
>> only to
>> have the same debate a few years from now when it comes time to
>> standardize the functionality.
>>
> I think any proposal for special re-forwarding to new destination,
> based on RH0, RHx, or anything else would have to be evaluated
> by its merits. Some of the questions that would be asked in
> review include, for instance, how is consent obtained from
> the participants obtained, and how can the consenting nodes
> ensure that they are not used as part of an attack (e.g.,
> amplification).
>
> Jari

Thanks, Jari.

I was also speaking mostly about the functional aspects of the  
mechanism, not the policy aspect.  I suppose when the IETF publishes  
an RFC (or decides not to deprecate one), it essentially 1. endorses  
the described functionality and 2. implies that potentially negative  
consequences that could arise if the functionality were widely  
deployed have been considered.  Using RH 253 among consenting nodes  
allows the IETF as a body to remain silent on the merits and  
potentially negative consequences of that particular mechanism /  
use.  That is a difference.

Of course, in this case the deprecation of RH0 essentially  
establishes a position on both RH0 and sufficiently similar  
functionality.  It is sort of like case law, with the RH0 deprecation  
draft as the legal opinion.  I think this is partly why folks were so  
interested that the text in the RH0 deprecation draft focus on the  
single issue of most concern (e.g. oscillation DoS), rather than the  
merits of source routing in general.

Is this consistent with your thinking?

Thanks,
Dow

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