Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard

Lorenzo Colitti <> Tue, 16 February 2016 02:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D4FE1B32FF for <>; Mon, 15 Feb 2016 18:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Slv6g1_ocpyd for <>; Mon, 15 Feb 2016 18:53:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 732D81B32F8 for <>; Mon, 15 Feb 2016 18:53:28 -0800 (PST)
Received: by with SMTP id u200so129325394ywf.0 for <>; Mon, 15 Feb 2016 18:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k6L0NH//M3KxeDYYDrEOh2kZfIG7akiGUFoAj1JBlBM=; b=OcvjKj5GRFC4JdJz7CwFtiX32c02ssAj4cfOSN+tO8TMATNlMcXZDVfv82LKsFQbVB 4HZENzFvTMsFB+6d6cGEBVfSuwNHJFlGmmUO6Rp5metn9rnKnHLBtNoSxxFwafMviC4c ERbz281eCZi6SLvqDneEYbXijPKRn7jPlvR0buPQHNTGKYeUp1+ba9E4BAeXG3Fzen84 U0DMjtrpQhR1z5Tat0+l6HdNQdwof3fy5Es8iGxO8hFS3+qTi8N0cwNVGU5n1I3e1nNl HpNycJJwAXi5rCjIZqm/TfqVVTIYndKT9uIDBFBgsRCKM/NQJTAZsK+UQ4MnJS5SmIDZ uPcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k6L0NH//M3KxeDYYDrEOh2kZfIG7akiGUFoAj1JBlBM=; b=brPT66N1BoH3qMBfeAES/J2wFTuASH7a1NJ1HiXv4PDbwWOHqjMV0HjZ0eUYnNFpp+ eQhZQyezXcKVdfTSMZi2NIjZAOLUOiq/txf8/Duubrfh/WHArEoeZoli0Upa9V0nw3sb JcxjyO0XfVI2+/OjbVSzCOtZ8KC2tQQjjK+l++lbe4f7KT8XJZ4Svs5adwrDuXLmPxpU 6PtkarXMuxyg3empFynpWmHD1Nn5kFjpsw1rgafMSPVX4ATLe7BdVYjrB4M2Dv7T+g1c nVCxbhbwq1wPSuTs3Hv8pkhmz6sHaij/VINjNWCCbJv4eV7TIR0bn991o1MN6BwPH/mv K+lw==
X-Gm-Message-State: AG10YOQIhkICyIYfc8eRVqWdcsgcR0q7fFXxik+Kl0ry0bX431Yxjr9d0qg8P2sunlAE+71j7i3u0Oi+tgsm18eM
X-Received: by with SMTP id u204mr10771488ywb.307.1455591207573; Mon, 15 Feb 2016 18:53:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 15 Feb 2016 18:53:07 -0800 (PST)
In-Reply-To: <>
References: <>
From: Lorenzo Colitti <>
Date: Tue, 16 Feb 2016 11:53:07 +0900
Message-ID: <>
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
To: IETF Discussion <>
Content-Type: multipart/alternative; boundary=001a114926e8de2c0b052bda3c0a
Archived-At: <>
Cc:, "" <>,,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Feb 2016 02:53:31 -0000

On Mon, Feb 1, 2016 at 11:24 PM, The IESG <> wrote:

> The IESG has received a request from the Dynamic Host Configuration WG
> (dhc) to consider the following document:
> - 'Anonymity profile for DHCP clients'
>   <draft-ietf-dhc-anonymity-profile-06.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2016-02-15.

Christian et al., thanks for taking on this work. But I think an important
point here is missing.

It seems to me that fundamental design of DHCP relies on the client blindly
broadcasting information to anyone that happens to be on link, or on the
path between relay and server. This information is both explicit - e.g.,
previous IP addresses assigned, hostnames, etc. - and implicit - e.g., via
implementation behaviour and unique combinations of options.

It's true that this profile mitigates the amount of information that can be
collected. But in IPv6 we have other configuration methods - such as SLAAC
- that broadcast way less information than stateless DHCPv6, which in turn
broadcasts less information than stateless DHCPv6.

This document should recognize that at least on IPv6-only networks, it is
an option not to use DHCP at all, and that option has substantial privacy
benefits that are in many cases above what this profile can provide.