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

"C. M. Heard" <> Thu, 02 November 2017 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB52013F722 for <>; Wed, 1 Nov 2017 19:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Status: No, score=-2.201 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w9iRR68MVr20 for <>; Wed, 1 Nov 2017 19:32:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C35E013F600 for <>; Wed, 1 Nov 2017 19:32:17 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 8B84AABAD0 for <>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=gYM h41TQPf+1vqfR4+EHhwJLynQ=; b=gmpDXG6hHp/ESYP2YBhVA1n8HHXIxy6wWPj 3Q9u0mYeLax+iRajb3bybUi47JUqeeQtNwH0BkT4o92jk8DJUESzQWY9F4C1QRBc xOv3mXTXT7jKLyDWjcj/TBzsjQe6Dgz5dQn+ufUJm8eVydTtzJFGCFV416G9eWfV 3s5/YUJ4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= R2qscUl8PW4qHFFDnWeG9pdimEd5uzeBLqUbVlSmQArXke/AWKDrQ5LxMKMbyaUy rvIVUqm48Fz04xIuTM1CJeQEJ2bSNJ79/l1QipFNGFiK+2B+Lk4/y6EfTcNsQscz JowPAiOaOHnT2J7LW2ayNQiFCHHGi7XzBHtmscbgWcY=
Received: from (unknown []) by (Postfix) with ESMTP id 84899ABACF for <>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 25053ABACE for <>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
Received: by with SMTP id m189so5086278qke.4 for <>; Wed, 01 Nov 2017 19:32:16 -0700 (PDT)
X-Gm-Message-State: AMCzsaX7ZlwJf50kHi52zER9W6CbgXl9T226yrbxP3bKVV8kdHcaJQcW ox+T4XCdb1QAf+86mCEA9z2c0N2s2SYDauiK8uE=
X-Google-Smtp-Source: ABhQp+R7ifgyQcUpbcCTotha1LSNQdjEgPOuALX4H3tFW/uqkowv+nwR8V4hvqQ8+ne1jcQ/FUnBK2dWZOwD1mUc7Oc=
X-Received: by with SMTP id t15mr2738329qke.232.1509589935726; Wed, 01 Nov 2017 19:32:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 1 Nov 2017 19:31:55 -0700 (PDT)
From: "C. M. Heard" <>
Date: Wed, 1 Nov 2017 19:31:55 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: 6man WG <>
Cc: Michael Richardson <>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 0A851492-BF76-11E7-AC36-8EF31968708C-06080547!
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: Thu, 02 Nov 2017 02:32:19 -0000

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
not supposed to skip the unrecognized extension header; it is supposed
to discard the packet. See Section 4 of RFC 8200:

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.

Substantially the same language appears in Section 4 of RFC 2460.

It is, in fact, impossible to reliably tell the difference between an unknown
extension header and an unknown upper layer protocol because they are drawn
from the same numbering space. That fact has been discussed here on more than
one occasion.

> In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
> header....  Because we got this wrong, we couldn't use AH to secure ND or any
> other multicast (like OSPF) without causing of a flag day.  AH became totally
> USELESS.  It was sad.

There may be problems with AH, but that is not one of them.

Mike Heard