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

David Farmer <farmer@umn.edu> Sat, 18 November 2017 22:07 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 B01AF1243FE for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 14:07:08 -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 o7CP_AJtXP9L for <ipv6@ietfa.amsl.com>; Sat, 18 Nov 2017 14:07:07 -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 D045A1200B9 for <ipv6@ietf.org>; Sat, 18 Nov 2017 14:07:06 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 1816D5F5 for <ipv6@ietf.org>; Sat, 18 Nov 2017 22:07:06 +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 ljIXthkBV3DB for <ipv6@ietf.org>; Sat, 18 Nov 2017 16:07:05 -0600 (CST)
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (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 78249239 for <ipv6@ietf.org>; Sat, 18 Nov 2017 16:07:05 -0600 (CST)
Received: by mail-lf0-f70.google.com with SMTP id g35so1293967lfi.0 for <ipv6@ietf.org>; Sat, 18 Nov 2017 14:07:05 -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=sycw35sYF2O303ESTNcz96zRB6unjGCfbwzQ6yMV/js=; b=BvnkwBkQS2F1pn2DmGbvy5iNAwIiMKxi0fxeDXk+Q9Ma/4+xRzqbVbA6/LfF8rZhCe 9VvhcvmKVtCCzuo1AU0ew7717jGs29XuhHhjI2rYYw/4YiQ9Xq9uaNSVG0QnovdDV/ZZ xpXXMlz4E7YVwKO1Y9zQZTpeOkK8jZ9l42QgABVwiv3xNJbYaqZY8Jx+4lAXaTkeCgV5 MdYuDStEdBuLzF7GAELpoxQFmwR+tBAw90/UlSIDy1zCLykIKZHMfW/FR8bJvyAr+6y9 6FhuscIN5ks4HNuwhnR7BUTJMCb+zkwBnFrz6vT6iyTfDW2t/7RzW3rRI5XvuBSUyS5X 46yw==
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=sycw35sYF2O303ESTNcz96zRB6unjGCfbwzQ6yMV/js=; b=boUdhQNJ1tkcRFQwJ/CZ7gS2RXsfm2pZ7kHbQSHDB+3w7YLJ0Bn2ffzNXw/uM9nufd Qa6jVpK4qXN0Y1l/+Xfg7BvoJf966SlklW0p8ReZNG3iHwKMFsMfXdtsQNRrdJnACmW1 qW80o+MNIUZ0wwXG6Hqs0GR8wQQFy/jLItPpWJpqPgo745gyTY4UDJ+VUHtN+S/ta9vH 2BiP+YFtn34O6jQ9AchqnOO4zzsTkuTkI8HobiyFDSbEYF4eSvXtE/xIvxJydK0USbiI B94zxDmX3GLtq+nyXVUnoE0Y2n0MutUa2tOw8kuvjWrVsvqZsrcWPDl0iZOk4PwiAQNx 1NPg==
X-Gm-Message-State: AJaThX4F/5CdrSSYn6quXFKzh61IDD+cmX1HkZklOUObqCTmFdihg/g2 bFAz+TXLyEi20S5dlEz2Xx6vV1H3fZx/tl9+9VEIhZ96POu3HvWTinM0s7sMSMPMBXhe9oeRfJm qly8SUKxTBHTSCHTGkmOorVEL
X-Received: by 10.46.20.83 with SMTP id 19mr2626669lju.23.1511042823925; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
X-Google-Smtp-Source: AGs4zMYS4YvHCJLZbfiz75GrCC676zuH6o9Vjg8dDGzW4123QnJIqSGJfbsp7N5uBiGC+BAGCaBqn6F8xpIqha0Gt8c=
X-Received: by 10.46.20.83 with SMTP id 19mr2626663lju.23.1511042823639; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
In-Reply-To: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
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>
From: David Farmer <farmer@umn.edu>
Date: Sat, 18 Nov 2017 16:07:03 -0600
Message-ID: <CAN-Dau3o=YCRJi1PDdc=KeDn-n=CLyAKUdS-zj_dtWaUyHYY0w@mail.gmail.com>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="f403045fb998be6b90055e491201"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GkZy6kkybdlt6nXZ_HPluHyZDy0>
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: Sat, 18 Nov 2017 22:07:09 -0000

On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com>; wrote:

>
> Regards
>    Brian Carpenter
>
> On 19/11/2017 03:39, Jen Linkova wrote:
> > Hi Bob,
> >
> > To be honest I'm not convinced that there is a real problem to be
> solved..
> > The draft says
> >
> > 'A mechanism is needed  to inform hosts that there is no IPv4 support
> > and that they should turn off IPv4.'
> > and it would be great to have more detailed problem statement IMHO...
>
> Indeed. If there is no serious problem, don't fix. What I seemed to hear
> in Singapore was that people weren't happy with just ignoring the small
> amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
> by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
> traffic, which is more of a burden for the infrastructure. We need to
> decide
> whether we care.
>
> (As to whether this belongs in 6man or sunset4, that's a secondary
> question.
> As for the other comments on this thread, I am too jet lagged to respond
> right now... later.)
>
>      Brian
>

Here is some analysis of the issues as I see them, hopefully this can help
lead us toward a problem statement;

I believe there are two separate issues here;

1. Security exposure; the inverse of the problems discussed in RFC7123,
basically malicious or accidental IPv4 service.
2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
IPv4-LL, ARP, service discovery, etc...

There are several solutions available already;

A. Filter Ethertypes 0x0800 and 0x806 altogether
B. Rogue DHCP server filtering or DHCP snooping
C. Proxy ARP
D. Service Discovery Proxy or Filtering

How much of an actual problem the issues are and the efficacy of solutions
depends on the type of network technology and the environment its used in;

For wired networks, the residual IPv4 traffic, even the fact that it's
mostly broadcast, isn't a significant issue.  The primary problem in here
is the security exposure, and solution B is usually sufficient protection,
but if that isn't, solution A will totally eliminate this risk.

For WiFi networks it's a little more complicate; low density WiFi
environments are similar to wired networks, the primary issue being the
security exposure, with the same solutions, discussed above. However, there
is an additional secondary issue, the residual IPv4 broadcast traffic could
unnecessarily impact other devices, especially battery powered devices.
Frequently, at least in enterprise WiFi networks, solutions C and D are
implemented to reduce the impact of IPv4 broadcast traffic in operational
WiFi networks, they will have the same effect on the residual IPv4
broadcast traffic in this case.  But, again solution A implemented within
the WiFi network will totally eliminate both the security exposure and the
impact of broadcast traffic on other devices.

However, the residual IPv4 traffic still consumes radio airtime, even if
the WiFi network discards the traffic. In very high dentistry and therefore
typically congested WiFi environments this unnecessary traffic only
increase the over-the-air congestion. Furthermore, broadcast traffic in a
WiFi networks consume more airtime that comparable unicast traffic (worst
case as much as 300 times, but 10-50 times is very typical), increasing the
impact of the residual IPv4 traffic that is mostly broadcast. Only a
solution that keep hosts from generating the residual IPv4 traffic in the
first place can help reduce over-the-air congestion in these environments.

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 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================