Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 06 November 2017 11:36 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62013FB5C for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 03:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 ZJtutjFW3JUA for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 03:36:49 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8694013FB31 for <ipv6@ietf.org>; Mon, 6 Nov 2017 03:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509968207; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=QFWVd7EtrRAhmzZOe53PX0L0i7F3XiDzNddxc5hrFpU=; b=Clmolqbc2xFdu1ZKBaesvVza2vGAyvxyktu0cs+tp5dx+A5HjJ365uUD6CuBmlYJH4O+3MJaEgU4xfqy4oBAdhfX5JSO5aj8dyqgEnErV+5xd4zvHWTDhwoxg3X7yIYFC/AOqmLESAE5x5oKerraif+Yni8TlVPgpqRffi5iqLY=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0119.outbound.protection.outlook.com [213.199.154.119]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-2-3Ek6SkGrNdqy_2c0crDGmg-1; Mon, 06 Nov 2017 11:36:35 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Mon, 6 Nov 2017 11:36:34 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 11:36:34 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Ole Troan <otroan@employees.org>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTU4K/vqPz1IcGUEyBNF2bHgm6GqMFBj08gAInMQCAAAtdAIAABy2A
Date: Mon, 6 Nov 2017 11:36:34 +0000
Message-ID: <602A126A-86C5-4F8C-AFED-B3A2BCE12BB8@jisc.ac.uk>
References: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com> <23308.1509623865@obiwan.sandelman.ca> <CACL_3VFrcombGczXU6Zz=Pk1u2GE=wGG-r+yEefdHai1REqXmQ@mail.gmail.com> <c8911f45-2afc-9d26-c0a8-1017d034a251@gmail.com> <CACL_3VEjp2bJAAGgqaKcqdqHoitE6vw6M3=qO6YauVoKN-26=A@mail.gmail.com> <f7feace2-86d2-a2f0-5662-469405aa32e8@gmail.com> <7923.1509845822@obiwan.sandelman.ca> <B232868B-8DE5-4F54-87E7-A16974AB9658@jisc.ac.uk> <F72E6924-8442-4FF9-A474-2FF3726CFA69@employees.org>
In-Reply-To: <F72E6924-8442-4FF9-A474-2FF3726CFA69@employees.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 20:0IZgs/DGg2zekjngyUGK5uDtHEk4siqhau7BjoGwbNRpS5HRXEq/6rDjed+QfB4/yAEiorQ/oa/2v6/jx870na/vaTVSN5ajftIk1Uz4b4obJsAnUp+He79vfMGh49NHZC4jK0jDYXQoLvR7U0ctK3fVUkY70/bpxAltRNFahrc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dff81674-fc15-4361-8c64-08d5250aa24a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:AM3PR07MB1138;
x-ms-traffictypediagnostic: AM3PR07MB1138:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <AM3PR07MB1138E076A2B05085BFBB60FCD6500@AM3PR07MB1138.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231021)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138;
x-forefront-prvs: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(24454002)(189002)(8656006)(82746002)(2900100001)(33656002)(7736002)(6916009)(5660300001)(229853002)(8936002)(316002)(189998001)(3280700002)(3660700001)(786003)(54906003)(53546010)(36756003)(93886005)(14454004)(305945005)(4326008)(2906002)(42882006)(2950100002)(74482002)(99286004)(97736004)(53936002)(25786009)(3846002)(102836003)(6116002)(72206003)(478600001)(6512007)(50226002)(101416001)(86362001)(106356001)(76176999)(105586002)(81156014)(8676002)(57306001)(6486002)(6436002)(81166006)(68736007)(50986999)(6246003)(66066001)(83716003)(5250100002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <0617009EED5C214C954A333009D26DFF@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: dff81674-fc15-4361-8c64-08d5250aa24a
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 11:36:34.4707 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: 3Ek6SkGrNdqy_2c0crDGmg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/N9eZhH7Hs5MWWllS1YYh5uSms6Q>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 11:36:52 -0000

> On 6 Nov 2017, at 11:10, Ole Troan <otroan@employees.org>; wrote:
> 
> Tim,
> 
>>>> Yes, that particular elephant stands politely and quietly in the corner
>>>> of the room. However, I'd just read the text you cite when I wrote my
>>>> message and I'll stick to what I said: we *specify* action for an
>>>> unrecognized extension header, but we ignore the elephant and *don't*
>>>> specify action for an unrecognized ULP. Consider it a drafting error,
>>>> or a design error. I agree with you about the practical effect: an
>>>> unexpected IPIP packet is likely to generate ICMP 1 today.
>>> 
>>> okay, so shouldn't 6463 fix this part at least?
>> 
>> The question is whether we add such “gaps” to 6434-bis, or spin up a new draft to update 8200, which might then be reflected in a future Node Reqs update.
>> I’m easy either way as an author of the doc, but would err towards minimising adding new material to 6434-bis, and trying where possible to just point to existing documents.
>> 
>> Some input from the chairs would be welcome.
> 
> If we are talking about the action for unrecognised next headers, I do not see a gap in existing specifications.
> If one want to engage in the sport of extreme hair splitting, I wouldn't mind if 6434bis were to add some a descriptive paragraph of "unrecognized next header including ULP are discarded as specified in 8200...".
> 
> If we are talking about the issue of IP in IP encapsulated packets sent to a unsuspecting host, that in my opinion requires a new document.

Thanks Ole.

Tim