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

Tim Chown <> Mon, 06 November 2017 11:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB62013FB5C for <>; Mon, 6 Nov 2017 03:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZJtutjFW3JUA for <>; Mon, 6 Nov 2017 03:36:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8694013FB31 for <>; Mon, 6 Nov 2017 03:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( []) (Using TLS) by with ESMTP id uk-mta-2-3Ek6SkGrNdqy_2c0crDGmg-1; Mon, 06 Nov 2017 11:36:35 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Mon, 6 Nov 2017 11:36:34 +0000
Received: from ([fe80::f008:dc81:4b84:fd23]) by ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 11:36:34 +0000
From: Tim Chown <>
To: Ole Troan <>
CC: Michael Richardson <>, "C. M. Heard" <>, 6man WG <>
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: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
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: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Nov 2017 11:36:52 -0000

> On 6 Nov 2017, at 11:10, Ole Troan <> 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.