RA "requires" DHCPv6 ?

Karl Auer <kauer@biplane.com.au> Fri, 30 March 2012 22:57 UTC

Return-Path: <kauer@biplane.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BE21F84CE for <ipv6@ietfa.amsl.com>; Fri, 30 Mar 2012 15:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqFFA7YfiyNG for <ipv6@ietfa.amsl.com>; Fri, 30 Mar 2012 15:57:36 -0700 (PDT)
Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id AF25C21F84C4 for <ipv6@ietf.org>; Fri, 30 Mar 2012 15:57:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBABg6dk+WZX+7/2dsb2JhbAANNoVWtmeBMwJfE7UTigOPdIEYBKEWh3Q
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Mar 2012 09:27:32 +1030
Subject: RA "requires" DHCPv6 ?
From: Karl Auer <kauer@biplane.com.au>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bzpq7gKFbcl4zHthfzmw"
Date: Sat, 31 Mar 2012 09:57:28 +1100
Message-ID: <1333148248.2624.187.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 22:57:36 -0000

In a discussion titled "Stable privacy addresses (upcoming rev)",
Fernando Gont said:
> They could [...] have RAs require you to do DHCPv6 and then have
> DHCPv6 assign you a constant address, etc.

What interests me here is the phrase "have RAs require you to do DHCPv6".

When, if ever, are hosts "required" to obtain an address via DHCPv6?
When the "M" flag is set in an RA?

There was a bunch of stuff about the M and O flags in RFC2462, almost
all of which was removed in RFC4862. In RFC2462, the word
"should" (*not* capitalised) was used, along with phrases like "is to
be".

Then there is RFC 4861 (neighbor discovery) which says:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].
[...]
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.

Anyway, I've been working on the basis that the M and O flags are
advisory and not prescriptive. That is, they do not *require* the host
to do anything.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687