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

Toerless Eckert <tte@cs.fau.de> Tue, 30 October 2018 18:34 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 D5504130E1C for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 11:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level:
X-Spam-Status: No, score=-3.952 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] 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 Yom4-kqrU6LY for <ipv6@ietfa.amsl.com>; Tue, 30 Oct 2018 11:34:22 -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 43802130E02 for <ipv6@ietf.org>; Tue, 30 Oct 2018 11:34:21 -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 E20AB548004; Tue, 30 Oct 2018 19:34:16 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D31C1440210; Tue, 30 Oct 2018 19:34:16 +0100 (CET)
Date: Tue, 30 Oct 2018 19:34:16 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Message-ID: <20181030183416.wfv47m63w5xk3cqe@faui48f.informatik.uni-erlangen.de>
References: <0d6008a4-337b-2ccb-2d9f-837f786eca65@gmail.com> <bfa4397a-aa7a-1184-4147-4cbfbfd13603@si6networks.com> <8C587906-F0EE-4A61-9046-2BFAC52588C0@isc.org> <E8DE18B5-94FC-411C-A310-E49A382E0079@thehobsons.co.uk> <e0fa8fad1b4249c9af79788323b0a922@boeing.com> <3A03A073-72E2-43A8-90A4-5C29DF445361@thehobsons.co.uk> <27fdbd71125842d888c5136684bf6e7b@boeing.com> <9A4368D6-E4B1-474C-9838-B584AF6D70C8@thehobsons.co.uk> <m1gHUMI-0000I6C@stereo.hq.phicoh.net> <acb0984ec73b40c9a350a0d144b23835@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <acb0984ec73b40c9a350a0d144b23835@boeing.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/D0Ag6wKevT-4XVCpfhPARf_8tZQ>
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, 30 Oct 2018 18:34:30 -0000

On Tue, Oct 30, 2018 at 05:56:08PM +0000, Manfredi (US), Albert E wrote:
> DNS in IPv4 format might be a good hint too.

Example ?
> From my standpoint, I have yet to see anything that the flag adds, that can't be done just as well, and less ambiguously, with heuristics. I'd like to see one scenario that the flag resolves, that can't be done otherwise. But this should be a good thing. It puts the onus on the people who are responsible. The responsibility of saving power should be on the guy designing that box, not on a net admin, who has his own interests.

Depends a bit on how the flag is refined:

If as i suggested the flag really means to trust IPv6 routers more than
IPv4 routers (aka: don't do IPv4 even if some IPv4 router tells provides
DHCP addresses), then it would be an explicit mechanism for IPv6 to
superceed IPv4. I would support that interpretation on the rough
estimate on my side that it simplifies policies and evolution. Without
that interpretation, you have more complex policies whom to trust
in an automatic way.

The second interpretation is vs. this means to just not even try to
do DHCP to get global IPv4 addressing/router, or whether it means
to not do IPv4 at all, including no link-local multicast. IMHO both
options are valid and would best be indicated through two separate
flags.

I think with just a single flag, the best value and distinction would be
had if the interpretation is a) Trust these IPv6 announcement more than
any IPv4 you see, and b) do not do any IPv4 at all, including no
ipv4 link-local

I don't think there is any way to achieve complete disablement of
ipv4 operations automatically without using some additional signaling
across non-IPv4. I think it would be cleaner to do this signaling at L2,
but given the overhead/politics of anything like that with IEEE, i think
its fine to have this signaling in IPv6. I don't think there is any
simpler/better way than at least one such flag.

As also mentioned, i would prefer to also have mechanisms described by
which routers would automatically determine whether to set this flag.

Cheers
    Toerless

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