IETF Logo Mail Archive

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

Mark Smith <markzzzsmith@gmail.com> Tue, 29 March 2016 02:25 UTC

Return-Path: <markzzzsmith@gmail.com>
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 B102F12D1EA for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 19:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FuqpCdJPFShp for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 19:25:18 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 A247D12D0B3 for <v6ops@ietf.org>; Mon, 28 Mar 2016 19:25:18 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id e6so2887878vkh.2 for <v6ops@ietf.org>; Mon, 28 Mar 2016 19:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GadUTZnSfiE74pFpEatoNjia2B4sySXuqvLHTQBtDXk=; b=Jql0kRSBOyMb2XTotRo2NIxjMrXo9vlsrXMVQAjx1AKEUufgEHTuQ/QS5eDVvUoniD mWDsow096igiRLdsy1oZYLKjQZb0nfu3AF8ooUN9TDun1iHhjmu9wlCS2BqU9E5Q0sEK waLowJIWssaG4ZL7tBLZr+nyLz2FZxo7Ivr1wAS9o/AjPFtLzb2QSkQ8IQCYnWaDZbs/ DxsarEMVQVV7HxKwft5HwBJV11DUt5angamyHpkOz8YNwOM3VGF4ItOBxUqaRHZSq7yL shKoaH2MK9CjHa/KxVs2CYdXm6NwXD0A71/+P7G9D3Sq6lZDkI2eB5JRYSDqbTCyHib7 0Taw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GadUTZnSfiE74pFpEatoNjia2B4sySXuqvLHTQBtDXk=; b=gxSBsAxZphArD/8+qxWtxQbpAqubUjBdMUS8HbW87AlPF4XXOoYMxiz7+6VsiSmxFp kpIG4suqPlnqih9l13hfnUdbQad+8GmOff2cHA7JwcD8NSycCuDQD10sYgkOm2vcET8o 0DnLAtyyQBPpPdcDwLxeJaNGJaqkSx172KLG9vc4exOk7vczxZfstNIdXtpQ2+Gwfzka 3ZGkaB+G3fQIdYiYsH6anQNs3nL+zhy0EL1OofTE7v6Stzp6Poqqh9dooqXAKIwSvdP8 gk3s6dXWBWOuYog1stw/ayV91A/0PR6O0jjRS/s3sX/ikWZ99uhLDOxdnyGi2wAmZyi4 B5BA==
X-Gm-Message-State: AD7BkJKpZ6NwBJCcr6Np939CuzQWYHd/3cyxpsBbt25FgS9maQWTiwjXRE3KVW2FulL6bS/ceB5kHqJmUJ1jUw==
MIME-Version: 1.0
X-Received: by 10.159.37.146 with SMTP id 18mr2954297uaf.140.1459218317695; Mon, 28 Mar 2016 19:25:17 -0700 (PDT)
Received: by 10.159.32.228 with HTTP; Mon, 28 Mar 2016 19:25:17 -0700 (PDT)
Received: by 10.159.32.228 with HTTP; Mon, 28 Mar 2016 19:25:17 -0700 (PDT)
In-Reply-To: <56F9C915.9070408@isi.edu>
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>
Date: Tue, 29 Mar 2016 13:25:17 +1100
Message-ID: <CAO42Z2w-MBtzGo16bqk_OfTvGH-EV6rGQBu8aQ3abDbOquCcLQ@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="001a113e163e79e0be052f26bd33"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/IW3GAEXlyQONsp2sdGDVng__dx0>
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 02:25:20 -0000

On 29 Mar 2016 11:15 AM, "Joe Touch" <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, but it isn't possible to know that
some was deleted on the way.

Adding/updating is far more ambiguous. 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.

RH0 allowed updating in the network, however it preserved and carried the
list of devices that updated the destination address.

> I appreciate that not everyone agrees, though.
>

I wouldn't want to be troubleshooting those sorts of packets if I don't
know and can't be sure if the source address of the packet is the creator
of all of its contents.

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.

Regards,
Mark.

> Joe
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email