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

Bob Hinden <bob.hinden@gmail.com> Fri, 26 October 2018 23:15 UTC

Return-Path: <bob.hinden@gmail.com>
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 4926A127148 for <ipv6@ietfa.amsl.com>; Fri, 26 Oct 2018 16:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 w7LdmQ-rjZow for <ipv6@ietfa.amsl.com>; Fri, 26 Oct 2018 16:15:11 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D48D12008A for <ipv6@ietf.org>; Fri, 26 Oct 2018 16:15:11 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id r64-v6so1222261pfb.13 for <ipv6@ietf.org>; Fri, 26 Oct 2018 16:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zyGY979AfT8fAdUSIExxgb0ybVl+Z6qlC5JriwTo4hI=; b=HCz3ZZE3YafI5KZkzqlY8JcsBUTnVouuo1Qx7Jw0n10aY1/dUdwoiGLJ/7ZnPMw3Ka MGLJXsxQPSyL9t0SWldSwdamJuQkcecv2aZkps8mMtaFgbgJmKcSnPMOsdWqFAVHOHnv 6md+xNx2UfQBcmv0+9eWGk5UflrmWWESlZ38celYXMkPgtT0n0qupOYJ96CfWODv2pZm +7B4A8c0Ycok+uwupAcC7gbdLUpohAiQN1QDwnT81WqW1QILBLusLi6pmYqPPVmyaIFU UqYuiShV10JxWOqZeFBUf32KcWC04sd8H2h0/eVx3nvfiHJzyCZ8sKLQdP7pQe+Tp9nB 36yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zyGY979AfT8fAdUSIExxgb0ybVl+Z6qlC5JriwTo4hI=; b=aV6RAwo8VpUg0C9tbnP/qaIFIuT6YRwr8y+KHKhsdRzdIEPu4eT4HEN6rD+7EQuyYy IRjjtPN1gQYLB7gaIu3WwvKfibMSsnD6dvcSeRK9Aq2uOcVSz8MGYZkxT3lPti/1pKUK tajKIBW9k+Q9pTKeIy7BcSzBlpvRZzQA0i+Bz3dfrQd04R38+iwijuTWUob+CRrtHr1q bR8pMHAbFcRICwI3CI8E9DNGk7aVoum471HBX7CHGTI8AQOKYwmcSYfugn7tpJ5flDof gj49M3y8WCuqY/hiJxXdJqZ4yP8XHCstyOZyDJgYfzH9ws2DKdDzsfjMSvXJ0Co4HXhH bcMg==
X-Gm-Message-State: AGRZ1gJzf2Qt3KLCS8y9LBVzVvQTDBtSzBAGyGZvTtC4EOa2OWUbO09r DEWxTsHIBxK4ZO6bcnKgb30=
X-Google-Smtp-Source: AJdET5dJ1mDFhfe+1wBa5unojOrZXt8vsuEwTFMvIUOWMgJbP1QdVNVuNkX++Zz3r7AxM5z7gw5vSg==
X-Received: by 2002:a65:6144:: with SMTP id o4-v6mr5308849pgv.387.1540595710784; Fri, 26 Oct 2018 16:15:10 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id m7-v6sm15545718pgq.59.2018.10.26.16.15.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Oct 2018 16:15:09 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <9E4F748E-9EED-499C-BAF1-F692209A2AAD@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4E54C924-52A8-4A00-9542-15D6263728C5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
Date: Fri, 26 Oct 2018 16:15:07 -0700
In-Reply-To: <6EE067A5-3536-4EDD-80D9-D98783DE57CE@thehobsons.co.uk>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
To: Simon Hobson <linux@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> <6EE067A5-3536-4EDD-80D9-D98783DE57CE@thehobsons.co.uk>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/T_itZupX2AzXFpGGOePpYc6oxFY>
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 23:15:13 -0000

Simon,

> On Oct 26, 2018, at 3:11 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:
> 
> 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).

That is the the intent of what the draft is designed to do.  I would add that it provides information from the administrator of the router.   From the draft:

   This document specifies a Router Advertisement Flag to indicate to
   hosts that the administrator has configured the router to advertise
   that the link is IPv6-Only.

> 
>> 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.

Agreed.

Bob


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