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

神明達哉 <> Tue, 23 February 2016 17:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6500B1B3150; Tue, 23 Feb 2016 09:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tlfjdnvyWr1y; Tue, 23 Feb 2016 09:35:56 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFD251ACD4E; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
Received: by with SMTP id 9so222707233iom.1; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FspTmB5v9nZFuhcXEONehE8PoJ2fvxkxQDM8LcZcUgw=; b=kq/1+ej9phS1klIjbs0pgnxYJUg8TWlMMybH6b/IOM6xbdhqwLs6UOdCtkFYAis+tJ dx4hEOhWlBlgYXGTZp5ab7FIFgkNlhi5A6sFdOQ6eylwwrN+Go67+pzzEqPmUKPQjHSr rzd8seOfpsZbBqOQyyrYpsKPmMSg6DPrzS/zeu+nx7yScvYoxVpL6Sipu9QWaXJxYPAI UCe/YQYNG49DPQq6OxBNW5sA8CIX8/uuW1opRFiZ3Y1ET9468SycCFz00FKQ1C2ZHEE8 Puaxu2qsZwFvQ6+b/zdC+vbpqBL7s1Y9WiqhjaSyI3Gcu+xCMt5X0qTsrN4JwSSwDTmU ZaGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FspTmB5v9nZFuhcXEONehE8PoJ2fvxkxQDM8LcZcUgw=; b=U4pGEntaijDFzU4DwElFza5JBOltpnhzFj9DOzSEu3JcMHHzKEH0B5/IrH8FgWkw2s 2bD8s/KQOLPnjLdaBhQiNSVOLpx8JR3RLSDxfixetrf49ixTCsjVwjwJ6t7uoO56pqgH u6B+kkZBQmOoAkJOZv0pwqWPuSYoYmjf7BFenN8lsF5bQCB1B40OxIiOY6usWNhr9Njb IGg5AcaKGCBBHjlqHYDCpz300Xga5dudiOtuLDjM5UwGFdei5t9/626ARm4XTiqI5qLG yJnaWBzjX4k8DPaC1N+OhMS8ImXlwg/XmDS4oHHjAtRn6ZDhJcldlFvwlZzSmQAdX8ye NxZw==
X-Gm-Message-State: AG10YORa7Aya95wtJLiwZfpAk/Q+ix8/S83L6OvYkHghLwxPItGBj3xd28yOJiSuJccaM5n22Usg3swvg/JCEA==
MIME-Version: 1.0
X-Received: by with SMTP id t14mr38546191ioi.172.1456248955428; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
Received: by with HTTP; Tue, 23 Feb 2016 09:35:55 -0800 (PST)
In-Reply-To: <EMEW3|2f1684467327348fadd8e3176ed6f3eas1MCo503tjc||>
References: <> <> <003001d1687a$926ab2e0$b74018a0$> <> <> <> <> <> <> <019301d16e1d$979ed1d0$c6dc7570$> <> <> <> <EMEW3|2f1684467327348fadd8e3176ed6f3eas1MCo503tjc||>
Date: Tue, 23 Feb 2016 09:35:55 -0800
X-Google-Sender-Auth: IYfZKK89EQyZkWzrkzpNwTS9IKA
Message-ID: <>
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
To: Tim Chown <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Approved-At: Wed, 24 Feb 2016 10:38:16 -0800
Cc: IETF Discussion <>,, Christian Huitema <>, The IESG <>,, "" <>, Lorenzo Colitti <>
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 17:35:57 -0000

At Tue, 23 Feb 2016 12:50:01 +0000,
Tim Chown <> wrote:

> > That's actually the contrary of what the specs say today: if M=1 you do
> > DHCPv6, not SLAAC.
> >
> > I don't see any statement in 4861 that says that. Per 4861, M=1 means "DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:
> >
> >       M              1-bit "Managed address configuration" flag.  When
> >                      set, it indicates that addresses are available via
> >                      Dynamic Host Configuration Protocol [DHCPv6]
> I agree. It’s always just been a hint, no more, no less. And it’s been discussed many times...

+1.  I understand it may look subtle and could be confusing probably
because it was a kind of compromise as we could reach consensus on how
M/A flags should actually work.  But, however it looks, I'm pretty
sure that the intent of RFC4861 is that we do NOT say "if M=1 you do
DHCPv6", and that was intentional.  Let alone RFC4862 (for which I
happen to be a document editor): it even removed references to the M/O

   o  Removed the text regarding the M and O flags, considering the
      maturity of implementations and operational experiences.
      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
      that this change does not mean the use of these flags is

As such, I don't see the need for adding the "update: RFC 4682" mark
because of the proposed text.  (I don't have a particular opinion on
the text itself, btw).

JINMEI, Tatuya