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

Simon Hobson <> Sat, 18 November 2017 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE061124C27 for <>; Sat, 18 Nov 2017 12:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rb1oCKP4geJ2 for <>; Sat, 18 Nov 2017 12:39:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1ECD01200FC for <>; Sat, 18 Nov 2017 12:39:00 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at
Received: from simons-macbookpro.lan (unknown []) by (Postfix) with ESMTPSA id A45AC1BC37 for <>; Sat, 18 Nov 2017 20:38:11 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
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 <>
In-Reply-To: <>
Date: Sat, 18 Nov 2017 20:37:59 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.1510)
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Nov 2017 20:39:02 -0000

Brian E Carpenter <> wrote:

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

On that basis, isn't the simplest and most compatible (in that it doesn't need any systems to be updated to support it*) to configure filters in the infrastructure as already suggested ?

> On 19/11/2017 03:39, Jen Linkova wrote:
>> If the problem is 'IPv4 broadcast noise on the link' then it should be
>> solved on L2 level and the network should not switch ethertype 0x0800.
>> If the problem is 'all those noisy DHCPv4 requests the first-hop
>> router has to drop because DHCP relay is not configured' then the
>> router interface should not accept IPv4 packets at all, problem
>> solved.

* The only requirement is that the infrastructure (APs, switches, routers) have the facility. And all this is in the hands of the network operator regardless of the nature of the clients connecting though it.