Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
"C. M. Heard" <heard@pobox.com> Thu, 02 November 2017 02:32 UTC
Return-Path: <heard@pobox.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 EB52013F722 for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 19:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 w9iRR68MVr20 for <ipv6@ietfa.amsl.com>; Wed, 1 Nov 2017 19:32:17 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35E013F600 for <ipv6@ietf.org>; Wed, 1 Nov 2017 19:32:17 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8B84AABAD0 for <ipv6@ietf.org>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; 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; d=pobox.com; 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 pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 84899ABACF for <ipv6@ietf.org>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
Received: from mail-qk0-f182.google.com (unknown [209.85.220.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 25053ABACE for <ipv6@ietf.org>; Wed, 1 Nov 2017 22:32:16 -0400 (EDT)
Received: by mail-qk0-f182.google.com with SMTP id m189so5086278qke.4 for <ipv6@ietf.org>; 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 10.55.170.15 with SMTP id t15mr2738329qke.232.1509589935726; Wed, 01 Nov 2017 19:32:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.38.241 with HTTP; Wed, 1 Nov 2017 19:31:55 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
Date: Wed, 01 Nov 2017 19:31:55 -0700
X-Gmail-Original-Message-ID: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com>
Message-ID: <CACL_3VETxNVQ+YD5j6ZiWjycQ=ojAuWwB23offNdVKm+S9c_7A@mail.gmail.com>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: 6man WG <ipv6@ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 0A851492-BF76-11E7-AC36-8EF31968708C-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YRW6bzHYvWb7J_PDYjUWvtBBeBo>
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: 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
- Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Turner, Randy
- Re: Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Timothy Winters
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Tim Chown
- RE: Updates to RFC6434 Templin, Fred L
- Re: Updates to RFC6434 Tim Chown
- RE: Updates to RFC6434 Templin, Fred L
- Updating to RFC6434 to deal with 8200-style heade… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mark Smith
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Erik Kline
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mark Smith
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Mikael Abrahamsson
- Re: Updating to RFC6434 to deal with 8200-style h… Fred Baker
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Ole Troan
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tom Herbert
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- RE: Updating to RFC6434 to deal with 8200-style h… Manfredi, Albert E
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tom Herbert
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Michael Richardson
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Bob Hinden
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Brian E Carpenter
- Re: Updating to RFC6434 to deal with 8200-style h… Fernando Gont
- Re: Updating to RFC6434 to deal with 8200-style h… Tim Chown
- Re: Updating to RFC6434 to deal with 8200-style h… C. M. Heard