Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

Toerless Eckert <tte@cs.fau.de> Wed, 31 October 2018 15:47 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 7E05B130DE5 for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 08:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 SWyiTw1vr_IP for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 08:47:42 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE898130DDA for <ipv6@ietf.org>; Wed, 31 Oct 2018 08:47:41 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CD327548140; Wed, 31 Oct 2018 16:47:37 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C079E440210; Wed, 31 Oct 2018 16:47:37 +0100 (CET)
Date: Wed, 31 Oct 2018 16:47:37 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Simon Hobson <linux@thehobsons.co.uk>
Cc: 6man WG <ipv6@ietf.org>
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Message-ID: <20181031154737.3errng2ifcmmzcve@faui48f.informatik.uni-erlangen.de>
References: <9A4368D6-E4B1-474C-9838-B584AF6D70C8@thehobsons.co.uk> <m1gHUMI-0000I6C@stereo.hq.phicoh.net> <acb0984ec73b40c9a350a0d144b23835@boeing.com> <20181030183416.wfv47m63w5xk3cqe@faui48f.informatik.uni-erlangen.de> <143d790e624d498c91fbf69b070da007@boeing.com> <20181030210020.66dppz77jeowp722@faui48f.informatik.uni-erlangen.de> <87651dfca4694f599e67abbc593f1787@boeing.com> <7FFB03B9-2629-47D1-A3D1-E4FDD6937BC3@thehobsons.co.uk> <CAO42Z2xeqJN3_MSx8Z5cY_kmVDfm-4C7oWKPbnecbC2Fww6UJw@mail.gmail.com> <E74C0E26-87B6-403E-8052-BD6533C1D79B@thehobsons.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E74C0E26-87B6-403E-8052-BD6533C1D79B@thehobsons.co.uk>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mc8L2DF1AyLe7cnqw2efLQCWGRc>
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: Wed, 31 Oct 2018 15:47:45 -0000

On Wed, Oct 31, 2018 at 10:12:08AM +0000, Simon Hobson wrote:
> > Because the network operator has actively asserted that there aren't, by actively choosing to set this flag.
> 
> I agree - that would be the case using the flag. But Albert (to whom the question was asked) asserts that heuristics such as "IPv6 appears to work and we have no active IPv4 connections" is sufficient to determine whether or not to enable IPv4.

I am asserting that routers can can assert whether there are 
any IPv4 only hosts on the LAN and only when there are none,
and if the router itself is also not configured to route IPv4
would it automatically set the v6only flag.

> > We're getting into trying to prevent insanity territory with these sorts of corner cases. 
> 
> I agree. Setting the flag where IPv4 is expected to continue working would be a configuration error - and one that the network admin can fix by unsetting the flag.

To me any new solution that requires more configuration is always
a downer. Primarily, everthing new we do should be autoconfiguring,
and only when sufficient analysis ha been done that this is not
possible should we continue discussing manual config requirements.

I have not seen sufficient discussion concluding that this flag
can not be autoconfigured by routers.

> Doing it by heuristics is prone to soft errors that would be hard to diagnose and harder to fix. But I don't seem to be getting through to Albert on this one.

Right. either we're able to specify explicit algorithms
for things or we're just doing a half-baked job.

Also i thought you have to say NN/DL/AI and not "heuristic" to
get funding ;-)

Cheers
   Toerless
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
tte@cs.fau.de