Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Mon, 23 May 2011 21:56 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
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 43F88E06E7 for <ipv6@ietfa.amsl.com>; Mon, 23 May 2011 14:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXh5zHBElvbZ for <ipv6@ietfa.amsl.com>; Mon, 23 May 2011 14:56:40 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5076FE069C for <ipv6@ietf.org>; Mon, 23 May 2011 14:56:40 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1QOd73-00028L-80; Tue, 24 May 2011 07:26:33 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 776E63B338; Tue, 24 May 2011 07:26:32 +0930 (CST)
Date: Tue, 24 May 2011 07:26:31 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Message-ID: <20110524072631.737ee12c@opy.nosense.org>
In-Reply-To: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com>
References: <C9F53B85.11BE93%john_brzozowski@cable.comcast.com> <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <BANLkTinByCkcvd6=wLE6=9h1xLX16AhPVQ@mail.gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
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: Mon, 23 May 2011 21:56:41 -0000

Hi Thomas,

On Mon, 23 May 2011 17:11:28 -0400
Thomas Narten <narten@us.ibm.com> wrote:

> Christopher Morrow <christopher.morrow@gmail.com> writes:
> 
> > one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6
> > is on-net, but require full config from a dhcpv6 server".
> > How does a host know that v6 is available otherwise? (this may be why
> > someone said "you don't really want to do that..')
> 
> Well, if I could go back in time, I would never have defined the M&O
> bits at all.
> 
> Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use
> whatever is available. That would have been simple and
> predictable. (And avoided 10GB of mailing list discussion!)
> 

What if both are available, accidentally or intentionally (due to
misunderstanding that it should be one or the other)? Conflict
resolution in these sorts of situations isn't always simple and
predictable. You've now got twice as many things to configure
correctly, and at least twice as many things to troubleshoot if they
don't work.

I'd think either leaving the status quo, or dumping one of them, and
adding the features to the remaining one to make it the functionally
equivalent to the dumped one would be a better thing to do at this time.

I'm not particularly pro-SLAAC, however I sit back and wonder what is
missing from it that makes DHCP essential? It seems to me that the
functional reason people want DHCP is that they think it will track
address use - but it won't if end-nodes are manually assigned static
addresses. SLAAC won't prevent that either - so both SLAAC and DHCP
aren't adequate if your goal is to track address use. In other words,
its a problem that neither of them adequately address and have tried to
address.

> (Hmm, maybe I should just write such a spec now, given the M&O bit
> definitions are in the twilight zone anyway... Discussion of what to
> do with them was effectively removed from the last revisions of the
> SLAAC documents, so now there is no clear guidance on how to process
> them. The IETF at its finest...)
> 

I'm a bit confused, I find this text in RFC4862 quite clear as to what
to do -

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

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.



About the only thing I'd have changed in the above to make it more
clearer is to use the word "stateful" in the M section when referring to
DHCPv6 and "stateless" in the O section.

Regards,
Mark.