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

Toerless Eckert <tte@cs.fau.de> Wed, 31 October 2018 16: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 C93A7130DC9 for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 09:47:11 -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 aJZFptykRRvP for <ipv6@ietfa.amsl.com>; Wed, 31 Oct 2018 09:47:08 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 7EE5E12F18C for <ipv6@ietf.org>; Wed, 31 Oct 2018 09:47:08 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E3679548140; Wed, 31 Oct 2018 17:47:03 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D4BC4440210; Wed, 31 Oct 2018 17:47:03 +0100 (CET)
Date: Wed, 31 Oct 2018 17:47:03 +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: <20181031164703.tsjwgsw4e4twcgfl@faui48f.informatik.uni-erlangen.de>
References: <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> <20181031154737.3errng2ifcmmzcve@faui48f.informatik.uni-erlangen.de> <5AA151D6-E8C6-40FB-BF2C-C4610C260400@thehobsons.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5AA151D6-E8C6-40FB-BF2C-C4610C260400@thehobsons.co.uk>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pmfGAVeglRqBElP1wM7m2c_lw-Q>
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 16:47:12 -0000

Simon,

The basic level of autoconfiguring which version of IP needs to be
active on a host is IMHO not an administrative function, but just
an automatic simplification of host stack operations, and beside
simplification it also can help to save battery (hopefully, as said
i wouldn't want to quantify that aspect). Thirdly, it would
automatically retire IPv4 in man subnets and solve IMHO the most
obnoxious unnecessary proliferaion of IPv4: you only have
external IPv6 connectivity, no old IPv4only host, and yet,
every device in the subnet still enables stupid IPv4 link-local.

So, its kinda completely incomprehensible how we would NOT want to
try to eliminate this most easy and most obnoxious IPv4
remains. All the other places where we would want to get rid of IPv4
are more difficult to deal with automatically IMHO.

You are right that a manual choice of "there are IPv4only devices,
but i still set the flag, because all "new" devices undersstanding
the flag would not need to talk to the old IPv4only devices. This
is fine, but its somewhat of a freeby to me: If we define
automastic operation of the flag thats as useful as stated above,
i don't reject manually configured overrides in the good old
tradition of allowing admins to shoot themselves or their
users in the feet.

> Secondly, an IPv6 only router won't know if there are any IPv4 devices there.

Good point. So for automatic settings of the flag, an IPv6only
router would need to implement listening to those IPv4/ARP packets
that would indicate presence of IPv4 only hosts. Or the feature
really is only supported on dual-stack routers configured
(or defaulting ) accordingly for only IPv6, in which case maybe
a second flag would be good for IPv6only routers indicating
"ipv6only-router", in which case that routers announcement
can be ignored on hosts trying to figure out whether IPv4 needs
to be enabled.

But maybe instead of starting delving into the technical issues,
the question is what type of problem we're trying to solve in
order of priority, and whether or not the top priority should be
to eliminate unnecessary enabling IPv4 on hosts AUTOMATICALLY - 
as i claim. Or battery saving as the draft claims.

Lastly: Yes, there are still new consumer devices with IPv4 only
stacks. The worst offenders are probably all those devices
where IP multicast is a key function and companies being too lazy
to move to IPv6 because they want to avoid duplicating content
in both IPv4 and IPv6 multicast. The most egregious new offender
IMHO is SES with its SAT-IP standard in europe thats also IPv4 only.
In this case it would be perfectly eay to also support IPv6 IMHO

*sigh*.
    Toerless

On Wed, Oct 31, 2018 at 03:54:50PM +0000, Simon Hobson wrote:
> Toerless Eckert <tte@cs.fau.de> wrote:
> 
> > 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.
> 
> There are TWO really big and in practical terms insurmountable problems there.
> 
> Firstly, wanting to deprecate IPv4 (in as far as this flag assists it) is an administrative function. it is not a case of whether there are any IPv4 only devices on the network - as has been mentioned several times, there may well be legacy devices still operating but for most devices "we don't care about being able to talk to them".
> If you make this (no IPv4 devices) a pre-condition of setting the flag then it's highly unlikely that you'll ever set it given how many of them there are.
> 
> Secondly, an IPv6 only router won't know if there are any IPv4 devices there.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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