Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

["David W. Hankins" <David_Hankins at isc.org>]

On Fri, Oct 17, 2008 at 07:21:34AM -0400, Ralph Droms wrote:
> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
>
>   The M/O flags indicate the availability of DHCPv6 service for
>   address assignment and other configuration information,
>   respectively.  The IPv6 specifications make no requirements on the
>   behavior of DHCPv6 clients in response to the values of the M/O
>   flags received in RAs.

Yes.  I think it also suffices as a problem statement. :(

> 2. Does the IETF choose to continue to accept this consensus or should
> the definition of client behavior in response to the M/O flags be
> revisited?

It's not cleFrom ipv6-bounces at ietf.org  Fri Oct 17 09:59:59 2008
Return-Path: <ipv6-bounces at ietf.org>
X-Original-To: ipv6-archive at megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C39C328C0F7;
	Fri, 17 Oct 2008 09:59:59 -0700 (PDT)
X-Original-To: ipv6 at core3.amsl.com
Delivered-To: ipv6 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2C5793A6AD7;
	Fri, 17 Oct 2008 09:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Aw8uptA9nr+Z; Fri, 17 Oct 2008 09:49:29 -0700 (PDT)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148])
	by core3.amsl.com (Postfix) with ESMTP id 477183A6A8F;
	Fri, 17 Oct 2008 09:49:29 -0700 (PDT)
Received: from david.isc.org (c-24-6-53-214.hsd1.ca.comcast.net [24.6.53.214])
	(authenticated bits=0)
	by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id m9HGoXW6014881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO);
	Fri, 17 Oct 2008 09:50:33 -0700
Received: by david.isc.org (Postfix, from userid 10200)
	id 00C2516E1B3; Fri, 17 Oct 2008 09:50:32 -0700 (PDT)
Date: Fri, 17 Oct 2008 09:50:32 -0700
From: "David W. Hankins" <David_Hankins at isc.org>
To: DHC WG <dhcwg at ietf.org>
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
Message-ID: <20081017165032.GB5157 at isc.org>
References: <200809171517.m8HFHaaV009346 at cichlid.raleigh.ibm.com>
	<9A613C72-E818-410B-9769-8C34E8A78AE1 at cisco.com>
	<200810131540.m9DFeRGR009155 at rotala.raleigh.ibm.com>
	<BA6C47AC-1668-47CE-94D0-49C4F7A6775E at muada.com>
	<20081013163846.GA5577 at isc.org>
	<FA7A47C2-0935-4BA3-A0EF-EC1773B181A0 at muada.com>
	<20081014163236.GD5364 at isc.org>
	<F3BF1907-5B33-4B6E-9ED8-B5AF275134BE at muada.com>
	<A06D0544-B8C7-40F2-8D29-CF70FD0451CF at cisco.com>
	<B16AF664-5D38-47ED-9558-3AE9880714F6 at cisco.com>
MIME-Version: 1.0
In-Reply-To: <B16AF664-5D38-47ED-9558-3AE9880714F6 at cisco.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Mailman-Approved-At: Fri, 17 Oct 2008 09:59:58 -0700
Cc: IPV6 List Mailing <ipv6 at ietf.org>
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============15056193=="
Sender: ipv6-bounces at ietf.org
Errors-To: ipv6-bounces at ietf.org

On Fri, Oct 17, 2008 at 07:21:34AM -0400, Ralph Droms wrote:
> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
>
>   The M/O flags indicate the availability of DHCPv6 service for
>   address assignment and other configuration information,
>   respectively.  The IPv6 specifications make no requirements on the
>   behavior of DHCPv6 clients in response to the values of the M/O
>   flags received in RAs.

Yes.  I think it also suffices as a problem statement. :(

> 2. Does the IETF choose to continue to accept this consensus or should
> the definition of client behavior in response to the M/O flags be
> revisited?

It's not clear what ar what YES or NO mean in this context.  Yes to the
first and no to the second?  No to the first and yes to the second?

I think you mean by context only the first question.  Someone needs a
lesson in "simple english."

> 2. NO: How does the IETF want to change this consensus and how should the
> change process be conducted?

1) How _should_ it work?
2) How do we migrate?

3) Write it down in an RFC.

> * Deprecate the M/O flags; require that future DHCPv6 clients ignore
>   the M/O flags; require that routers send RAs with M/O flags set to 1

I'm not sure that specifying M/O fixed to 1 is worthwhile, but
generally the deprecation of the flags is the correct direction.


Because I type at 80wpm and can't be stopped:

There is a larger deficit in IPv6 single-stack operations that this
solution puts us on track towards addressing.  That deficit is today
filled in dual-stack networks by DHCPv4.  I am going to continue with
some "next work" items I believe are mandatory for IPv6 single-stack's
adoption;

1) PIO-equivalent information in DHCPv6 replies (even if prefix length
    is simpler for most implementations today).
2) Default gateway configuration in DHCPv6 replies.
3) Deprecation of RA, at the same time:
4) DHCPv6 rapid-commit support (from Solicit to a Reply) which
    includes;
  a) PIO-equivalents.
  b) An indication for the client to commence SLAAC, and transition to
      Information-Request for configuration ("NoAddrsAvail" in any
      IA_NA, or similar (explicit perhaps) mechanism).

This would cause there to exist a single protocol which RA/DHCPv6
should have been from the very start (an equivalent approch is to
extend RS/RA so that RA is identical to a DHCPv6 Advertise, and
additional messages negotiate assigned addresses - I believe selecting
DHCPv6 and backporting SLAAC is more expedient).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

Attachment: pgp8QLLDvA9IT.pgp
Description: PGP signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------