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

"Roberta Maglione (robmgl)" <> Tue, 19 November 2013 15:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F1811AE01C; Tue, 19 Nov 2013 07:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.541
X-Spam-Status: No, score=-13.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GwclZXmH5Dct; Tue, 19 Nov 2013 07:16:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 50CEE1ADFF3; Tue, 19 Nov 2013 07:16:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16603; q=dns/txt; s=iport; t=1384874206; x=1386083806; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9VrlUk8T2fZOP7CWfAu6qrHDhZ+jmSZsTAayFJXmVu4=; b=L2S53iqUPUtzRc29dzXjsqckA9hf0WoQ5Unc68auPaJIj9y5Ajathu8I NhLKJ+qbZWeZPcPoHDGsq7xorULqEF6JACO3wjBbx55IODvsTnWqrou2+ 1QT/Cln9sm/Y53s2xRj+mUYLxAZO8SAwe9KCwNl/ofW6o3lamxSX2qGo8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.93,729,1378857600"; d="scan'208,217"; a="286069451"
Received: from ([]) by with ESMTP; 19 Nov 2013 15:16:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAJFGjk5010268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 15:16:45 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 09:16:45 -0600
From: "Roberta Maglione (robmgl)" <>
To: Wuyts Carl <>, Athanasios Douitsis <>, "Bernie Volz (volz)" <>
Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation
Thread-Index: AQHO5SRsttdYcQjLZEODiORjPZunGZos5DGA///C96A=
Date: Tue, 19 Nov 2013 15:16:45 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "" <>, "" <>, " WG" <>, Michael Richardson <>
Subject: Re: [radext] [dhcwg] [homenet] 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 15:16:57 -0000

Hello Carl,
I agree with you that using DHCPv6 to number the WAN is a more common approach.
In such case you don't really need PD exclude; you just need a single IPv6 address for that link and RFC 6911 in section 3.1 already defines the Framed-IPv6-Address Radius attribute to be used for this purpose.
"3.1. Framed-IPv6-Address
   The Framed-IPv6-Address Attribute indicates an IPv6 address that is
   assigned to the NAS-facing interface of the RG/host."


From: Wuyts Carl []
Sent: Tuesday, November 19, 2013 7:43 AM
To: Athanasios Douitsis; Bernie Volz (volz)
Cc:; Michael Richardson; Roberta Maglione (robmgl); WG;
Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

It's probably just a remark/side note, but pd_exclude could also be used with DHCPv6 iso RA on the WAN-link.  I've not bumped in to many customers using RA on WAN links to number them, not with separate prefix nor with excluded prefix, so the typical use case will be to get/use an excluded prefix, and to assign an IP from it to the WAN link through ia_na.


From: dhcwg [] On Behalf Of Athanasios Douitsis
Sent: dinsdag 19 november 2013 13:40
To: Bernie Volz (volz)
Cc:<>; Michael Richardson; Roberta Maglione (robmgl);<> WG;<>
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

Hello (thanks for the answer),
The uplink connection between the delegating and the requesting router will be in many cases enumerated with a prefix dictated by the Framed-IPv6-Prefix value. If this uplink prefix is going to be a part of the greater prefix that will be delegated, we would in effect have to include the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE.
Example, if a delegating router makes a RADIUS request and gets the following attributes in the reply:

Then the delegating router should
1)send an RA in the client uplink interface with 2001:dead:beef::/64. The uplink is enumerated with that /64.
2)Afterwards, when requested for PD, it should reply with the 2001:dead:beef::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from that /56 by putting it in the OPTION_PD_EXCLUDE.
So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLUDE option.
If I have misunderstood something in the RFC or the discussion, I'd be grateful if you would correct me.
Thanks very much,

On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) <<>> wrote:
Why would it ever be copied into that option? That makes no sense to me.

- Bernie (from iPad)

On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <<>> wrote:

(i.e. have a configuration option to use the Framed-IPv6-Prefix value in the prefix exclude option instead of an RA)

Correction, the above is incorrect, as has been rightly pointed.
Are there any cases where the Framed-IPv6-Prefix value will not be copied as-is in the OPTION_PD_EXCLUDE value?

dhcwg mailing list<>

Athanasios Douitsis