[radext] PPP, DHCPv6 and Prefix Delegation

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 November 2013 17:11 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BA21E8091; Tue, 12 Nov 2013 09:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 21d-ef-9CuwS; Tue, 12 Nov 2013 09:11:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5B21E82B8; Tue, 12 Nov 2013 09:11:29 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A4F40202EB; Tue, 12 Nov 2013 13:23:30 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 1DCBD63B89; Tue, 12 Nov 2013 12:11:21 -0500 (EST)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id 0E96963AEF; Tue, 12 Nov 2013 12:11:21 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dhcwg@ietf.org, homenet@ietf.org, radext@ietf.org
X-Attribution: mcr
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: text/plain; charset="us-ascii"
Date: Tue, 12 Nov 2013 12:11:21 -0500
Message-ID: <11836.1384276281@sandelman.ca>
Sender: mcr@sandelman.ca
X-Mailman-Approved-At: Tue, 12 Nov 2013 11:27:05 -0800
Subject: [radext] PPP, DHCPv6 and Prefix Delegation
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 17:11:55 -0000

<#secure method=pgpmime mode=sign>

(Please excuse my slight spray, but I'm unclear where the gap is.
Also I've just subscribed to radext. Haven't done any radius stuff in a
decade. It might also be that my question has been addressed by convention by
some operator forum)

I'm working on adding IPv6 to a PPPoE LAC, and specifically thinking about
IPv6 Prefix Delegation.  I'm working backwards from RFC6204 and the homenet
architecture document to derive requirements for the ISP end.
(If my document would be useful at the IETF, let me know.  Really, there
is little additional that homenet requires from ISPs other than 6204 and at
least a /56... at least until we get to DNS delegations issues, which I plan
to implement)

The intended architecture is ppp speaks to radius server to authenticate the
customer at LCP time,  then RA and DHCPv6 daemon(s) are told about new
interface; specifically about the customer associated with that virtual
interface.    I would prefer that the DHCPv6 speaks to the radius server
as well to obtain IPv6 prefix information using RFC4818.
(In IPv4 space the product has 6 different ways to maintain pools)

The issue/question that I'm having is that it seems to me that the PD
transaction must occur after the user is authenticated.  That is, it does not
occur during the initial Access-Request.  It can't occur until the IPV6CP has
brought the link up, and the customer has requested some address space.

So, when the subsequent DHCPv6 with the PD request arrives (with the
prefix-size and value hint), the DHCPv6 server will perform a second
radius request.  But how will this second request be linked to the first one?

If the DUID had been communicated during the PPP LCP setup, then that could
have been included in the initial Access-Request, and the second DHCPv6 could
reference it.

Or, if the radius server had returned some kind of session ID to the ppp,
it could communicate that to a co-located DHCPv6 server (or relay) to include
in the request.

Fundamentally, I think it's pretty important when we get to DNS
forward/reverse delegations that we are able to tie them to a specific
customer account.

My fallback at this point is that I will simply populate the Radius NAS-port
consistently (likely from the ppp interfaces' ifindex).  Perhaps I've missed
some PPPoE specific mechanism for this.


Also, I found the diagram in RFC4818 of concern.  It suggests that the
Radius server will be committing to providing the address space at
the point of Solicit, rather than at the point of Request.  
Why isn't the diagram in section 1 like this:

Requesting Router   Delegating Router                   RADIUS Server
         |                     |                                 |
         |-Solicit------------>|                                 |
         |<--Advertise(Prefix)-|                                 |
         |-Request(Prefix)---->|                                 |
         |                     |-Request------------------------>|
         |                     |<--Accept(Delegated-IPv6-Prefix)-|
         |<--Reply(Prefix)-----|                                 |
         |                     |                                 |

I guess that delegating router needs to know if there is address space
that it can delegate, and if there wasn't it wouldn't Advertise.  I just
think that this should have been a three phase protocol.

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works