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

Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 13 November 2017 16:15 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 4D290120454 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level:
X-Spam-Status: No, score=-4.32 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, URIBL_BLOCKED=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 0rZzT0z2ibTC for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 08:15:50 -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 0DD9E129AF9 for <ipv6@ietf.org>; Mon, 13 Nov 2017 08:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510589748; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=9zkowOVAW8CSFaZLzFclgFF1Gr2eTfjUJAut0Pbx6Ng=; b=C0q+qVcd5nRFvXAhvcXQ0zlInVy1iLH7i3T6B2lTnX6c0rnBBQJeOmRxrbN1wOi/sa6sVkgn+diiPo7vg9xvPT14pOgxp4UDCyn/7kuwmORrCgoU1WUtVbP1/+cLi1NEzrY6eJb/iS08XQ7w1G3GCxBlePW8eWpt3XkgP54rw/I=
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-130-1zgIpZIbO5ObHHSrarCE5Q-1; Mon, 13 Nov 2017 16:15:45 +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_P384) id 15.20.239.4; Mon, 13 Nov 2017 16:15:43 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 16:15:43 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Fernando Gont <fernando@gont.com.ar>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
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/vqPz1IcGUEyBNF2bHgm6GqMHrANIgAAZpoCAAQgTgIAAiLAAgAk33AA=
Date: Mon, 13 Nov 2017 16:15:43 +0000
Message-ID: <7F4258AC-1951-46E5-B0DD-BA5541A2797D@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> <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
In-Reply-To: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
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:e565:a751:53f4:fd9a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:iJsQrnvrvAJAOAyn/gRvznwqjI4O3cDxNN0BfB0/0Ae/BkK0+PWkF06UvzxGTMWI9wTACmaFNvVcnOIxyS+aNA74dBk3UO+EiNgVZcPE8HJ7XNj1pWQbWLq2/ADOKGBcnMVdlu9714yk0/K7XXL79lICCYS0jlqrwvM+XqqRjv4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: bb6e49ab-a646-44a7-7db6-08d52ab1ca5b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139;
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-microsoft-antispam-prvs: <AM3PR07MB1139630BB6844965010A145DD62B0@AM3PR07MB1139.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(100324003535756);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(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: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(25786009)(3660700001)(33656002)(6246003)(6512007)(8676002)(5660300001)(54906003)(93886005)(229853002)(6916009)(42882006)(189998001)(53936002)(305945005)(50986999)(39060400002)(7736002)(6306002)(2950100002)(966005)(2900100001)(72206003)(4326008)(14454004)(101416001)(83716003)(102836003)(68736007)(478600001)(5250100002)(76176999)(81156014)(106356001)(82746002)(105586002)(97736004)(53546010)(81166006)(316002)(3280700002)(86362001)(36756003)(6116002)(786003)(2906002)(57306001)(74482002)(6436002)(6486002)(8936002)(6506006)(50226002)(8656006)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <42A67C320F002B4AA54AAB973062E12D@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: bb6e49ab-a646-44a7-7db6-08d52ab1ca5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 16:15:43.4739 (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: 1zgIpZIbO5ObHHSrarCE5Q-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1fMY9KZNI93fgHbNjrZBtXm9xXs>
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, 13 Nov 2017 16:15:53 -0000

> On 7 Nov 2017, at 19:29, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
> 
> On 08/11/2017 00:20, Tim Chown wrote:
>> Hi,
>> 
>>> On 6 Nov 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
>>> 
>>> Hi Fernando,
>>> 
>>> On 07/11/2017 07:02, Fernando Gont wrote:
>>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
>>>>> On 03/11/2017 04:26, C. M. Heard wrote:
>>>>>> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca>; wrote:
>>>>>> 
>>>>>>> 
>>>>>>> C. M. Heard <heard@pobox.com>; wrote:
>>>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>>>>>>> Yet we skip other extension headers in order to find the ULP.
>>>>>>> 
>>>>>>>> Not so. An end node that encounters an unrecognized extension header
>>>>>>> is
>>>>>>> 
>>>>>>> Both AH and IPIP are well known and recognized extension headers.
>>>>> 
>>>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
>>>>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
>>>>> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
>>>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
>>>> 
>>>> Based on the std, anything that is unknown is an EH. In the context of
>>>> RFC8200/FC2460, there's only:
>>>> 
>>>> * Known EHs
>>>> * Known ULP
>>>> * Unknown EHs
>>> 
>>> Yes, that's what the text says but I wish we'd fixed it in 8200 to
>>> acknowledge that there is a 4th case (Unknown ULP) and that it
>>> cannot be distinguished from the 3rd case. Acknowledging that is
>>> much better than ignoring it. I'm happy with Ole's suggestion that
>>> this (and the resulting ICMP 1 behaviour) should be mentioned in
>>> 6434bis - as a clarification, not a new invention.
>> 
>> This seems a reasonable approach to me.  Would you like to propose text, Brian?
> 
> After this:
> 
> 5.1.  Internet Protocol Version 6 - RFC 8200
> 
>   The Internet Protocol Version 6 is specified in [RFC8200].  This
>   specification MUST be supported.
> 
>   Any unrecognized extension headers or options MUST be processed as
>   described in RFC 8200.
> 
> insert something like:
> 
>   Note that it is impossible for a node to distinguish between an
>   unrecognized extension header and an unrecognized upper layer
>   protocol. Therefore, a node will behave in the same way for
>   either of these cases, in particular by returning an ICMP
>   Parameter Problem message with code 1 ("unrecognized Next Header
>   type encountered") even for an unrecognized upper layer protocol.

This is the text TimW will present in 6man; it seems fine to me, and hopefully we’ll have consensus.

Tim

> (Protocol 41 is not special in this regard.)
> 
> - Brian
> 
>> 
>>> I also agree that there are enough potential issues in unexpected
>>> IPv6-in-IPv6 that is deserves its own draft.
>> 
>> I’d agree. The same with header insertion for that matter. Focus on the issues and how/if they can be mitigated and in which contexts.
>> 
>> Tim
>> 
>>> 
>>> Regards
>>>  Brian
>>> 
>>>> with the last one being the default branch :-)
>>>> 
>>>> 
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------