Re: [v6ops] M/O flags and PD

Tore Anderson <tore@fud.no> Fri, 30 October 2015 08:55 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 EDC781A6F2A for <v6ops@ietfa.amsl.com>; Fri, 30 Oct 2015 01:55:44 -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 gd8pGHWtvttE for <v6ops@ietfa.amsl.com>; Fri, 30 Oct 2015 01:55:44 -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 C8CC61A6F0B for <v6ops@ietf.org>; Fri, 30 Oct 2015 01:55:43 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1029] (port=47734 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1Zs5TG-0004ei-Gt; Fri, 30 Oct 2015 09:55:38 +0100
Date: Fri, 30 Oct 2015 09:55:38 +0100
From: Tore Anderson <tore@fud.no>
To: Gert Doering <gert@space.net>
Message-ID: <20151030095538.20544d0a@echo.ms.redpill-linpro.com>
In-Reply-To: <20151030082131.GC70452@Space.Net>
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> <20151030082131.GC70452@Space.Net>
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="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/SuTLYzTkhrG7ruBIa2AePnsgYzc>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 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: Fri, 30 Oct 2015 08:55:45 -0000

* Gert Doering <gert@space.net>

> Yes, but that is the point - "typical routers" do not need to
> *listen* to RAs, because that's not required for their job.  They
> will speak a routing protocol, and not default-route, etc.

Who is listening for RAs or not seems to me to be besides the point. It
boils down to this: If you are about to originate an RA to a link, and
know that there is information available in DHCPv6 on said link, you
should set set the M or O flag. Otherwise you're supplying false
information by indicating that there is no information available in
DHCPv6.

The possibility of there being a node (router) on the link that does
not listen to RAs does not seem relevant - you'd still be giving out
false information to anyone else on that link.

> As I said, boundaries between "hosts" and "router" are less than clear
> today - but this is my interpretation on how these have come into place.

Indeed. Thus I believe claims like «hosts don't request prefixes» or
«routers don't process RAs» can't be considered true (unless a node can
be both simultaneously).

> There might not even *be* a RA if this is a pure router-to-router
> link...

If you're not sending any RAs to begin with then you obviously do not
have to set any RA flags. That's fine. My point is just that IFF you
send RAs, make sure you send correct information - by setting the M or O
flag if there is any form DHCPv6 service being provided to the link.

In any case I don't think RA-less pure router-to-router links are
particularly relevant to a discussion on whether or not DHCPv6-PD is
signalled using the M/O RA flags. At least I have never seen a use case
where DHCPv6-PD being used on such RA-less router-to-router links, have
you?

> as soon as a host requests a prefix for "a bunch of VMs" running on
> that same host, and forwards traffic between "the outside router" and
> "the various VMs", it very much becomes a router...

...that, crucially, will continue to process RAs (just like a RFC 7084
CE router will). So the RA we're sending that host ought to contain
correct information.

Tore