IETF Logo Mail Archive

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

joel jaeggli <joelja@bogus.com> Tue, 05 April 2016 13:01 UTC

Return-Path: <joelja@bogus.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 6F3FD12D5D6 for <v6ops@ietfa.amsl.com>; Tue, 5 Apr 2016 06:01:30 -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 wapmd0nnPtDH for <v6ops@ietfa.amsl.com>; Tue, 5 Apr 2016 06:01:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0597012D681 for <v6ops@ietf.org>; Tue, 5 Apr 2016 06:01:26 -0700 (PDT)
Received: from dhcp-b257.meeting.ietf.org ([IPv6:2001:67c:370:176:a1e9:33d0:3819:48]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u35D1J6E093568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Apr 2016 13:01:21 GMT (envelope-from joelja@bogus.com)
To: otroan@employees.org, 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> <E2C0BF9F-806C-4ACC-86CE-1B678628E687@employees.org> <CAO42Z2z2R9N4b1Y=zQCuw2niwYzaRtten+8mDHpsjfYXSh8pJQ@mail.gmail.com> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com>
Date: Tue, 05 Apr 2016 10:01:18 -0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="2kDiRkpPm2wgqDt802qCKVhcGH04T1qcn"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/yamLS5EOPWp1Huitqi-a4coKbgA>
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, 05 Apr 2016 13:01:30 -0000

On 3/29/16 6:51 AM, otroan@employees.org 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.
>>>> 
>>>> I appreciate that not everyone agrees, though.
>>> 
>>> It does break PMTUD though.
>>> 
>> 
>> Which I think is because of an expectation that the device
>> identified in the packet source address (the "sender") is
>> responsible for creating the whole packet. It can't be a "unicast
>> source address" field if there are multiple sources of the
>> information in the packet.
>> 
>> It also breaks troubleshooting methods and assumptions about the
>> source address field that have been true for IPv6, IPv4 and many,
>> if not all, past layer 3 protocols.
>> 
>> One perspective on tunneling is that when it modifies the packet,
>> it adds another source address field to record that another device,
>> other than the original packet source device, has made additions to
>> the packet.

Encapsulation does not alter the wrapped packet, except perhaps by
decreasing the ttl.

> indeed, and is why 2460 bis states: "Extension headers must never be
> inserted by any node other than the source of the packet.  IP
> Encapsulation must be used to meet any requirement for inserting
> headers, for example, as defined in [RFC2473]."
> 
> cheers, Ole
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email