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

Nick Hilliard <nick@foobar.org> Sun, 19 November 2017 14:25 UTC

Return-Path: <nick@foobar.org>
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 37391126DFF for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 06:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ck9HeX2zFbvz for <ipv6@ietfa.amsl.com>; Sun, 19 Nov 2017 06:25:12 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372D8124205 for <ipv6@ietf.org>; Sun, 19 Nov 2017 06:25:11 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAJDOunx007776 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Nov 2017 13:24:56 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A119443.2030108@foobar.org>
Date: Sun, 19 Nov 2017 14:25:07 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
CC: "Brian E. Carpenter" <brian.e.carpenter@gmail.com>, IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
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> <CAKD1Yr3WC+vwL_=0PeiJ_D85NqFVTCkb8c83x-ZtGhAbSELGMA@mail.gmail.com>
In-Reply-To: <CAKD1Yr3WC+vwL_=0PeiJ_D85NqFVTCkb8c83x-ZtGhAbSELGMA@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Uo5hb6asaJL939zPppTTDrQ0cSU>
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 14:25:14 -0000

Lorenzo Colitti wrote:
> Let's not forget about battery life. According to the numbers in RFC
> 7772, on a phone even just sending DHCPv4 packets every 2 minutes could
> reduce battery life by ~8% compared to a completely idle device.

is there any guarantee in this situation that any other apps would not
be chattering in the background over ipv6 anyway?  From what I've seen
on tcpdump, mobile phones tend to be extraordinarily noisy, and a dhcpv4
packet every two minutes would, in any situation where I've examined
mobile phone traffic from normal handsets, be nothing more than
background noise.

Also, the whole internet isn't a mobile phone network, and what might be
relevant or appropriate on a cell network might not be in any way
relevant to another type of network.  Without meaning to state the
obvious, it would be important to take this into account when framing
any problem statement.

One relatively straightforward way of dealing with extraneous dhcpv4
packets would be to create a new dhcpv4 reply option hinting to the
requester to cease DHCPv4 requests on the interface in question, or to
slow down the request rate from one every two minutes to one every X
minutes where X is network defined.

Nick