Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard Thu, 09 February 2017 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6F02129D26; Thu, 9 Feb 2017 15:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LeaPztK7uRkq; Thu, 9 Feb 2017 15:37:00 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 8F9571294E5; Thu, 9 Feb 2017 15:37:00 -0800 (PST)
Received: from ([]) by with ESMTP; 09 Feb 2017 23:36:59 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 579D7D788D; Thu, 9 Feb 2017 15:36:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Te5tmpVtBpEmi7PnKaYIYB6brOA=; b= paQ3Pph3TnyshM+ZubDnjzu4sCjKzANV3ymAHSntSDgSs1Bstev5e6dXrHteo75+ 4laAU0duhPJskig52nrPYiyejtcEZtV6f6P+vkdMxQnPmpO9y1e6Zk5g4xjSoGUj m8q/uP6BWgurH2/yVSgx8AuFO4i6uuFjZrh59iZzB9k=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=lNwT79mbUcBkkibd2ZPzvaI BewSDrSGLR8JPJhxF+SIZzzcns2Hx8/jPLZl0kjDt8n1pKS/H7JTb0BZXEE65saq PE31cDNdQkvk7SFN6eolVlUjsh6CRR71bq4ubWUj74aee1/F1tHbki06IaS8krrr 26K9uDX2ijHhEnqt8pdU=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id D524CD788B; Thu, 9 Feb 2017 15:36:58 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4D9F288478E0; Fri, 10 Feb 2017 00:36:55 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_7560A77E-A831-406E-AB7E-9FCE5E8D9802"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Fri, 10 Feb 2017 00:36:54 +0100
In-Reply-To: <>
To: Fernando Gont <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc:, IETF Discussion <>, Pete Resnick <>,,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Feb 2017 23:37:02 -0000


>>>> Fernando,
>>>> Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
>>>> I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.
>>>> I don't understand your message.
>>>> Do you disagree with the summary itself? Are there arguments missing?
>>>> Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?
>>>> Or are you just rehashing your position on the issue?
>>> I think that some points are not as clear as they should be:
>>> 1) The current state of affairs with respect to IPv6 EH insertion is
>>> that insertion is forbidden. It has always been clear to everyone.
>> I don't think it has. In fact, that's the whole point: some people
>> have *not* deduced that rule from the RFC2460/RFC1883 wording.
> "It has always been clear.... till these proposals on EH insertion arised".
> Since some people didn't "deduce" it from the current text, that's a
> clear indication that a clarification is warranted.

You can now optimize this discussion without having to bother the whole IETF list. Just look up the counter arguments in the previously posted summary.

E.g. the response to your argument in this email:
1.a.i) Out of scope: Argue the point of header insertion or alternatives in the context of those proposals, not in the context of the core IPv6 specification. Do not try to make a preemptive strike in the core specification.

Only partly tongue in cheek.