Re: IPv4 traffic on "ietf-v6ONLY"

David Farmer <farmer@umn.edu> Thu, 16 November 2017 00:39 UTC

Return-Path: <farmer@umn.edu>
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 E06E3120721 for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 16:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 jxWi-rIPQVnE for <ipv6@ietfa.amsl.com>; Wed, 15 Nov 2017 16:39:44 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1B0120227 for <ipv6@ietf.org>; Wed, 15 Nov 2017 16:39:44 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id E732957A for <ipv6@ietf.org>; Thu, 16 Nov 2017 00:39:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUR8u5i_ZLSR for <ipv6@ietf.org>; Wed, 15 Nov 2017 18:39:43 -0600 (CST)
Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 79FDB86A for <ipv6@ietf.org>; Wed, 15 Nov 2017 18:39:43 -0600 (CST)
Received: by mail-lf0-f69.google.com with SMTP id y85so3664122lfk.15 for <ipv6@ietf.org>; Wed, 15 Nov 2017 16:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v02luK29UbZnvF7CIOEKdETb5ZIpiEF09roD6kYGqQI=; b=TN5rWxvy7piwdmA6duJdGlTgtNZac8Kc2u6zw2ygstsdDL/J6qANa1AwQQh/Mz6Q1S D2ZVK0iaTuc1UKwciyk4dxbOShVFPvOoxJeCA6FRw7S8QaHgdGgX/+R6fMegu65/fKFS bBaXb+hdhCa+EA59HK8rYmoy3YqcpD+5zxru4NGi4/gv59SsJCR721bXLlEtJMjzD/uT rC6E8oed/K0o+BuIauFIvrgaxh3jSKhfndvyUeMz/3iktigrpt+p0Rg5vMW7q215CTr3 Xq8cjES69cvMy4jTaaqm6wTYtx00drNiHG0PZSYOwqImKQrjiW6k6QvKeHLfptSZTzcm MZEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v02luK29UbZnvF7CIOEKdETb5ZIpiEF09roD6kYGqQI=; b=ftGutYVK2Wqym9UZjxYGdsWfK/qBdO1bWEmcob2C4+DIYpX9fCqUv/+QYdRfBmQK/k w6Z+kyM5EC9imPrL0jGfF+BpZEZDR1jsDGxNOTyB7PuLEU3sVipAiIQ8f0pdbpqE4ayo bPtPF679Uvj8rniGseFVL9FChD6djC4wtn7QgTQIWC9yrV2vlqBo2pjsy8Agj6QcqsKg usbdgfAT4YzQeGDkpePS2ce08lKTujYJVmWhNqPkwojooSFKeP04YvJF2YdKeFqp2rmx LUHaqDJXGvtW1HNzZ7oqaI3mrwncBU8owu7Pmx5raszNgR2Cmzp3J0LbwmHdRmW4alCs LYUg==
X-Gm-Message-State: AJaThX5V7BMrK3A1VCzbiM8gN0UCt8glFxwZ7TLH74iml5Y/qZkSilux DiNs9JCOiNFxLItitgL8txkuQQQX+4f6v7dgidEuk6qfkwu6u+SaUvoSFhUWDYyGiTTUicNLixu /OMUDz7oryd3a5jONuYzTW+qT
X-Received: by 10.25.31.198 with SMTP id f189mr4157577lff.1.1510792782007; Wed, 15 Nov 2017 16:39:42 -0800 (PST)
X-Google-Smtp-Source: AGs4zMZ/kRUv7iuefF8FMibD2NGqNeJKaTlf9yzS1sCl9+vivSClV5aydB4uOn55WIiNwZnoPU6RZQCXTGUwY6kmbNU=
X-Received: by 10.25.31.198 with SMTP id f189mr4157573lff.1.1510792781742; Wed, 15 Nov 2017 16:39:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Wed, 15 Nov 2017 16:39:41 -0800 (PST)
In-Reply-To: <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>
References: <f9805855-68cf-a3e8-a13f-c6ac31b09058@gmail.com> <bbd4e1d2-047f-6758-76f8-fd591c51dad7@gmail.com> <D631CE54.8C0F5%lee@asgard.org> <m1eEvEP-0000G3C@stereo.hq.phicoh.net> <D75288D5-B571-46EB-A35E-0DBD79F930E5@google.com> <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Wed, 15 Nov 2017 18:39:41 -0600
Message-ID: <CAN-Dau3mVnTKqkzYWHa3qnTHWWcos=BXKgGfKsyD9ScWAB4obA@mail.gmail.com>
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a11403c0815da98055e0edb81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1UlqYq4Ufib5CSwC7udL1oIhZRM>
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: Thu, 16 Nov 2017 00:39:47 -0000

On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 16/11/2017 08:15, james woodyatt wrote:
> > On Nov 15, 2017, at 02:47, Philip Homburg <pch-ipv6-ietf-4@u-1.phicohcoh.
> com> wrote:
> >>
> >> The safest option to do that is a DHCPv4 option that says 'no IPv4
> service here, go away'.
> >
> >
> > Better: extend ARP with a signal that says, “ARP is not welcome here."
>
> However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
> That is a practical indication that this problem probably isn't worth
> solving.
>
> I submit for example that sending a new "not welcome" response to
> ARP requests would do more harm than good, since the legacy hosts
> would probably react badly.
>
>    Brian
>

I'd love to see some data to back up the conjecture, that is the "traffic
... is negligible and harmless"

I completely agree that "a new "not welcome" response to ARP requests would
do more harm than good."

The problem I see is that WiFi airtime is precious, and worse yet broadcast
packets (DHCPv4 discover and ARP) can use excessive airtime in some
situations, more than the fraction of the bits they represent would
indicate.  On a wired network I'm not all that worried, but on WiFi, I'd
like some data on the matter.

On enterprise WiFi, you could filter ethertypes 0x0800 and 0x0806 at the
AP, or they usually have DHCP and ARP proxies, either of which would
prevent sleeping devices from being pestered by the traffic.  However, the
traffic still consumes airtime and that's my concern, especially on large
congested WiFi networks, like at IETF.

Thanks.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================