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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 03 November 2017 01:44 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 15D5D13FB10 for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 18:44:27 -0700 (PDT)
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 1OvjldU6DYfG for <ipv6@ietfa.amsl.com>; Thu, 2 Nov 2017 18:44:25 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 7971313FB0F for <ipv6@ietf.org>; Thu, 2 Nov 2017 18:44:25 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id n89so1048660pfk.11 for <ipv6@ietf.org>; Thu, 02 Nov 2017 18:44:25 -0700 (PDT)
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=W6BVvf4ttR6OmFD9gP9Mzt43lAuJ3Da1LnRAuEx+LaQ=; b=ZV8FnFw+U1e9snOcqPPM9ezkpBqdlYpDWyVHf03c6Rtp4reaCY4UF4yiNokdCgo7uM ams87zknGmdls46IMvyH/nPNgGpnqS7WhLJUfVM+Ouc31XpBqBqSb7TNTdnYOz83I029 QVlp2MNGAiHv5xKSMMUcNFaE1Qi0jAV42jOuSkekJi6ikoR+JOOAFFWHKlw0t9z733sZ WgpS8FlSupCZw7a66fPg/SPy5oSIPeZLh3ZqR2IZgBvkdbHJj6oBXECJj7EFn94oKwqa lnAAwxmBIz4xUKAjnSPCqXjsaIsp/QCSDw2QOtIjbupm4pVBF6Cc1m3mb3LxhgS1Pox0 1avA==
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=W6BVvf4ttR6OmFD9gP9Mzt43lAuJ3Da1LnRAuEx+LaQ=; b=cGJbk+330ytU1nE3W8/4Y8owBkDBEPGXsqxKeLHy+h4Q7R9YmYGQawZntpXTF91iej WoYnAlYPMsXp+qEwdmYfyYz8hYGoDtkvtgL0kD7Jb5smlRB0tnWMYByuyuXF9YGT8rDZ U0c8sBuGV1e+es9lCy66tv13d6DUPmn+Bc1sWt+LllaBbelrvakovet3IEedqPGnsUWb H5BBgN1rhXJS00nzCB+Qk8HF6EKjSn8GOIXWjE+ZzuYQXqPhK+b4lP3F4dZxIBVqR0AF cG5zL7eia/CV/UGEv/o1bQKzYkZldmel6+fK5K9r4c8+8GVBGU9QarEt2iRcFwV1mBHI MEYg==
X-Gm-Message-State: AMCzsaWNCTrsxLqlYvECDpeCJGcH26rjGQDbFrnEQV6uFXizlLvlWZAd MfJBGXw6n1wjteyLG0QtQfE=
X-Google-Smtp-Source: ABhQp+SRhUvLK1cbHACadnrqsp93BROpS2beHSSqB7W8sEggNEJFkALTZn0Oe8ITDC8peXMzj+0mTA==
X-Received: by 10.99.103.5 with SMTP id b5mr5554427pgc.447.1509673464944; Thu, 02 Nov 2017 18:44:24 -0700 (PDT)
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 t2sm8444796pfk.90.2017.11.02.18.44.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 18:44:24 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "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> <CACL_3VEjp2bJAAGgqaKcqdqHoitE6vw6M3=qO6YauVoKN-26=A@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <f7feace2-86d2-a2f0-5662-469405aa32e8@gmail.com>
Date: Fri, 3 Nov 2017 14:44:29 +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: <CACL_3VEjp2bJAAGgqaKcqdqHoitE6vw6M3=qO6YauVoKN-26=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0ueMjkPh8V5zqGBBM0H5MduUiwo>
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: Fri, 03 Nov 2017 01:44:27 -0000

On 03/11/2017 10:30, C. M. Heard wrote:
> On Thu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> 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.
>>
> 
> Actually, it does, and the disposition is exactly the same as for an
> unrecognzed
> extension header. Both come under the heading of ICMP Code 1 ("unrecognized
> Next Header type encountered").  See the second paragraph on page 9. Indeed,
> it could hardly be done any other way, since it's not possible for a node
> to tell
> whether an unrecognized Next Header type represents an extension header
> or an upper-layer header.

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.

   Brian