Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 15 March 2017 18:59 UTC

Return-Path: <brian.e.carpenter@gmail.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 A345B1317C4; Wed, 15 Mar 2017 11:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5CvrN5SPTKBx; Wed, 15 Mar 2017 11:59:25 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F7B1317B6; Wed, 15 Mar 2017 11:59:25 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id z13so26950965iof.2; Wed, 15 Mar 2017 11:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ws6E1ZoldqSknOCCnwZETYm/BULceeEuOtraiX3XFcY=; b=WJlIJijpV8QSOi3uBfekk2iNSoIYyrCr000BTtHXYEnqf678otwjr2Gm87SrvBLAgJ Kq7y2PIw0oidr9I9giGN6mR3LR4pIPvwanfot0rnUJ9nLV/hLXOu+5XLbt2EvpXygOtm 1yJCro1jVdoFZ88xB4oaZIs9FC5JqOr6SyaHgrH4QWEy3ScYyeR3qK8X8iuNfCiUVCWF jSXH/5e9pMXWXH9V3Js7GmZ0Xa5hf27veGIURx1LpJG+H4n8D4T7247V1ivL698nlGtd dmnEoRBGO7bzSuNtPeIoJqDPESrrgT/2i71xaA1RGJPE1cbVTVy9tFrFBVy0RiY+fhgF YUHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=Ws6E1ZoldqSknOCCnwZETYm/BULceeEuOtraiX3XFcY=; b=TZ8Hs10K/Hc6peGXtMkb6FzgvLKzXn6f6spQcd6JLjLsSeGKUQcXMzmZeJwjLyGTjf 56pQIIA4yl4oEDh6Qz70f5eM90nuT0MR7HFfqKbVIbY1HTeziI9pWYDUUprpAVI4rRbd kVaKGs/bSzu4+azLMlhi5dlZbonQUPo3RyXNKJH7n2mzhDWqcOvOeIT8lxT8z3jEunSh 3RIG3QDz5854w5oAOunj3iSsbtHVJ8T4xWhaXk9ktv6ge8hz/ubnJsunZ61tvEBnK0Jo PJUP39zNi+HHy7o3zbGXXz65f7B78IxCmH+dKXSZJHCk41tGIexGrwtnBlmGWy1P9vEA 1tCA==
X-Gm-Message-State: AFeK/H0Citk4edN09Jhb5gXWImJ5eZ4uur+R3oQZj8efcQp7CpBnH4QSrQZZKXmQfQJXJw==
X-Received: by 10.107.2.201 with SMTP id 192mr6547803ioc.81.1489604365107; Wed, 15 Mar 2017 11:59:25 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id i189sm538611ita.23.2017.03.15.11.59.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 11:59:24 -0700 (PDT)
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Joe Touch <touch@isi.edu>, "Leddy, John" <John_Leddy@comcast.com>, Tim Chown <Tim.Chown@jisc.ac.uk>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <A67E1C07-282B-4422-A2FF-86F6CACBD775@cable.comcast.com> <ab7c95a5-9776-24b5-7c26-4c5987d4c948@isi.edu>
Cc: "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <ed2f5144-52fb-dda5-1fb4-62be1625b341@gmail.com>
Date: Thu, 16 Mar 2017 07:59:31 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <ab7c95a5-9776-24b5-7c26-4c5987d4c948@isi.edu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mzZIl8EoxS7rik1Vekqi0DCjrgg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Mar 2017 18:59:28 -0000

On 16/03/2017 07:14, Joe Touch wrote:
> 
> 
> On 3/15/2017 9:33 AM, Leddy, John wrote:
>> Does this mean that only middle boxes, not covered by the architecture could insert an extension header for use within the domain?
> Please see my recent post about Stefano's issue. IMO, any opaque
> (distributed) system that acts like a host can follow the host (node)
> requirements.
> 
> The instant that system is not opaque or fails to act like a single
> host, it becomes noncompliant.

That's the point. That's why the 6man WG shot down proposals to play
intra-domain tricks with the flow label a few years ago, and they
didn't even break PMTUD or IPsec/AH.

In another form, the answer to John is that there are no protocol police,
so what consenting adults do inside their own networks simply isn't an
issue that an Internet-wide spec can or should address. And for sure, the
spec for IPvN for any value of N is an Internet-wide spec.

If Stefano and colleagues describe how private domains can perform tricks
that MUST NOT be exported to the Internet, that is fine. Whether that
becomes a standards track document or an Independent Submission RFC is
another question. But IMHO it is completely orthogonal to the rough
consensus on 2460bis.

    Brian