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

Michael Richardson <> Tue, 12 November 2013 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B5B411E811B; Tue, 12 Nov 2013 10:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N7ruCiDhFoxl; Tue, 12 Nov 2013 10:31:18 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3::184]) by (Postfix) with ESMTP id 8FCFE11E810B; Tue, 12 Nov 2013 10:31:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 20CE5202EE; Tue, 12 Nov 2013 14:43:21 -0500 (EST)
Received: by (Postfix, from userid 179) id 7489363B89; Tue, 12 Nov 2013 13:31:11 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 640A263848; Tue, 12 Nov 2013 13:31:11 -0500 (EST)
From: Michael Richardson <>
To: Ted Lemon <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 12 Nov 2013 13:31:11 -0500
Message-ID: <>
Cc: " WG" <>, " Group" <>, "<>" <>
Subject: Re: [radext] [homenet] PPP, DHCPv6 and Prefix Delegation
X-Mailman-Version: 2.1.12
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, 12 Nov 2013 18:31:26 -0000

Ted Lemon <> wrote:
    Ted> Historically this has been proposed to be done with a stateful BRAS
    Ted> that retains authentication information from the PPP client/RADIUS
    Ted> server authentication process, and provides that to the DHCP server
    Ted> using a relay option.   The DHCP server can then go to the RADIUS
    Ted> server to get prefix information if appropriate (although I would
    Ted> argue that this is unnecessary and probably harmful, since it
    Ted> requires static provisioning for all customers). 

Some radius servers have the ability to allocate from a pool and the keep
that lease for a period of time.

    Ted> Have you looked at RFC 4014 and RFC 7037?

Thank you for the reference, which I missed in scanning relevant WG documents.

    Ted> really be a problem.   If the RADIUS server were doing dynamic
    Ted> allocation, it would potentially be a problem since resources that
    Ted> are committed during the solicit/advertise phase ought to be freed
    Ted> if no request/reply phase follows.   I don't know enough about
    Ted> RADIUS to know if this ever happens, but it's my understanding that
    Ted> it does not. 

It can occur.

    Ted> Of course, the larger question here is, why the heck would you want
    Ted> to use PPPoE with all the MTU woes it brings into the picture?   I
    Ted> know the answers that are usually given, but I think this is
    Ted> something that ought to be treated as a less-preferred approach to
    Ted> delivering IPv6 service. 

This is not a greenfield deployment.  The existing service(s) is IPv4 PPPoE.
To be clear: this is an existing product being updated to support IPv6
because the customers asked for it. (Truly!)

PPPoE is also significantly easier for third party operators to work with in
many jurisdictions.

Michael Richardson <>, Sandelman Software Works