RE: DHCPv6 address used when M or O bit is set

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Wed, 04 April 2012 22:58 UTC

Return-Path: <albert.e.manfredi@boeing.com>
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 1A20511E80C5 for <ipv6@ietfa.amsl.com>; Wed, 4 Apr 2012 15:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8]
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 2S7RAdLJss4Q for <ipv6@ietfa.amsl.com>; Wed, 4 Apr 2012 15:58:48 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 327FF11E808C for <ipv6@ietf.org>; Wed, 4 Apr 2012 15:58:48 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q34N080X022204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2012 18:00:10 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q34Mx0vq021113; Wed, 4 Apr 2012 17:59:00 -0500 (CDT)
Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q34Mx0Vl021108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 4 Apr 2012 17:59:00 -0500 (CDT)
Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-02.mw.nos.boeing.com ([134.57.113.20]) with mapi; Wed, 4 Apr 2012 17:58:29 -0500
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Karl Auer <kauer@biplane.com.au>, "ipv6@ietf.org" <ipv6@ietf.org>
Date: Wed, 4 Apr 2012 17:58:27 -0500
Subject: RE: DHCPv6 address used when M or O bit is set
Thread-Topic: DHCPv6 address used when M or O bit is set
Thread-Index: Ac0StCvDtFd14Uc3R2W4TpPMOgTY6AAAioUg
Message-ID: <B0147C3DD45E42478038FC347CCB65FE02BB701A1F@XCH-MW-08V.mw.nos.boeing.com>
References: <CAAVMDnVNUaXBwi5cU87+0PkB71kdT+e4BaLUW7Ai39hCWitUrw@mail.gmail.com> <4F7C56BE.6010507@si6networks.com> <1333579298.11943.532.camel@karl>
In-Reply-To: <1333579298.11943.532.camel@karl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 04 Apr 2012 22:58:49 -0000

Can we vote to have your interpretation pasted into RFC 4862bis?

Honestly, that I get, at least.

Bert

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Karl Auer
Sent: Wednesday, April 04, 2012 6:42 PM
To: ipv6@ietf.org
Subject: Re: DHCPv6 address used when M or O bit is set

On Wed, 2012-04-04 at 16:12 +0200, Fernando Gont wrote:
> I'm curious about why the corresponding text was removed. In particular
> when at the time (2007) the DNS options was not yet widely implemented,
> and hence you *needed* DHCPv6 to learn the addresses of recursive DNS
> servers dynamically.

Me too!

The RFC4862 says

   "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
    deprecated.)"

The only way I can interpret this is "people are doing whatever the hell
they like with these flags, and some of those implementations are pretty
well-established, so we are not going to try to define how the flags
should be used because no matter what we say, it will conflict with the
way someone out there is doing things. However, people should definitely
still use these flags! We aren't taking them away, we're just refusing
to define how they should be used."

It seems a strange thing to say, so maybe my interpretation is wrong :-)

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