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

Tim Chown <Tim.Chown@jisc.ac.uk> Thu, 02 November 2017 11:23 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 62B5C13F6F1 for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 04:23:39 -0700 (PDT)
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_H3=-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 Ftj0SAKwZYUW for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 04:23:37 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.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 464A213F6C9 for <ipv6@ietf.org>; Thu, 2 Nov 2017 04:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509621815; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=9tfnZPbg9ByZy+TraMMETTpUXu0l6KzggXe4b29sYPk=; b=Cp9aHF0Vq+LXgcnas8NFzVqZdNtfvy2iquCIXW6x5MdljjQoEwFl7hzGvxlNtRr3oh1GJLdieJ1wmrxQBvluSCT65gms187AyNBsEgSai+Fwf0Oa7VPGzmNWiPdsuvVpltml4rBPFTfjqbvu6ygvY93UhvfAUSwziBgZJgBJkjI=
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0053.outbound.protection.outlook.com [213.199.154.53]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-67-QZcToU2-MWikA5BjBIBQlg-1; Thu, 02 Nov 2017 11:23:31 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Thu, 2 Nov 2017 11:23:29 +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.004; Thu, 2 Nov 2017 11:23:29 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Mark Smith <markzzzsmith@gmail.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: AQHTUduNvqPz1IcGUEyBNF2bHgm6GqL9Jb0AgAAEQQCAAHcwgIAAsL+AgABsDACAATtKAIAA/QgA
Date: Thu, 02 Nov 2017 11:23:29 +0000
Message-ID: <460D9142-43AE-4B5F-AABA-4E3E8B322AB4@jisc.ac.uk>
References: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com> <6286.1509408085@obiwan.sandelman.ca> <f9447eb6-fca1-e54c-ff0b-abafa5986960@gmail.com> <25055.1509413008@obiwan.sandelman.ca> <B5488438-0F4B-4362-9B34-6B6FB74D5A49@employees.org> <19111.1509476559@obiwan.sandelman.ca> <CAO42Z2xhwkT03TgaJBYwFmKAYB0F87-1yd+wvk3NJAfzwY7ZiQ@mail.gmail.com> <17463.1509567470@obiwan.sandelman.ca>
In-Reply-To: <17463.1509567470@obiwan.sandelman.ca>
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: [2001:a88:d510:1101:347c:9966:7017:389f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:H6Q+4nNjy8S/j04ajMGxvsj3FlCc83rE1rhMy07fHem7k6brqnvN/xINoBp9bmNnVzCQ/2eJOPUYfdRFE1phRPpWIQjMyeWtPMupm9vWGE4paWeiZ2FQXAa1vw9vN/QR9fkWdpl5mwXNNNrcOV3sa91uP78jucsmC88Js84I9fU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 1b026109-8440-4193-7e9d-08d521e424db
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139;
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <AM3PR07MB113969BCB84F4CADD6A74EE7D65C0@AM3PR07MB1139.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)(3231020)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139;
x-forefront-prvs: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(189002)(199003)(101416001)(3660700001)(189998001)(53546010)(2900100001)(14454004)(6246003)(74482002)(39060400002)(3280700002)(50986999)(76176999)(2906002)(53936002)(5250100002)(6436002)(106356001)(99286004)(97736004)(6506006)(33656002)(6512007)(105586002)(2950100002)(5660300001)(42882006)(82746002)(229853002)(68736007)(81166006)(478600001)(81156014)(72206003)(8676002)(50226002)(83716003)(57306001)(102836003)(7736002)(6116002)(25786009)(305945005)(316002)(786003)(93886005)(8936002)(36756003)(4326008)(54906003)(86362001)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <5D4B73B3292B7D4D94C09B2A8296108B@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b026109-8440-4193-7e9d-08d521e424db
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 11:23:29.6792 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: QZcToU2-MWikA5BjBIBQlg-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4ZVyaaEtKymq0p_Y2RU7FGEPJGs>
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: Thu, 02 Nov 2017 11:23:39 -0000

Hi Michael,

> On 1 Nov 2017, at 20:17, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Mark Smith <markzzzsmith@gmail.com> wrote:
>> I think we need to be clear about what is "inserting" is. To me, the word
>> "inserting" means inserting to into something that already exists and has
>> previously been created - cut apart, insert, glue back together.
> 
> You can mince words here if you like, I don't mind.
> 
> If someone wants to add a packet by encapsulating with a new IP header, then
> they have to pick a destination address for that header, and if they keep the
> same destination as the inner one, then the end host has to process two headers.
> 
> So, if one wants to make the advice of 8200 useable in practice, then one
> has to fix 6463.
> 
> If one argues that this will hard and shouldn't be done, then 8200 must be
> wrong in some way.

So the 6man chairs were quite keen that we try to push 6434-bis to a conclusion in Singapore, which is a goal the authors are very happy to share.

Obviously, reopening this issue may prove to be contentious.  The simplest and easiest answer is to punt it to a separate draft, and wrap up 6434-bis. I *think* the only other contentious issue that’s still open for the -bis is what we choose to say, or not say, about RAs vs DHCPv6.  In my view, wherever possible we should be just including pointers to existing text in other RFCs, and minimising any additional interpretation.

Having said that, why don’t you try to write some succinct text in advance of the Singapore 6man slot, post it, and see what the reaction is?  Worst case, you’ll then have the basis for a separate draft.

Tim