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

Brian E Carpenter <> Fri, 03 November 2017 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15D5D13FB10 for <>; Thu, 2 Nov 2017 18:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OvjldU6DYfG for <>; Thu, 2 Nov 2017 18:44:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7971313FB0F for <>; Thu, 2 Nov 2017 18:44:25 -0700 (PDT)
Received: by with SMTP id n89so1048660pfk.11 for <>; Thu, 02 Nov 2017 18:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id t2sm8444796pfk.90.2017. (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" <>, 6man WG <>
Cc: Michael Richardson <>
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <
>> wrote:
>> On 03/11/2017 04:26, C. M. Heard wrote:
>>> On Thu, Nov 2, 2017, Michael Richardson <> wrote:
>>>> C. M. Heard <> 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.