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

"C. M. Heard" <heard@pobox.com> Sun, 19 February 2017 17:34 UTC

Return-Path: <heard@pobox.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998312944D for <ietf@ietfa.amsl.com>; Sun, 19 Feb 2017 09:34:05 -0800 (PST)
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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5xmE4nkX3rvh for <ietf@ietfa.amsl.com>; Sun, 19 Feb 2017 09:34:04 -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 3A7BE129442 for <ietf@ietf.org>; Sun, 19 Feb 2017 09:34:03 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8A425696C0 for <ietf@ietf.org>; Sun, 19 Feb 2017 12:34:02 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type :content-transfer-encoding; s=sasl; bh=br01aGKBq1Y7MStCI+rDwbDlx 6M=; b=JeFs3kIyLZB41mtiJxEIWo8Dahp5JvEHRlcc5QNbX+ZeAKf8lO898Y5X/ u2JfYQbPOC9r7bw9ky8HyTO74Q0fBpnIrQoKSNuvnAsSXSoJXh+s0VikWt6H3OmB kVDGIpwwCM1oaluYD1bhHGiHnhsL2hrvwbv0oNcBvsSt3Vyfxg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type :content-transfer-encoding; q=dns; s=sasl; b=VQOVdqnxuhhdkan3ntm zbJu0QbJsR9qCjM2BBeGpD11BQG3IDNeB5+zGByJqWAOckPFhc/vPvqdYcKs57hY Xry1tIHeVCDSxPktC2wTh8wye+GtgFBxUxlL8qIZDZbJ0+JF4oN9ZgwoVtoI4Gde vtJd5F9RFvH9TGMgXfYm6G5g=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 78E9C696BE for <ietf@ietf.org>; Sun, 19 Feb 2017 12:34:02 -0500 (EST)
Received: from mail-qt0-f169.google.com (unknown [209.85.216.169]) (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 9BDBD696BC for <ietf@ietf.org>; Sun, 19 Feb 2017 12:34:01 -0500 (EST)
Received: by mail-qt0-f169.google.com with SMTP id x49so72120662qtc.2 for <ietf@ietf.org>; Sun, 19 Feb 2017 09:34:01 -0800 (PST)
X-Gm-Message-State: AMke39lLsvvLSTHrinliwdFwvkR2cq6Dx+v/0ydt9Fk08CFg9AgatT5sOD45xoxfJ9CI2MgjYZshHVPdwr/EBA==
X-Received: by 10.200.40.113 with SMTP id 46mr15532045qtr.167.1487525640963; Sun, 19 Feb 2017 09:34:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.18.106 with HTTP; Sun, 19 Feb 2017 09:33:40 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 19 Feb 2017 09:33:40 -0800
X-Gmail-Original-Message-ID: <CACL_3VEykmViHpT=X3XC9wiBU+wDSbHjzrj-JrkJTqtO3v4cSw@mail.gmail.com>
Message-ID: <CACL_3VEykmViHpT=X3XC9wiBU+wDSbHjzrj-JrkJTqtO3v4cSw@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
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: 9A2815AC-F6C9-11E6-8C68-A7617B1B28F4-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FVA5zEhpoq1GFozEufx9RZQAN5U>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Feb 2017 17:34:05 -0000

On 2017-02-18 Brian E Carpenter wrote:
> On 18/02/2017 07:00, Stewart Bryant wrote:
> > Ole
> >
> > Are you saying:
> >
> > A correct implementation of RFC2460 MUST NOT insert an EH at any point
> > along the path other than at the packet source.
> >
> Or
> >
> > A correct implementation of RFC2460 MAY insert an EH at any point along
> > the path.
>
> Ole doesn't, apparently, want to say either of those things.
>
> I want to say the first *as part of the promotion to Internet Standard*
> because it was the clear and documented intent of the authors and WG
> of RFC 1883, which became RFC 2460. (Documented in the ancient email I dug
> out a while back.) And it has been assumed by subsequent work such
> as PMTUD and IPsec/AH.

For the benefit of those who find it inconvenient to dig into the 6man WG
email archives, I've pasted the relevant part of that ancient email below.
See https://mailarchive.ietf.org/arch/msg/ipv6/poEU0yz7m2qpx3EACsszktrOlpk
for the full text of Brian's message.

-------- Forwarded Message --------
Subject: (IPng 609) changes to Last Call'ed specs
Date: Sun, 27 Aug 1995 20:59:26 PDT
From: Steve Deering <deering@parc.xerox.com>
To: ipng@sunroof.eng.sun.com
CC: deering@parc.xerox.com

At the request of our ADs, I prepared the following list of agreed-upon
changes and outstanding issues with the set of specs that underwent
IETF-wide Last Call in June and July.  Please let me know of any errors
or omissions.

Steve
[ … ]
===================================
The following suggestions in Charlie Lynn's formal response to the Last Call
were rejected at the Stockholm meeting:

  - Add a bit to the Routing Header indicating whether or not it was
    inserted into the packet en-route, i.e., by a node other than the
    packet's originator.

      reasons for rejection: insertion of extension headers en-route breaks
      PMTU-discovery and can result in ICMP error messages being sent to
      non-guilty parties.  The desired effect can be achieved, and those
      problems avoided, by using en-route encapsulation (with optional
      Routing Header) rather than header insertion.
[ … ]