Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Nick Hilliard <nick@foobar.org> Tue, 28 May 2019 17:33 UTC

Return-Path: <nick@foobar.org>
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 30E42120228; Tue, 28 May 2019 10:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qMhL9BXGpXK8; Tue, 28 May 2019 10:32:59 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D67120048; Tue, 28 May 2019 10:32:58 -0700 (PDT)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x4SHWuVq056284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 May 2019 18:32:56 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
To: David Farmer <farmer@umn.edu>
Cc: Sander Steffann <sander@steffann.nl>, 6man WG <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <m1hQCYr-0000KBC@stereo.hq.phicoh.net> <561d9dc3-c769-c774-8f65-f975ac2a10a0@gont.com.ar> <m1hT1DZ-0000HEC@stereo.hq.phicoh.net> <ce07ade8-5105-055f-4798-f4ef20a2393c@si6networks.com> <CAN-Dau02MYCrKx2BgyuYJeHBdoz6SHCnp+-byM+LMM8af0S+rA@mail.gmail.com> <40e99171-6dda-29e3-6152-da5ca5219ed9@foobar.org> <CAN-Dau0ALqfAA-Dz56oHAfOtY7E2obx5E7TgoeH357Mckp3t9g@mail.gmail.com> <093ba8e2-6f0a-4c91-9df1-cda33fffea97@foobar.org> <CAN-Dau3kVqb+ZEHB7iPGeRuq1Mu8UHR3FEZv8SgmiqZexaFhuA@mail.gmail.com> <12db9629-f92a-e12a-5ff1-7db2c5d2137e@foobar.org> <F6F0C9DC-545E-4FE5-BB4C-55BB29022E84@steffann.nl> <CAO42Z2yUDi3FHOZsLrHqwLsEWkB1X9FREa8m6dU6ecOr=SsX4g@mail.gmail.com> <E51102E7-D4F0-4469-8888-5072F624EE06@steffann.nl> <CAN-Dau1S57wQ+3+m+m5grMe5N2SdfFqhELteSYfkmAC85_8H3w@mail.gmail.com> <8523a960-d551-1c24-d756-10c1840289de@foobar.org> <CAN-Dau27O9QB9MHhk81RsewwpH=xW=D1ZrUDmEq+WP0_Fyeh5Q@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <4a73b73a-7d84-4fa2-b15f-21b8cb74cbbf@foobar.org>
Date: Tue, 28 May 2019 18:32:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <CAN-Dau27O9QB9MHhk81RsewwpH=xW=D1ZrUDmEq+WP0_Fyeh5Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8cVly18sU_cNObpQh4U5WT4ksB8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 May 2019 17:33:01 -0000

David Farmer wrote on 28/05/2019 15:57:
> Again you seem to have gone back to either using RFC2563 or filtering 
> separately and have completely ignored the requirement to do both.

The draft assumes that neither is an option, so why do some of us 
continue to bring these things up at all (see below)?

> Filtering by itself leaves hosts sending futile traffic and wasting 
> battery power, and RFC2563 by itself leaves the network susceptible to 
> hosts that ignore the signal from RFC2563.

And the ipv6only-flag option proposes to fix this by implementing fate- 
sharing between ipv4 and ipv6, while offering a mechanism that can 
either promise hard ipv4 shut-down by protocol and open serious security 
problems in the process or else implement the flag as one of potentially 
many heuristic inputs to hint to the host device to tune down ipv4 
services, in which case it doesn't have as many security issues, but 
also doesn't fulfil the stated objective of shutting down ipv4 services.

So the question is: what are we actually trying to achieve here?

We can probably all broadly agree that there are some situations where 
we might want to tune down excessive ipv4 chatter on some types of 
network segment, including those which might only support ipv6 as a 
working protocol.  We've sort-of identified that some types of large, 
flat, semi-managed, byod, wifi networks merit investigation in this regard.

We're now over 1000 emails into this discussion and at least to me, the 
working group seems to be hopelessly split on almost everything else 
raised over the last 2.5 years.  Probably others disagree about this 
assessment, but ultimately it doesn't matter because it's not our call - 
it's the chairs' call.

So at this point, it would be helpful if Ole could make a determination 
on whether there is consensus to move the document forward.

Nick