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

Nick Hilliard <nick@foobar.org> Tue, 07 May 2019 19:13 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 AD3101200CE for <ipv6@ietfa.amsl.com>; Tue, 7 May 2019 12:13:47 -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_PASS=-0.001, URIBL_BLOCKED=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 qdbv7XLJv2KZ for <ipv6@ietfa.amsl.com>; Tue, 7 May 2019 12:13:44 -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 280F41200B5 for <ipv6@ietf.org>; Tue, 7 May 2019 12:13:43 -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 x47JDe2n018504 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 May 2019 20:13:40 +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: Bob Hinden <bob.hinden@gmail.com>
Cc: Sander Steffann <sander@steffann.nl>, IPv6 List <ipv6@ietf.org>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <a2465e81-a17f-ab48-efda-20fe12a70077@foobar.org> <30239E0C-C444-4A7E-8342-AEE47BF8A2BB@employees.org> <20190505200449.GB7546@vurt.meerval.net> <80073906-c3c0-1f22-9e7f-c2b349063936@gmail.com> <CAO42Z2xzVW3m0mN7jEn8SYyYCYhrufVnkfp3rBjJcijBkvucNQ@mail.gmail.com> <CACWOCC-35yVYXSRR0sRL-MBMHyOFZtJx9E9h14G8qqVh5T7qGA@mail.gmail.com> <232c1a43-0fd9-4eae-737b-260a3906f72a@gmail.com> <51F2BD2A-A590-4AF1-B8C1-FE62C9416340@steffann.nl> <8C63324F-FEF6-40BD-B918-B413CDEF9186@gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <478d5dc5-af00-4ab0-d8ef-75e41cd501d4@foobar.org>
Date: Tue, 07 May 2019 20:13:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.15
MIME-Version: 1.0
In-Reply-To: <8C63324F-FEF6-40BD-B918-B413CDEF9186@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OMSE-DJQ22LL25JSyAblY-tijO8>
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, 07 May 2019 19:13:48 -0000

Bob Hinden wrote on 07/05/2019 17:31:
> Enterprise networks are an important use case for this proposal.
> 
> The draft seems to me to be clear it is focused on managed networks.
> It uses the word “administrator” 12 times.   There is, of course, no
> administrator on unmanaged networks.
> 
> Would it help if the draft said the focus is for managed networks?
Not really, no, because when you look at it more closely, it becomes 
apparent that the flag is redundant on managed networks.

What's important about managed networks is that they're managed.  I.e. 
that whatever policy is put in place by the administrator can be 
enforced.  v6only does not and cannot enforce anything, which means that 
from the point of view of policy or enterprise management, it fails 
before it leaves the block.  It fails because all it does is provide an 
advisory hint to the operating system about the intentions of the 
network administrator.

Drilling down further and looking at the issue from the point of view of 
an enterprise network, management would encompass either device 
management or fine-grained network access control, or both.  In each 
case, the management will be enforced because if it's not enforced, it's 
not management: it's hand-waving.

For device management, it might be e.g. Windows group policy, or macos 
workgroup manager, or some orchestration tool (puppet / saltstack / 
etc), or some COTS product to do all this - there are plenty out there. 
The point is that the management of the devices on the network will be 
centralised and will give the administrators of the network the ability 
to enable or disable ipv4 by application of enforced policy.

No sane operating system manufacturer will leave the v6only option 
enabled by default on an out-of-the-box installation because the 
possibility of mischief is far too great. This means that if the 
administrator wants to change this default, they will need to touch the 
configuration of each installation.

But here's the thing: if they already have to change the default 
configuration to enable v6only, why wouldn't they go the whole hog and 
just disable v4 completely?  More to the point, if they need to delve 
into this level of operating system protocol capabilities, their policy 
management tools will be sufficiently fine-grained to enable or disable 
any specific protocol on any specific network that they choose.  In 
other words, the v6only flag is almost entirely irrelevant for managed 
networks where the management capabilities are done on the host devices. 
  The job can be done more simply and more reliably by using existing tools.

The other type of managed network is where control of the network access 
is managed.  I've gone into some detail on this scenario on several 
occasions before, so please forgive me for quoting these URLs:

https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI
https://mailarchive.ietf.org/arch/msg/ipv6/a9KBvO88PlPrO0kLr83VOBlGmpw

Summarising:

- L2 ACLs provide vastly superior functionality, and work today.

- even L2 ACLs on core links can reduce the problems assertions in the 
v6only-flag problem statement to background noise.

- gigantic l2 domains were busted about 30 years ago as being terrible 
network design and the ietf has no responsibility to create workarounds 
for people who implement terrible network designs.  And if you really 
need to implement gigantic l2 domains, you need kit which is fit for 
purpose.

I.e. if you want actual management, then you need to manage, and that 
mandates enforcement.  The larger your network, the more effort you need 
to put into designing it properly - and managing it using appropriate 
equipment.

I'm sure it would be possible to contrive scenarios where marginal gain 
in functionality is achieved with the v6only flag, but in 18 months of 
discussion (and draft-perreault-sunset4-noipv4 before it), not even a 
single credible use case has come up where the alternatives weren't better.

Nick