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

Simon Hobson <linux@thehobsons.co.uk> Fri, 26 October 2018 22:13 UTC

Return-Path: <linux@thehobsons.co.uk>
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 AD802130E29 for <ipv6@ietfa.amsl.com>; Fri, 26 Oct 2018 15:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ttAFBHTMuXcL for <ipv6@ietfa.amsl.com>; Fri, 26 Oct 2018 15:13:12 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00658127148 for <ipv6@ietf.org>; Fri, 26 Oct 2018 15:13:11 -0700 (PDT)
X-Quarantine-ID: <RwHTBqZx0WXM>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <CA[...]
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 231CE1BC37 for <ipv6@ietf.org>; Fri, 26 Oct 2018 22:13:04 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <a3a2d823c38f44d48b301e2ca657e352@boeing.com>
Date: Fri, 26 Oct 2018 23:11:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EE067A5-3536-4EDD-80D9-D98783DE57CE@thehobsons.co.uk>
References: <CAFU7BASO_ByzbanhLKnWV280O_fASd-8W+ujpj3sN6d2-whw2w@mail.gmail.com> <CACWOCC-u7aAPwAOcixYvt2On=-o_8X25GhqdXTfA+tWRC1o2XA@mail.gmail.com> <3beca72e-19c5-10af-02e5-c21a90d77100@gmail.com> <20181019.223739.271916573.sthaug@nethelp.no> <4f58643c-272e-507e-3282-c87befd42395@gmail.com> <0927741c-4e8e-fcf7-ddd6-3ba500ba4c3d@si6networks.com> <7B48A11D-31DE-443C-B73A-14642EA0A397@jisc.ac.uk> <7526af75-4359-6fc6-e39b-eb94024a04de@si6networks.com> <E1BB1232-C1A2-496A-8157-0682D91EED42@steffann.nl> <5E75F3CA-F1D2-4F4F-9CF7-EEEE59634C1E@gmail.com> <C46C990E-0A4F-4731-8CB1-FD204858935E@consulintel.es> <9B53019C-3506-4C9E-AFCF-D6125FA1A65B@gmail.com> <1157b739-3a66-8d45-e3e1-e5f904dfb9bc@asgard.org> <a00607f9-7ced-f889-b5cb-c2fe16367d73@si6networks.com> <66759b73-0a22-e1a9-49db-21154e8e1267@gmail.com> <37ba23b3-df19-9c2a-bdbe-ba7a99d72d05@si6networks.com> <0d6008a4-337b-2ccb-2d9f-837f786eca65@gmail.com> <bfa4397a-aa7a-1184-4147-4cbfbfd13603@si6networks.com> <8C587906-F0EE-4A61-9046-2BF AC52588C0@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> <a3a2d823c38f44d48b301e2ca657e352@boeing.com>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/y6ZFF8TSzNT9yES4L7r5ALTzN6o>
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: Fri, 26 Oct 2018 22:13:15 -0000

Manfredi (US), Albert E <albert.e.manfredi@boeing.com> wrote:

> I will mostly assume that L2 filtering is NOT available, since that was stipulated as an extra obstacle. Your host device has a link to a destination. It tries to reach that link. Chances are, mDNS won’t have the address of any destination outside of this admin domain, but either way, a network which does not support IPv4 will not provide IPv4 addresses. No IPv4 address from mDNS or regular DNS, no further IPv4 attempt by the host device.

You've missed the fact that most nodes these days will autoconfigure a link-local IPv4 address. So "no address = no protocol" doesn't work. "no address (other than link-local) = no protocol" doesn't work either as it would break any network using link-local addressing - they do exist.

>> Desired result - on a network that is, by the subjective criteria decided on by the network operator/admin, IPv6 only; you disable IPv4 and don't try sending IPv4 packets.
> 
> Not even the flag will achieve this "desired result." As I said, IPv4 islands are always permissible (plug in your own switch(es)), and, you have no idea whether someone will plug in some older IPv4-only device. Only L2 filtering will truly disable IPv4 from the nodes controlled by the net admin. Having the hosts alone make that IPv6-only determination is, in fact, very close to the best you can do with a flag.

It's accepted that if devices ignore the flag then they can still play around in IPv4 link-local space - but that's not the intent of the flag. The flag is to inform nodes that IPv4 isn't supported on the network and so they can disable the protocol, saving battery (and probably memory) as well).

> Plus, it is possible to give the user a setting, such as many settings already are:
> 
> 1. Allow host to use IPv6 and IPv4 (recommended - default)
> 
> 2. Use only IPv6.

A setting for it is not practical for a number of reasons. Firstly, it will need to be changed when the user moves between different networks, secondly in most of the scenarios talked about, the user device is unknown to and the network operator and not managed by them. The aim is to be able to give the devices a flag which will **relliably** and **automatically** tell them that they can save the resources they'd otherwise expend on IPv4 operations.

I'm afraid I still see vague hand waving that implies trying stuff and if it doesn't work then adjusting stuff. That's either manual (yeah, forget that) or it's prone to problems. Apart from the acknowledged attack vector to IPv4 only networks, using an RA flag as suggested will be quite reliable and deterministic.