Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

Simon Hobson <linux@thehobsons.co.uk> Sun, 19 November 2017 10:59 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 936B11200CF for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 02:59:19 -0800 (PST)
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 Ets_91TYLRjy for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 02:59:18 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D01126B72 for <ipv6@ietf.org>; Sun, 19 Nov 2017 02:59:12 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9B3B31BC37 for <ipv6@ietf.org>; Sun, 19 Nov 2017 10:50:13 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <F26580ED-62B8-401F-83F7-882A26678454@consulintel.es>
Date: Sun, 19 Nov 2017 10:50:00 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A8CF860-375C-4EC8-84DE-D10945F9B1FC@thehobsons.co.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> <E838C63E-7612-4AA4-9375-854C184D699E@gmail.com> <CAFU7BAQKoWPcEFQZgU3k_d0gUL4en6d2pyNq1V4RMNZ6HrSG8w@mail.gmail.com> <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <CAN-Dau3o=YCRJi1PDdc=KeDn-n=CLyAKUdS-zj_dtWaUyHYY0w@mail.gmail.com> <F26580ED-62B8-401F-83F7-882A26678454@consulintel.es>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jEsSgpygomNE0OV9Txxsb6AF-4g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 19 Nov 2017 10:59:19 -0000

JORDI PALET MARTINEZ <jordi.palet@consulintel.es>; wrote:

> Agree with your analysis, but the problem I see is that many WiFi networks are very simple, even with high level of congestion, and they may not be able to apply such simple filters. Even home networks may have the same issues.

I would suggest that the sort of network (ie one aimed as very high user-counts) where the traffic is a real issue are also the sort of network running on "higher end" kit with the capability required, and run by people who understand the issues. For home networks, it's not going to be a real issue - other than in high-density situations (apartment blocks) where just things like 2.4GHz band congestion is already an issue.

> One way or the other, hosts get updated frequently

Not completely. See my post in the other thread, there's a lot of legacy stuff around. OK, Windows XP and WiFi in a sports stadium isn't going to be a significant issue, but a lot of users do not upgrade their phones every year or two - I'm only on my second in 2 decades ! And for older models, manufacturers have a tendency to simply abandon them so they won't get updates - for "older", this can mean "sold last month" if some of the anecdotes are correct.

> , but switches, APs and L2 infrastructure don’t, even CEs or small routers in many hotspots don’t get updated.

Again, I would suggest that where it matters, they'll get updated. If the operator sees a lot of IPv4 traffic and it's impacting on network performance, then they have an incentive to do something about it.

> ... that automatically detects the lack of IPv4 support (trying to avoid fake DHCP servers), so they automatically stop sending any IPv4 traffic, or even using IPv4 link-local?

How ?
How do you differentiate between a network with a missing DHCP4 server and one that doesn't run IPv4 at all ? If you simply assume that "no DHCP4 == no IPv4" then all that automagical networking using IPv4 LL will break. So realistically you can only assume there's no IPv4 if explicitly told - which comes back to having to have a mechanism to tell, and update everything involved to know about it.

Probably the best that can be done by the client is to be "less aggressive" in trying to configure IPv4 when IPv6 is available and you don't seem to see IPv4 traffic from other nodes. That way, if a network does employ L2 filtering, nodes will reduce their IPv4 broadcast traffic - but it shouldn't impact anything else.
Don't forget that in the cases being discussed (high density networks), the network operators typically have zero control over the clients connecting.