Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

Jouni Korhonen <> Tue, 19 November 2013 17:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C87C21AE118; Tue, 19 Nov 2013 09:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.484
X-Spam-Status: No, score=0.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FRT_ADULT2=1.474, SPF_PASS=-0.001, T_FRT_ADULT2=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dojDfd3SpMoR; Tue, 19 Nov 2013 09:43:00 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22e]) by (Postfix) with ESMTP id 371301AE117; Tue, 19 Nov 2013 09:42:59 -0800 (PST)
Received: by with SMTP id x12so7869088wgg.13 for <multiple recipients>; Tue, 19 Nov 2013 09:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z16Ztk4xVQvEp7I2+OdsSriXy82xwcANqIzO3ym5fXw=; b=EdsFP4qc/V1N6DgslDvwyw/Qf+Zxo+pE9K5gQ86ZEPfV6kTRIt5JVIMafQCijjwYEA gt7jQQ5MKLW0qV1nYdWyDh0xPDE23igwHlr7eH9jY5H4EIOahHd+4eUc8iCNAhK1aoVT 0xg3uSoHyp409my5PCPnk2Nzchd6dQ2knKK2Hiuzy0PhV5HNwGTKLucas0ObClJ+ZQaw ZSwhzyMFFQmy9q4tgo5DNnqFWvEZ7lvpYBJeJHQMR7J9TknElCRPiwxppXCFLW9AYHbc +SBNYID0PgEPgSjeHHCXvMJeb8sIKYdVPu5EkZKdV3s6CquCQ3rkk03Iy7hwj0MJSE4b wuoQ==
X-Received: by with SMTP id b19mr1794876wiw.19.1384882972562; Tue, 19 Nov 2013 09:42:52 -0800 (PST)
Received: from troma.lan ( []) by with ESMTPSA id qc10sm36551286wic.9.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 09:42:51 -0800 (PST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <>
In-Reply-To: <>
Date: Tue, 19 Nov 2013 19:42:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Roberta Maglione (robmgl)" <>
X-Mailer: Apple Mail (2.1510)
Cc: "" <>, Athanasios Douitsis <>, "Bernie Volz (volz)" <>, Michael Richardson <>, " WG" <>, "" <>
Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Nov 2013 17:43:02 -0000

On Nov 19, 2013, at 7:10 PM, "Roberta Maglione (robmgl)" <> wrote:

> Hello,
> I see your point. In my opinion if you would like to have all the prefixes assigned by RADIUS server in order to be able to cover the scenario you described in a clean way you would need a new RADIUS attribute for PD_EXCLUDE.

I am not sure I agree entirely.

> The reason why I think a new radius would be required is because you need to differentiate between the scenario where Framed-IPv6-Prefix is used to number the Wan link with a separate prefix (not included in the PD - without the PD_EXCLUDE) and the scenario you described where the prefix for the WAN link is part of the PD and you need to copy it into the PD exclude option.

That would be a trivial check in the RADIUS client, right? If the Framed-IPv6-Prefix falls into the Delegated-IPv6-Prefix, then you do the exclude, otherwise not.

> Today the BNG (that in this case is acting both as RADIUS Client and Delegating Router) has no mean to know if the  Framed-IPv6-Prefix should be used for the  PD_EXCLUDE or not and in my opinion it would be better not overload the sematic of the Framed-IPv6-Prefix.
> Any comment?

I would do the check rather than define a new attribute. 

- Jouni

> Thanks
> Roberta
> From: Athanasios Douitsis [] 
> Sent: Tuesday, November 19, 2013 11:50 AM
> To: Bernie Volz (volz)
> Cc: Jouni Korhonen;;; Roberta Maglione (robmgl); WG; Michael Richardson
> Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
> On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <> wrote:
> This must be done by the delegation router (if you are talking about the DHCPv6 packet itself) – as it is the one that constructs the Advertise and Reply messages to the client.
> Pardon me, I meant to wonder who should make the assignment, not who should construct the packets.
> When you are using the Delegated-IPv6-Prefix AV pair, the delegating router obviously constructs the packets with the delegated prefix value, but the actual assignment has been done by the RADIUS server. By the same token, I wondered whether it makes sense to do the same for the OPTION_PD_EXCLUDE value.
> Kind regards,
> -- 
> Athanasios Douitsis