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

Jen Linkova <> Mon, 20 November 2017 04:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85DA1126C22 for <>; Sun, 19 Nov 2017 20:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NV0GGOIFPuA9 for <>; Sun, 19 Nov 2017 20:17:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1EC7126579 for <>; Sun, 19 Nov 2017 20:17:11 -0800 (PST)
Received: by with SMTP id x68so8545256lff.0 for <>; Sun, 19 Nov 2017 20:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPq53zradKHuL/uTDM7IoE3T5aDOx9QVUFpqd4Bg5Gk=; b=bL81sRg7vp4eg9rL56WEEf8lgSFLjjtjnmj7wIAkHEuv7P/5SDSlP2RR6ngAXJm3DS kv4qOwmhIoTZpQ5rYg+/4e1QCxkYcYJftSGgk1TK8dJtbyxFJTCMv4RZ5UWQPTCNA1Ma 1/61eUEV+uC4do4P8PXgvBCfk0HQe+D4//VLKhEWhQgqaNbW5qv9zKrX9ijNKv+o8ye9 3PniuOk6ArYN0oSuB9Gw/VOmjx03eGCWsMOClQrua2lNJDOHsCPQsVTLrHmhlQmtr2PN GmRoW0eYXrpDeoUCXp1r+jDORcjLKyFVPn/xuDDc8Zafm1w9yjoNtvPNNec/XO/Z399v Aw6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPq53zradKHuL/uTDM7IoE3T5aDOx9QVUFpqd4Bg5Gk=; b=r4wESxQPhZeqJXKv8B8oIb9n4nyFHOb9GlEG/5PWF1NG7twAbDaGZO3RCB/luo97Ds nudfT4VygvN1Fbmr5QAwlC7hiGhKIR6gVydrq7FsADfxhzQHoTvjSBKCmVdalpw3L0c4 i8wmyHHYQ/ImT1XY99dpr0Y28dL4psXOv9YDdMCsJ1/sR+RTyn9IPtPS5p8dFNNrr9qI fyF5cmDQt9M8HJuG+jYGD8CGOOriDLGFJal7y/E7tmxw4/kiRd/jrsGvOfmU20idn8nB GgO9pQf8ItvvNZ3g0NxI0SbayManAPCupSb0yVz87cwrnYT92KpBLL6FljRSq0KoXn1H sgkw==
X-Gm-Message-State: AJaThX5hJRBTL9sAwAeDwzIZ6psO1KwH9FOjxWt+eF3VtqII/tROGYR8 9xf74YHZxq0bUZzP2p6WiZ6+RbKcoqXqDx7M4jwKEQ==
X-Google-Smtp-Source: AGs4zMa2D9XQzMLLy4YlqcrdDY84d+6aPwkjHsGOA3BEeh8d6K5iI22BUZNT44Me3tdjO1tGRWisP6id2Me92dCqA2k=
X-Received: by with SMTP id 17mr4169617ljc.67.1511151430093; Sun, 19 Nov 2017 20:17:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 19 Nov 2017 20:16:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Jen Linkova <>
Date: Mon, 20 Nov 2017 15:16:49 +1100
Message-ID: <>
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard <>
Cc: Lorenzo Colitti <>, IETF IPv6 Mailing List <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 20 Nov 2017 04:17:13 -0000

On Mon, Nov 20, 2017 at 1:25 AM, Nick Hilliard <> wrote:
> 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.

The idea of using a protocol X to tell device 'there is no protocol X
on this link' sounds very entertaining ;)
If I run a single-stack network I do not want to configure IPv4
addresses, dhcp relays etc on v6-only interfaces
and most likely I have no desire to run DHCPv4 for those segments. I
might not even allow v4 traffic on the link at all
(as it reduces the attack surface).

There are two unrelated things which could be done:
A) To protect the network from excessive amount of undesirable (v4)
traffic some actions need to be taken on the network level. Those
could not be completely delegated to hosts as most likely we are
talking about large number of devices, uncontrolled, potentially
outdated etc.
However the network indeed could provide some hints to hosts in case
those hosts are willing to listen. Here comes B)
B) To improve the device performance at v6-only network, the device
can do smth to detect the lack of IPv4 on the link (either explicitly,
like the RA flag we are discussing) or implicitly (no DHCPv4 replies
-> back-off etc).

SY, Jen Linkova aka Furry