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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 07 November 2017 19:29 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 4A266126BF3 for <ipv6@ietfa.amsl.com>; Tue, 7 Nov 2017 11:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4eYn97PCczEl for <ipv6@ietfa.amsl.com>; Tue, 7 Nov 2017 11:29:28 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F102E12421A for <ipv6@ietf.org>; Tue, 7 Nov 2017 11:29:27 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id t188so208621pfd.10 for <ipv6@ietf.org>; Tue, 07 Nov 2017 11:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=163KGNepeKjtsVyT+cJJt/KwOG1C6FFdiwYN5VkVvVY=; b=b73yebo2B6WMy+43Brswc8VFE7XupAOMAAeD5Oyo/godOGL9tL05tMisdqbW5rOQAI LsW1afFnI6xNbAMywERGSMQ99WG0UDko/ecr+vrMoslFQwt8QfTvK29iRl17Yg1k+w8/ eW9qGECFBITd69IksDWibMIcLTwSqG2G5i2S+VF0S5GpBtKTNuV4kazTzXAfauJ71wTB TUnUe7rRvU0ywQHWrvC6OVjhZZEtC58baaI+7QKrHLe2HrtolrjB2Ugm0vRZ8v4xkDtV 617SYmBsbW+ug9k7yDT9O7nl5tk8EzEXnZ3Ueid7TlVDjwGfpoL0TtrLUWSiNxYLYhuo 94Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=163KGNepeKjtsVyT+cJJt/KwOG1C6FFdiwYN5VkVvVY=; b=s85fCzH+zIFAdRpZx7b0Agd9g7rKAwg/UcNK1oyyixS5GN53m3jYs3KV6XCHDUu7Pc 1YafN+SCxD/sW1wsbJ1ulxhHRndIVizxEIpY34flCjp3OdUWlH+XPaykrLYnlSAb0AlS 2CT6UhpbjKxib0cLjsbGxARujIxDHCcz9FfdN5k74cNWsc++5C1LX05H81mijNLaWp4b H2rz7+c5zGFFf3QxB28Bm6aZH3U69vcVyMfYtrbZgvXLRBHtviFf1znZC9IBtb1WNpa4 oZ69OJ4SXFSEaMxbvC5YxUzMpTi5uxiHXI0u0ZqQVxLO+y5BtynCcsKYg2i7n4Dm4Vaw SFdQ==
X-Gm-Message-State: AMCzsaXKVzSKi320XCoSxPAbYvxp3CUgV8ELOSGTIiWyok6BWk1na4yx x/h73q5Q4lINiddRyZAJLnqpBA==
X-Google-Smtp-Source: ABhQp+ROTTJGkfgNZF27T/u1ekvo2gHcF0KScYAXVDAycQyAuo5kAJH1cbZUAA5UezJfnSV3yoIvww==
X-Received: by 10.84.245.145 with SMTP id j17mr18676781pll.163.1510082967497; Tue, 07 Nov 2017 11:29:27 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s3sm4718582pfk.7.2017.11.07.11.29.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 11:29:26 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: Fernando Gont <fernando@gont.com.ar>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
Date: Wed, 8 Nov 2017 08:29:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lbWXg7z-mnlPSPmhsFIfaczAuRk>
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: Tue, 07 Nov 2017 19:29:30 -0000

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.

(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
>> --------------------------------------------------------------------
>>
>