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

Brian E Carpenter <> Mon, 13 February 2017 00:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58183127058; Sun, 12 Feb 2017 16:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fyMBW16AyXyB; Sun, 12 Feb 2017 16:40:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28BF41294E1; Sun, 12 Feb 2017 16:40:12 -0800 (PST)
Received: by with SMTP id o64so5281073pfb.1; Sun, 12 Feb 2017 16:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hApkLpY3/DPAaZGAiEKt2nmkpVh72MkkfVJ52b1bUjw=; b=ppVkN2f4zsTJf1Do91cARSAWxmkTICS+sixyyUAN1hnwB4LnJlcm2Gfryz6y40DY0H tIifM81LYweJaRibtSR8bhAkV7IOg162uovfrMuseMIepFG0qENQSIhLfJkep2z+5qe9 l6HzJm5eGRlu/w6dB9H8FOUxfbDpa+pQPst/evoyT00y/QKcWh6nS5UZmfFTjvJ0kcQ4 Fr88nCILpnE+OP+cCKcta5KWxYI8B/o7oXvNj1bAUObXldtIgLCKkF5DHOZ4DhouExxG pB2R9zb81q5sdBEIFHrbR+GHx7wqHjToaeP5ADgg61psCU4hHyDKVFnO1/AfHP0EQft6 /Xhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hApkLpY3/DPAaZGAiEKt2nmkpVh72MkkfVJ52b1bUjw=; b=qn7HKfF2YREkoQJEO8m4vq3CBFqsJB2waWwZhvRWOZv5B/xwPV3VvnUkCSUS4LaDEm zd2r0C3PoLySv+PSZ9z7NpXEafsmrzjvp72pkQogYtlrFEi7lyCVeUCuNJOzZck6JZYq 5HSMaWstUpulR05pJgIDgCMhVP1/OtTDSpvqd6uLPSF6k36iZ7+BLV5Puqi5WgJWUL5Y RprTb6j/UKe+cY4Wy/AwF1THDu80/a0USiKHbHqVfS7LBqQsx2Bxfm6H1AioXnZ7x2sh YWtj8NWuE5GfFzZs3TApSlfMZNWlGW9m4vy/irjRMlEmd0yh69mXJR6Y6Q289O8vYeYQ auTA==
X-Gm-Message-State: AMke39nagcROjcKsnhQiL4+E9pQeSTo/0K3e0ZdJlX2y/+DnZLN/In5ttWmxMvUJQY+h0w==
X-Received: by with SMTP id e63mr23812563pgc.104.1486946411640; Sun, 12 Feb 2017 16:40:11 -0800 (PST)
Received: from ?IPv6:2406:e007:6e60:1:28cc:dc4c:9703:6781? ([2406:e007:6e60:1:28cc:dc4c:9703:6781]) by with ESMTPSA id b83sm16903658pfe.12.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 16:40:10 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: "Leddy, John" <>, "Eric Vyncke (evyncke)" <>, Suresh Krishnan <>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
References: <> <> <> <> <00af01d27e11$fe539500$> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 13 Feb 2017 13:40:04 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Pete Resnick <>, "" <>, IETF Discussion list <>, "" <>
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: Mon, 13 Feb 2017 00:40:14 -0000


On 13/02/2017 12:05, Leddy, John wrote:
> I’m trying to understand how a ban of this functionality would work.  Is it targeted at vendor products, precluding them from implementing the functionality?

It's targetted at interoperability across the Internet. We can never stop
people doing whatever they please inside a private domain, obviously.
As always, there are no protocol police.

> If there is a technical problem that can be solved by using EH insertion within a domain where there are no harmful side effects, it should be able to be used.
> In a software networking world where functionality is being deployed that is not from traditional network vendors; solutions that solve problems efficiently will get deployed.

We had a lot of this conversation in a slightly different form prior to
RFC 6437. It proved impossible to specify "local domain" rules that could
reach consensus. I think we'd have the same problem trying to write rules
for header insertion/deletion within a domain. But in any case, that isn't
the target for RFC2460bis: the target is the Internet.


> John Leddy
> From: ietf <> on behalf of "Eric Vyncke (evyncke)" <>
> Date: Sunday, February 12, 2017 at 3:56 PM
> To: Suresh Krishnan <>om>, 神明達哉 <>
> Cc: "" <>rg>, IETF Discussion list <>rg>, Pete Resnick <>om>, "" <>rg>, "" <>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
> Suresh, Jinmei and Fernando,
> I fully agree with you Suresh, the goal of an IETF last call is to get NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.
> -éric
> From: ipv6 <> on behalf of Suresh Krishnan <>
> Date: Saturday 11 February 2017 at 07:11
> To: 神明達哉 <>
> Cc: "" <>rg>, IETF Discussion list <>rg>, Pete Resnick <>om>, Fernando Gont <>om>, "" <>rg>, "" <>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
> Hi Jinmei,
> On Feb 10, 2017 1:23 PM, "神明達哉" <<>> wrote:
> At Thu, 9 Feb 2017 18:30:11 -0300,
> Fernando Gont <<>> wrote:
> While I largely agree with Fernando on everything he said, I have to
> admit most of the points are just repeated from the 6man discussion,
> and won't get us anywhere new by discussing these again at this point.
> I guess the only new input for the IETF last call is this:
>> 2) However, some folks came up with proposals to insert EH, on the basis
>> that "RFC2460 does not explicitly ban EH insertion". If there's people
>> arguing that, we clearly need to make this clear in the spec.
>> 3) There was a consensus call, yes. When the call was made on the
>> mailing-list, the vast majority of supporters of "let's keep the
>> ambiguity" were folks from the same company as "2)". I have no idea if
>> this changes (or not) "consensus"... but this is clearly an important
>> datapoint.
> Although I don't want to point a finger at particular people or
> organizations without an evidence, I guess not a small number of 6man
> participants (not only those who explicitly spoke up here) suspected
> that the decision process was biased with the influence of a large and
> powerful organization and the process and resulting "consensus" was
> not really a fair one.  And I'm not an exception to it - in fact, it
> was so unbelievable to me that we can't clarify an ambiguity even when
> we were also open for future extensions, that I couldn't think of
> other reasons than a company agenda.
> Of course, it's quite possible that it was just a coincidence that
> many people with the same organization genuinely thought we should
> leave it ambiguous while many others strongly thought we should
> clarify it but few (if not no) people from that organization supported
> the clarification.  But I don't think we can prove it either way.
> But as Fernando said, I believe this point (and that several, and
> arguably more, participants suspected it) should be included in making
> the decision at the IESG and at the IETF last call.  And, whatever the
> decision, it would be more productive to move on after that and use
> our time for some other things.
> I am guessing that the people who spoke up during the WG process to not put in an outright prohibition would make their case along with their arguments here as well. We are only a week into a four week long last call.
> Thanks
> Suresh
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------