Re: [dhcwg] PPP, DHCPv6 and Prefix Delegation

[Roberta Maglione <[e-mail]>]

Hello Michael,

in DSL/Broadband environment usually the BNAS/BNG acts both as RADIUS
Client and as DHCPv6 Server. In case of an IPv6 PPP session (or a PPP dual
stack IPv4/IPv6 session)  the PPP session is established using LCP that is
independent of the network layer protocol that needs to be carried over
PPP. LCP allows for the transport of both IPv4 and IPv6 at the same time
over the same PPP session.

In IPv6, address assignment is performed at the network layer, in contrast
to IPv4 where a number of functions are handled in the PPP layer. The only
function handled in IPv6 Control Protocol (IPv6CP) is the negotiation of a
unique interface identifier. The IPv6CP is only used to configure the link
local address.

The PPP link can be unnumbered (i.e. only using link – local addresses) or
numbered by the BNG which can assignIPv6 addresses to the remote peer via
SLAAC or DHCPv6. In addition to that DHCPv6-PD in order to get an IPv6
Prefix for the home network.

Both the IPv6 prefix to be used for the DHCPv6-PD and the IPv6 prefix  used
to number the Wan link (if needed) via SLAAC or DHCPv6, can be extracted
from a pool (locally configured on the BNG) and the pool name could be sent
from the RADIUS Server using specific RADIUS attributes in the
Access-Accept during the authentication phase. Please take a look at RFC
6911 for the details about the attributes for the pool names and
architecture.

Basically all the parameters required to configure the RG can be sent by
the RADIUS Server to the BNG (RADIUS client) in the Access-Accept during
the authentication phase and then the BNG (acting as DHCPv6 Server) can use
them to number the Wan link and delegate an IPv6 prefix to the home network.

Please take a look at TR-187 issue2 from BBF

http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf

 and RFC 4241 for  more details on the architectural model.

Hope this helps.

Thanks

Roberta


On Tue, Nov 12, 2013 at 12:11 PM, Michael Richardson
<[e-mail]>wrote:

>
> <#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)
>
> BACKGROUND:
> 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)
>
>
> ARCHITECTURE:
> 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)
>
> ISSUES:
> 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.
>
>
> OTHER NOTES:
> ===========
>
> 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 <[e-mail]>, Sandelman Software Works
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>