IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 06 November 2017 19:35 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 BAF6013FB5D for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 11:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 PzYDIQeUf1BJ for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 11:35:06 -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 A861E13FBCC for <ipv6@ietf.org>; Mon, 6 Nov 2017 11:35:06 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id b85so8450620pfj.13 for <ipv6@ietf.org>; Mon, 06 Nov 2017 11:35:06 -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=GiJCYkUUeifDgiay1XblL8MQKalB/ptBkfK5UacRPVU=; b=fqZhYsqIMGUvdsQz5Ocbe6YDnFDGxt81D3oibR6NzDvmwB0GvRE+Z3ukaInHvIeuvG tSqTI+vBqgZcS5zqTMNiQIad4blmQeb2LW8jem999mcLZqJguh2ov1s2LdAvAGWplVst VdEhMMHCZLG9yiSQDo+pp6I3pxd2cwYOm+KSvMWoFGw9y0Lnzs/aB1GDxGXOFOKdMgA0 Uz0cT/BIl7WXVyGsnUtx7ww0W6ZHhvZGYOhUoLp7Ww4SFqwE/B5aKcKdpuA19cPnTzIC 8JCmTEf76kKr/oRVwfvq8g9uAwYnDZnxNJzKtUb9SWL4tt2gWRo1rjupQmqfjKsaUg6a loUA==
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=GiJCYkUUeifDgiay1XblL8MQKalB/ptBkfK5UacRPVU=; b=HUpjND+6h/1NaoINZfrcslvR+hXIWAUj1ngAmumtwTdotGIkRxK4Y6pvN3Fr2Zu0yH 2IfcXZDWbqiY21tLflgl86lpTtk+8ewe1iW63X8Sqf1YKqSd7I4WqcswIgMBuopOJ1N5 Czqz4VCvIbIva8dqsGjrdOb7h9k+ynBDjMg252wzrJ6Fv9G7F/wXPxOeRFhApVLq6kHG vhTINaMoCl2BdRLSei56GRX8AX0oxVtaJb6yI3SPyDLApYGbbGCfEDj7DPaTeREFaHSe nLf+wjrI8VjGugPL6tYVLo4NOovwMQ8dIHuJsWPacuuDwnfPBku6Ge8flOh/jGFX6pvq OLWQ==
X-Gm-Message-State: AMCzsaXOkf6i2k94IRoxib8WoTJLUsMhayMlLF7Wkc6OiwZ8V77a643Q 98E/hLH9CVuglPBLGd2OZmU=
X-Google-Smtp-Source: ABhQp+QPmH43Uj8d+nDPJdECzdIXh8QPtlJ3dmc4clDiVBq0ICRhojBPjr5UUOLzEr3+hjVFpKh4iw==
X-Received: by 10.101.64.11 with SMTP id f11mr16279916pgp.217.1509996906083; Mon, 06 Nov 2017 11:35:06 -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 g11sm25313645pfe.41.2017.11.06.11.35.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 11:35:05 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Fernando Gont <fernando@gont.com.ar>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>
Cc: 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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
Date: Tue, 07 Nov 2017 08:35:03 +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: <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2PJwMDHtLEIwTqjSZ5uL47c--NY>
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 19:35:10 -0000

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.

I also agree that there are enough potential issues in unexpected
IPv6-in-IPv6 that is deserves its own draft.

Regards
   Brian
 
> with the last one being the default branch :-)
> 
>

v2.23.0 | Report a Bug | By Email