IETF Logo Mail Archive

Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

Joe Touch <touch@isi.edu> Tue, 29 March 2016 03:00 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D1C12D095 for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 20:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcagKCfUtaZe for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 20:00:00 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9750D12D099 for <v6ops@ietf.org>; Mon, 28 Mar 2016 20:00:00 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u2T2xMxt014841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 19:59:24 -0700 (PDT)
To: Mark Smith <markzzzsmith@gmail.com>
References: <CAHw9_iLbqEvsw0x4dDcA3Zy3SXKUROcQuy5nSynsL9Xi+xrZLg@mail.gmail.com> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <CALx6S37zP4UvCtBJsvnPN6OmDB0OQDMfRrJNy1XF0t4COStUjQ@mail.gmail.com> <56E98086.5040209@foobar.org> <EE17974D-EDA4-4732-B29E-B2B3BC36DB86@employees.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <CAO42Z2w-MBtzGo16bqk_OfTvGH-EV6rGQBu8aQ3abDbOquCcLQ@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <56F9EF8A.6090903@isi.edu>
Date: Mon, 28 Mar 2016 19:59:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAO42Z2w-MBtzGo16bqk_OfTvGH-EV6rGQBu8aQ3abDbOquCcLQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/UXLU7335rYB73IX1g1S6D8sNn4c>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2016 03:00:02 -0000


On 3/28/2016 7:25 PM, Mark Smith wrote:
> 
> On 29 Mar 2016 11:15 AM, "Joe Touch" <touch@isi.edu
> <mailto:touch@isi.edu>> wrote:
>>
>>
>>
>> On 3/28/2016 5:12 PM, Brian E Carpenter wrote:
>> > Yes. It's a bug in RFC2460 that this ambiguity arises.
>>
>> I took it as a feature. IMO, the idea of a chain enables this feature,
>> and I don't think it should be so quickly dismissed as potentially useful.
>>
> 
> So I think the question to ask about such a packets is what does the
> source address now mean when it arrives?
> 
> Deleting information from the packet means the source address is
> responsible for all the field values,

That's provably not true, as per the RFC I cited previously.

> but it isn't possible to know that some was deleted on the way.
> 
> Adding/updating is far more ambiguous.

Route headers are updated too.

> The source address really just
> now means that the specified device decided to send a packet and that is
> it. There is no way to tell what was in the original packet - everything
> else could have been added or replaced along the way.

If that matters, it's up to the other layers to decide. That's partly
why TCP and UDP include a subset of the IP header values in their
checksum, but also why they do not include the entirety of the IP header
including options.

...
> I think tunneling is the correct approach for "modifying" packets in the
> network, because it completely preserves the semantics of the inner
> packet's fields.

Encapsulation does that too, when honored as it is defined.

Joe

v2.23.0 | Report a Bug | By Email