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

Fernando Gont <> Tue, 23 February 2016 11:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C6F241B2A53; Tue, 23 Feb 2016 03:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L7_8VTRMQazb; Tue, 23 Feb 2016 03:07:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6546D1AD362; Tue, 23 Feb 2016 03:07:22 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D2AB880DA8; Tue, 23 Feb 2016 12:07:15 +0100 (CET)
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
To: Christian Huitema <>, 'Lorenzo Colitti' <>
References: <> <> <003001d1687a$926ab2e0$b74018a0$> <> <> <> <> <> <> <019301d16e1d$979ed1d0$c6dc7570$>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 23 Feb 2016 08:06:25 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <019301d16e1d$979ed1d0$c6dc7570$>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:,, 'IETF Discussion' <>,,
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, 23 Feb 2016 11:07:24 -0000

On 02/23/2016 06:35 AM, Christian Huitema wrote:
> On Monday, February 22, 2016 4:36 PM, Lorenzo Colitti wrote:
>> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont
>> <> wrote: ...
>>> But the authors are making such statement here. i.e., if you are
>>> going to implement SLAAC/DHCPv6, then this statement affects
>>> your implementation. Hence, an appropriate tag should be included
>>> (i.e., such that if I look at RFC4862 or RFC3315, it's clear that
>>> I should look at this document, too).
>> I still don't see why this document needs to formally "updates: RFC
>> 4862" if it doesn't affect any > text in it.
> We actually had an extensive discussion on a related topic, whether
> to state that the document was "updating RFC 4361." We concluded that
> no, it wasn't, using precisely the test that Lorenzo mentions. The
> consensus was that an RFC can only update another one if it replaces
> some of the original text. You have to be able to say something like
> "in section X of RFC Y, replace the sentence so and so by this and
> that," or "add this paragraph."

Please see my response to Lorenzo.

Essentially, Lorenzo is saying that even if M=1, if you have a PIO with
A=1 you SHOULD do SLAAC and SHOULD NOT do DHCPv6. That's an update to
the existing specs.

Similarly, your text says:
    The choice between the stateful and stateless scenarios depends on
    flag and prefix options published by the "Router Advertisement"
    messages of local routers, as specified in [RFC4861].  When these
    options enable stateless address configuration hosts using the
    anonymity profile SHOULD choose it over stateful address
    configuration, because stateless configuration requires fewer	
    information disclosures than stateful configuration.

That's actually the contrary of what the specs say today: if M=1 you do
DHCPv6, not SLAAC.

I'm not arguing that what you propose is incorrect. I'm just saying
that, procedurally speaking, you're updating SLAAC. Hence your document
should have an appropriate "Update" tag, and note in the abstract the
specs it is updating.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492