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

"C. M. Heard" <> Sat, 18 February 2017 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C127129675 for <>; Sat, 18 Feb 2017 15:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Status: No, score=-2.202 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] 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 dxvTTliHMFNs for <>; Sat, 18 Feb 2017 15:15:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D75F129667 for <>; Sat, 18 Feb 2017 15:15:38 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id C6F586AAF6 for <>; Sat, 18 Feb 2017 18:15:32 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=0ir ndjj8PjILfcnXOsRWeYZyK4I=; b=xpife6wdh4/rQPJrYNGMzgvO4jMsLkcapFS XUisV8r1JKUVs68LWV8SWJeIqnsD0js3VhzJiYSGKp4xqsQnT4MIOcqjrWPP2xc2 ZJWT1j/FG4kt50cLRAHLoRaYea5+w6YNKXtThrfCG+zuUTb80GV7x9cG+OEYpP5I wAMAJ2fM=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= gf9IfeQZIbQiW3djz4g2qMGqj4wMP/SiCA6wTpg+kWZeVVfMBMjFXbGJAOXUYk4t dj2f1u2ybRQ72fkQl5IJWphREq7JDclfAExcPvtUcr2fFh4VCleAqqaM3q9XEcqM vgioaEaUj3kFPEERkzSjMCmxxWbBT3CcSLRJIJ+qgF0=
Received: from (unknown []) by (Postfix) with ESMTP id BEC9A6AAF5 for <>; Sat, 18 Feb 2017 18:15:32 -0500 (EST)
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 B9FB26AAF1 for <>; Sat, 18 Feb 2017 18:15:31 -0500 (EST)
Received: by with SMTP id b16so15514076qte.0 for <>; Sat, 18 Feb 2017 15:15:31 -0800 (PST)
X-Gm-Message-State: AMke39l8tpIAY1J60als1sHpsQ+3soqGQbCHP5zwtuE64oyvL/Py5MG/gTy000LPmfAiwarNFo501/qj2E0Lcg==
X-Received: by with SMTP id h36mr13255506qte.11.1487459731289; Sat, 18 Feb 2017 15:15:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 18 Feb 2017 15:15:10 -0800 (PST)
From: "C. M. Heard" <>
Date: Sat, 18 Feb 2017 15:15:10 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: "Joel M. Halpern" <>
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: 24CEF378-F630-11E6-B247-FE3F13518317-06080547!
Archived-At: <>
Cc: Ole Troan <>, IETF <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Feb 2017 23:15:40 -0000

On 2017-02-17 Joel M. Halpern wrote:
> I disagree with your interpretation of the bar the document must meet.
> I believe I have clearly stated my concern.
> I will leave that judgment to the relevant ADs and IESG when they
> review the last call results.

Thank you for saying this.  I am glad to see that someone who was not
involved in the WG discussion has chosen to speak out in support of
that position.

During the WG discussion, I said:

"If I were on the IESG and a spec came to me with a known ambiguity,
 I would vote to send it back to the WG with instructions to resubmit
 it after the ambiguity was fixed."

I would base that on the following language from RFC 2127, Section
3.1 (which replaces similar language in RFC 2026, Section 4.1.1):

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.

The relevant ADs and IESG may see this differently, but in my view,
language that has been shown to admit conflicting interpretations,
either by implementors or by authors of subsequent specifications,
constitutes a "known technical omission," and if that's not good
enough for PS, it's clearly not good enough for IS, either.

There is ample evidence in the record that the language in both 2460
and now in 2460bis has led to conflicting interpretations regarding
the admissibility of insertion of extension headers by any node other
than the one originating the packet.  The main discussion in 6man
focused on the segment routing header, where versions of
draft-previdi-6man-segment-routing-header up through 07 called for
insertion of that header by a border router, and according to and,
that behavior was actually implemented (for further evidence, see
also  That behavior was removed
in favor of encapsulation in the -08 version of the draft and also in
the version adopted by 6man (draft-ietf-6man-segment-routing-header),
but the older implementations apparently linger on.

The early SRH drafts, however, are not the only examples of conflicting
interpretations of the language in 2460. RFC 6621 Section 6.1.3 says:

   If a digest collision is detected at an SMF ingress point, the H-DPD
   option header is constructed with a randomly generated HAV.  An HAV
   is recalculated as needed to produce a non-colliding hash value prior
   to forwarding.  The multicast packet is then forwarded with the added
   IPv6 SMF_DPD option header.

By contrast, RFC 4782 (Quick Start) and RFC 6971 (Depth-First Forwarding)
were careful to specify that the HBH options defined therein were either
inserted by the source node or that encapsulation was used if inserted
by a non-originating node.

I couldn't find any discussion of 6621 or 6971 in the 6man archive.
I did see 4782 mentioned as problematic, but I didn't get that from
reading the RFC, which carefully discussed compatibility with AH.

On 2017-02-17, Ole Troan wrote:
> Do we agree that you can see this at two different angles?
> 1) Are there any interoperability issue or ambiguity in the protocol
>    specification of 2460 and how implementors of 2460 have interpreted
>    that?
> 2) Is 2460 "future-ambiguous", i.e it is unclear if 2460 permits a
>    future extension? Like ECMP, Header insertion NAT...

Question #1 is incomplete, as it fails to ask if there is an ambiguity
that has tripped up authors of specifications extending IPv6. That is
demonstrably the case. And it is equally clear from the discussion
on record that insertion of extension headers by intermediate nodes
breaks fundamental assumptions of IPv6 and causes some of the
core specifications to fail.

Question #2 is also incomplete, as it fails to acknowledge the
difference between extensions that break parts of the core
specifications and those that do not.

> I'm trying out the argument of declaring the whole question of
> ambiguity out of scope. To see if there is better consensus for
> that.

And I am hoping that the community and the IESG do not buy this.

Best regards,

Mike Heard