Re: IA_PD bit in RA

Owen DeLong <> Fri, 13 December 2013 23:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CDAAC1AE055; Fri, 13 Dec 2013 15:02:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.991
X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MYxIRKm2kLZr; Fri, 13 Dec 2013 15:02:33 -0800 (PST)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id E211F1AE005; Fri, 13 Dec 2013 15:02:32 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id rBDMvhGg025798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 14:57:44 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 rBDMvhGg025798
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1386975465; bh=7FYjlmBwQ/e7u1VZCO4UOlEgciU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=3d06KEqBSnY775/xeXW/8qmEQ4GFEko1JURji/lCAFCy6yvbHTz16/HtUJHUX2CXD 1d+Qkmr6JWKcZapUc4XO1v+xE60FLSl6E5Fy4e7n8GcsNSjX7kw2RTjf4Us2LgQ1yg EbkQj5cIUVd3n944AaR1JFgwtCmwrDyetxwPci1w=
Content-Type: multipart/alternative; boundary="Apple-Mail=_143AB308-590E-4C7E-A8FB-7408BE895497"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: IA_PD bit in RA
From: Owen DeLong <>
In-Reply-To: <>
Date: Fri, 13 Dec 2013 14:57:42 -0800
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Alexandru Petrescu <>
X-Mailer: Apple Mail (2.1822)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( []); Fri, 13 Dec 2013 14:57:45 -0800 (PST)
Cc: "" <>, 6man WG <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Dec 2013 23:02:35 -0000

On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu <> wrote:

> On 13/12/2013 23:01, Owen DeLong wrote:
>>>> I would think that the rational thing to do in an environment
>>>> where you want to provide DHCP-PD and not other information via
>>>> DHCP (which is hard for me to imagine why, but let's ignore that
>>>> for the moment) would be to advertise an O bit and then answer
>>>> with empty or negative responses for non PD requests.
>>> Right - reset M, set O and answer negatively to non-PD DHCP
>>> requests.
>>> But how about when the Delegated Prefix is available, but via
>>> 'other other' means than DHCP such as Radius, or via PPP?  There is
>>> no bit for that either.  The 'O' and 'M' bits apply only to DHCP.
>> There’s no support for this,
> Well...
> In addition to Radius and PPP, there are the migration v4-v6 mechanisms which may offer a v6 Delegated Prefix as well.

Examples, please?

>> nor do I think I would expect there to be support for this in RA.
> But one _would_ expect RA to always be there.

The ubiquitous presence of RA doesn’t mean that we should bloat those RAs with a bit for every conceivable possible choice of configuration mechanism that some person might want to use in some obscure application. Indeed, I would argue that it means quite the opposite, that we should be very judicious in what kind of bloat we stuff into RAs.

RDNSS had a pretty compelling case, IMHO. Short of an equally compelling case, I really don’t think it’s worth the tradeoffs.

>> In the cases of PPP and RADIUS, you are already having an
>> authentication or other negotiation process with the server and I
>> would presume that there would be mechanisms in those negotiations to
>> handle this. For example, in RADIUS, the prefix(es) should be sent as
>> additional attribute/value pairs. In PPP, I presume it would be part
>> of the IPCP6 process, but I admit I haven’t looked at those details.
>>> It would be clearer if there were 1 bit for each of the
>>> fundamental addressing aspects (address, default route, delegated
>>> prefix, etc.) and each would be 'O' - Address available by other
>>> means than this RA, Default route available by other means than
>>> this RA, Delegated prefix available by other means than this RA,
>>> etc.
>> I don’t see the advantage to this way of approaching it. Please
>> present a use case where this offers a clear advantage over the
>> existing mechanisms which would warrant an incompatible modification
>> to everyone else’s expectations and existing software. Absent a
>> compelling advantage to such a change, I just don’t think the
>> risk/reward proposition makes sesne.
> I agree.
> No particular use case.  This is on the 'what-if' branch.

What-ifs are all well and good, but if you want to create the kind of protocol upheaval that you are suggesting, then I think more than what-ifs are necessary. I think that would require a very compelling use case.