Re: [v6ops] M/O flags and PD

Tore Anderson <tore@fud.no> Sat, 31 October 2015 08:46 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902271A036F for <v6ops@ietfa.amsl.com>; Sat, 31 Oct 2015 01:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMcFl3vjgQq for <v6ops@ietfa.amsl.com>; Sat, 31 Oct 2015 01:46:29 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DDF1B2B2F for <v6ops@ietf.org>; Sat, 31 Oct 2015 01:46:29 -0700 (PDT)
Received: from [2a02:fe0:c410:d92::8b1] (port=38511 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1ZsRnq-0005tP-H4; Sat, 31 Oct 2015 09:46:22 +0100
Date: Sat, 31 Oct 2015 09:46:21 +0100
From: Tore Anderson <tore@fud.no>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <20151031094621.182c6c50@envy.fud.no>
In-Reply-To: <5633C030.6040202@gmail.com>
References: <20151019195001.22760.2580.idtracker@ietfa.amsl.com> <5AB28826-8E45-461F-AA7B-5D45F218FC18@cisco.com> <20151028113851.530c649d@echo.ms.redpill-linpro.com> <CAJE_bqd1263SaqU61sqqk_4Tne1GzE4_kMUhuLMgY42Cyc6m_A@mail.gmail.com> <5631232E.4020701@gmail.com> <20151029203951.06a4d4fd@envy.fud.no> <39B7C63D-A31A-4F3D-8487-5A9FF917F939@employees.org> <20151030075849.5ad90ed6@echo.ms.redpill-linpro.com> <20151030073854.GZ70452@Space.Net> <20151030091055.2b050875@echo.ms.redpill-linpro.com> <38EF67B7-1293-4565-83D8-9AD4E2A7DC5C@steffann.nl> <5633C030.6040202@gmail.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/gBW_QqFsKucarWMnXa9zHxXZc88>
Cc: jinmei@wide.ad.jp
Subject: Re: [v6ops] M/O flags and PD
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2015 08:46:30 -0000

* Brian E Carpenter

> On 31/10/2015 04:24, Sander Steffann wrote:
> 
> > I always understood this bit from RFC 3633 to mean that any host
> > configuration flags (such as M/O) are not relevant to DHCPv6-PD:
> > "Note that this use of DHCP is not bound to the assignment of IP
> > addresses or other configuration information to hosts".	
> 
> The phrase "is not bound to" is rather unclear, don't you think? It
> neither says nor implies that routers are thereby exempt from issuing
> correct RAs.

Agreed.

Also, note that RFC 3633 did *not* update RFCs 2461/2462, which at the
time defined the meaning of the O/M flags to be essentially the same as
what RFC 4861 defines them to be today.

> Even if you accept that, in the case that you *don't* know that such
> information is available, you physically cannot set the M or O flag.
> So in the real world, a node that is interested in IA_PD had better
> go fishing for it, whatever the MO bits say. So I retract all the if
> statements in the pseudocode that I sent. The only robust
> implementation is one that always looks for DHCPv6 information.

That might indeed be the case - but it's not what the standards are
currently telling the implementers to do. Furthermore, accepting this
would mean that the M/O flags are essentially pointless. In that case,
deprecating the flags would be the logical thing to do.

(You explicitly called out IA_PD, but as your argument applies equally
well to any other DHCPv6 option I'm going to assume you meant IA_PD
just as an example.)

Tore