Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

"C. M. Heard" <heard@pobox.com> Fri, 03 February 2017 17:20 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 47F32129407; Fri, 3 Feb 2017 09:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Level:
X-Spam-Status: No, score=-5.4 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, RP_MATCHES_RCVD=-3.199, 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 XDfPKmSLxTNb; Fri, 3 Feb 2017 09:20:57 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA38129678; Fri, 3 Feb 2017 09:20:53 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4AA2462708; Fri, 3 Feb 2017 12:20:50 -0500 (EST)
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=YSV qVQlzrT/OgZPaK+xeyUHt3Kg=; b=XS8owOJ7puuqFtEZKi4tX6iN1PSsz9tOcca LOgJbLyR3+Zbp3tJdHQ5i8o6NNnIQgkAeqafF2rA5azsBZpIG5gjH0GpSnno2QBb z8CO9NhSsp+D98G1S5HVUJMi2XplErP9q6p00pssrGhQZWl0uSrBJ1l/4QOQryeb +o+Z1+xU=
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= KH0ORbrgz5hA5ndy3/kkQICa9ifFDVLOh0fuQQNt2MZ9UIUKLLRJWElw64pnfgpF J46N5/5Yl05FwgWJMDcLs7lb3PVz3TLftL3FPcu1zi5FUbm5R91k/ZqGgAOYn/nx YmPN+uKn5GTcAN80/UjRewggXhaySw86IuilBCe3/vE=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4242062707; Fri, 3 Feb 2017 12:20:50 -0500 (EST)
Received: from mail-qt0-f170.google.com (unknown [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C10DD62706; Fri, 3 Feb 2017 12:20:49 -0500 (EST)
Received: by mail-qt0-f170.google.com with SMTP id k15so44917991qtg.3; Fri, 03 Feb 2017 09:20:49 -0800 (PST)
X-Gm-Message-State: AIkVDXIRn/XPNyrPvdBikw6fP1NilN8CU9wujQv7ZyN3n+sXFQD5YtCIy4Bz/mypPrb/ptPs6ReA2mWDVpF5Nw==
X-Received: by 10.200.39.35 with SMTP id g32mr15525354qtg.265.1486142448990; Fri, 03 Feb 2017 09:20:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.18.106 with HTTP; Fri, 3 Feb 2017 09:20:28 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 3 Feb 2017 09:20:28 -0800
X-Gmail-Original-Message-ID: <CACL_3VGL5ecO=-7gqiEKxHtqoTFXpZd6+hQd7FtT9Qc2F11Paw@mail.gmail.com>
Message-ID: <CACL_3VGL5ecO=-7gqiEKxHtqoTFXpZd6+hQd7FtT9Qc2F11Paw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: IETF <ietf@ietf.org>
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: 1B91960A-EA35-11E6-A4A5-A7617B1B28F4-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/B0cAlDMJE1z1JFTiB4-a0eAq_X8>
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, draft-ietf-6man-rfc2460bis@tools.ietf.org, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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 Feb 2017 17:20:59 -0000

On Fri, Feb 3, 2017, at 1:37 AM, Brian E Carpenter wrote:
> In Section 4 ("IPv6 Extension Headers") the draft says:
>
>>    With one exception, extension headers are not processed by any node
>>    along a packet's delivery path, until the packet reaches the node (or
>>    each of the set of nodes, in the case of multicast) identified in the
>>    Destination Address field of the IPv6 header.
>
> (FYI, the exception is the hop-by-hop extension header.)
>
> I do not dispute that this sentence reached WG consensus. However, I want
> to ask if it has IETF consensus. In my opinion, this sentence should read
>
>    With one exception, extension headers are not processed, inserted,
>    deleted or modified by any node along a packet's delivery path, until
>    the packet reaches the node (or each of the set of nodes, in the case
>    of multicast) identified in the Destination Address field of the IPv6
>    header.
>
> I believe this was always the intended meaning of the word "processed"
> from the earliest design phase of IPv6, but some people have read this
> text as allowing insertion, deletion or modification of headers. IMHO
> it needs to be clarified.

I, too, am of the opinion that the WG consensus on this point was wrong.

>From the outset it has been fundamental to the IPv6 architecture that
an ICMPv6 message triggered by a particular packet will be sent back to
the source of that packet. If an intermediate node inserts an extension
header or makes an alteration in one that triggers an ICMPv6 error
message -- for example, Packet Too Big or Parameter Problem -- that
error message will be sent back to the source of the packet, not to
the node responsible for inserting the offending header or alteration.
That is fundamentally broken.

On that basis, I don't think that there is any doubt that Brian's
construction of the intent of RFC 2460 is the correct one, and
the language of RFC 2460bis should unambiguously reflect that.

Mike Heard