Subject: [dhcwg] PPP, DHCPv6 and Prefix Delegation

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2013 12:11:21 -0500

<#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 <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Nov 2013 12:38:16 -0500

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

Have you looked at RFC 4014 and RFC 7037?

The reason for the state diagram in 4818 looking as it does is that the DHCP server has to know how it's going to respond to a request from the client before it sends its advertise message.   Since the prefix is statically configured on the RADIUS server, this shouldn't really be a problem.   If the RADIUS server were doing dynamic allocation, it would potentially be a problem since resources that are committed during the solicit/advertise phase ought to be freed if no request/reply phase follows.   I don't know enough about RADIUS to know if this ever happens, but it's my understanding that it does not.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2013 13:31:11 -0500

Ted Lemon <[email-masked]> 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.
Reading.

    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.

---

From: Roberta Maglione <[email-masked]>
Date: Thu, 14 Nov 2013 22:08:47 -0500

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
<[email-masked]>wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 10:11:23 -0500

Thank you for the write up.
It's clear that there is a gap, which TR-187 has filled.
     http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf

RFC4241 is Informational... why didn't TR-187 come to the IETF to standardize
4241?  (Will TR-187 get re-issued with the reference to access-16 changed to RFC6911?)

===
I was wondering this week whether or not the WAN link needed other than
link-local addresses, and it seems to me that this depends very much on
whether or not the CPE is going to do all of 6204 or not.

If link-local is enough, then there is no reason to do RS/RA over the WAN
link at all: stateless DHCPv6 to do PD is enough.

How can the BNG/BNAS know what will happen?   Is it reasonable to assume that the
if the device does a RS that it expects the ISP to number the WAN link with a
global address?

The documents all seem to suggest that the ISP is going to make a
provisioning decision a-priori about this.  And this seems to imply that
all customers will have to be provisioned.... while IPv6 space is very large,
bigger allocations cost ISPs more money, and so this still seems silly.

While the customer can be provisioned, the end user may well swap CPEs in and
out, and may connect desktop computers directly to the DSL connection at
times, so making the ISP and the end user agree here seems like a way to
guarantee truck rolls)

RFC6204 does not (as far as I can see) suggest that (un)numbering the WAN
link is something the CPE can/should do.  RFC6204 says:
     W-3:  Absent other routing information, the IPv6 CE router MUST use
           Router Discovery as specified in [RFC4861] to discover a

yet, RFC4241 omits a RS/RA phase in section 2.2, which specifically goes
        from IPV6CP (link-address negotiation) to prefix delegation

  2.2. IP Layer
    After IPV6CP negotiation, the CPE initiates a prefix delegation
    request.

The diagram in RFC4241, figure 2 also clearly leaves out RS/RA.
(I remind that 4241 is Informational, not standards track)

If it does PD, then the CPE device can clearly use an address from the
delegated prefix to originate traffic to the Internet. 4241 suggests
assigning the "0" subnet network to the router's loopback.

(I note that this could make the CPE's firewall more complex, as one can
 assume that all PD/56 traffic is to be protected equally.)

Further, if the WAN link is numbered as a /64 from within the prefix that
(will be) delegated, that also would seem to make the CPE's firewall even
more complex, so I'd rather number it outside the PD if it needs to be
numbered at all.

Meanwhile, TR-187 says that Route Advertisements are generated by the BNG.
(section 5.2

and says:
    Whenever the Framed-IPv6-Prefix attribute is returned from RADIUS, the
    BNG includes this prefix as On-Link and Autonomous in the Router
    Advertisement Prefix Information Option. If this attribute is omitted,
    the BNG will not send a Prefix Information Option. DHCPv6 is used to delegate prefixes.

so this is exactly inline with what I had concluded: number the link if
provisioned to do so, leave it unnumbered otherwise.

Has this worked well in the field?

section 5.3.1 suggests that the delegated prefix be returned during the
initial communication with the radius server.  This is great for
pre-provisioned systems, but seems to premeditate the size of prefixes that
customers will get, regardless of what they put into their DHCPv6 PD request.

It also implies that every customer, even those not yet IPv6 ready, are going
to get IPv6 prefixes delegated to them, as the various IPv6 radius attributes
are returned during PPP LCP phase, and before one has any idea that the customer
is v6 capable.  It also prevents the CPE from turning on IPv6 later on
without cycling the PPP connection.

I think it would be better to omit that on the first connection, and permit
the allocation to be driven by the actual DHCPv6.  RFC6911 outlines the
attributes to be used, but it isn't clear to me that they have to be done at
PPP LCP time.

It seems that TR-187, in requirement R-22, (section 9), is suggesting that
/128 addresses be given out via stateful DHCPv6.  But R-29 says /64 for
SLAAC.

Roberta Maglione <[email-masked]> wrote:
    > 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.

Yes,  the delegated prefix could be in the initial Access-Accept, and this is
easy to do if the prefixes are all statically provisioned.  There are radius
servers that can do dynamic allocation, but the bigger issue I'm concerned
about is that the allocation may not be able to reflect what the CPE will
actually ask for.

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

Thank you this document is useful.  I'd like to ask that some homenet
document cite it.

    mcr>  and RFC 4241 for  more details on the architectural model.  

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

I have been reminded of the radius State attribute which is commonly used.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 15 Nov 2013 16:28:53 +0100

All, some feedback from a CPE-vendor, feel free to ignore of course.

1. Wan links don't NEED global IP address.  This will depend on different factors and used protocols.  E.g. a PPP does not need a global IP for sure, however, what if you want to run remote management on it through IPv6 ?  It's very unlikely to be on the same link, hence link-local might not be sufficient.

2. if the CPE sends an RS, the BNG doesn't have to translate this as "please number my link", strange assumption I'd say.

3. the statement   "After IPV6CP negotiation, the CPE initiates a prefix delegation request."  makes sense that DHCPv6 is indeed the local next step after PPP IPv6 is "up", however, potentially, manual config is possible, so to have this "automatically' in place might be the wrong conclusion

4. the statement " Further, if the WAN link is numbered as a /64 from within the prefix that (will be) delegated, that also would seem to make the CPE's firewall even more complex, so I'd rather number it outside the PD if it needs to be numbered at all."  Agree that firewall config might be more difficult, but don't forget that it saves address space +, more important, injects less administration for the ISP to keep track of prefixes.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: vrijdag 15 november 2013 16:11
To: Roberta Maglione
Cc: [email-masked] WG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

RFC4241 is Informational... why didn't TR-187 come to the IETF to standardize 4241?  (Will TR-187 get re-issued with the reference to access-16 changed to RFC6911?)

===
I was wondering this week whether or not the WAN link needed other than link-local addresses, and it seems to me that this depends very much on whether or not the CPE is going to do all of 6204 or not.

If link-local is enough, then there is no reason to do RS/RA over the WAN link at all: stateless DHCPv6 to do PD is enough.

How can the BNG/BNAS know what will happen?   Is it reasonable to assume that the
if the device does a RS that it expects the ISP to number the WAN link with a global address?

The documents all seem to suggest that the ISP is going to make a provisioning decision a-priori about this.  And this seems to imply that all customers will have to be provisioned.... while IPv6 space is very large, bigger allocations cost ISPs more money, and so this still seems silly.

While the customer can be provisioned, the end user may well swap CPEs in and out, and may connect desktop computers directly to the DSL connection at times, so making the ISP and the end user agree here seems like a way to guarantee truck rolls)

RFC6204 does not (as far as I can see) suggest that (un)numbering the WAN link is something the CPE can/should do.  RFC6204 says:
     W-3:  Absent other routing information, the IPv6 CE router MUST use
           Router Discovery as specified in [RFC4861] to discover a

  2.2. IP Layer

If it does PD, then the CPE device can clearly use an address from the delegated prefix to originate traffic to the Internet. 4241 suggests assigning the "0" subnet network to the router's loopback.

(I note that this could make the CPE's firewall more complex, as one can  assume that all PD/56 traffic is to be protected equally.)

Further, if the WAN link is numbered as a /64 from within the prefix that (will be) delegated, that also would seem to make the CPE's firewall even more complex, so I'd rather number it outside the PD if it needs to be numbered at all.

and says:

so this is exactly inline with what I had concluded: number the link if provisioned to do so, leave it unnumbered otherwise.

section 5.3.1 suggests that the delegated prefix be returned during the initial communication with the radius server.  This is great for pre-provisioned systems, but seems to premeditate the size of prefixes that customers will get, regardless of what they put into their DHCPv6 PD request.

It also implies that every customer, even those not yet IPv6 ready, are going to get IPv6 prefixes delegated to them, as the various IPv6 radius attributes are returned during PPP LCP phase, and before one has any idea that the customer is v6 capable.  It also prevents the CPE from turning on IPv6 later on without cycling the PPP connection.

I think it would be better to omit that on the first connection, and permit the allocation to be driven by the actual DHCPv6.  RFC6911 outlines the attributes to be used, but it isn't clear to me that they have to be done at PPP LCP time.

It seems that TR-187, in requirement R-22, (section 9), is suggesting that
/128 addresses be given out via stateful DHCPv6.  But R-29 says /64 for SLAAC.

    > Server) can use them to number the Wan link and delegate an IPv6 prefix

Yes,  the delegated prefix could be in the initial Access-Accept, and this is easy to do if the prefixes are all statically provisioned.  There are radius servers that can do dynamic allocation, but the bigger issue I'm concerned about is that the allocation may not be able to reflect what the CPE will actually ask for.

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

Thank you this document is useful.  I'd like to ask that some homenet document cite it.

---

From: Roberta Maglione <[email-masked]>
Date: Fri, 15 Nov 2013 12:57:23 -0500

Please see comments inline [RM].
Regards,
Roberta

On Fri, Nov 15, 2013 at 10:11 AM, Michael Richardson
<[email-masked]>wrote:

> 4241?

[RM] Well, basically there were no new protocol extensions to be
standardized in order to cover this scenario;  the missing piece was a
document where to glue together all the different pieces and specify
requirements for CPE and BNG, that's why we (speaking as one of the
co-editors of TR-187) did this work at the BBF/

> (Will TR-187 get re-issued with the reference to access-16 changed to
> RFC6911?)
>
[RM] Well I don't yet, maybe, I need to speak with the other co-editors
none of us is actively involved in BBF anymore.

> whether or not the CPE is going to do all of 6204 or not.
[RM] This is really a Service Provider's preference: there are operators
that prefer numbered model (for management/security purposes) and others
that are fine with just the link-local and the loopback for management. We
had a long discussion in BBF about this point and both models appeared to
be valid.

> bigger allocations cost ISPs more money, and so this still seems silly.
[RM] Why do you think it is silly? The ISPs have to make a-priori decision
about the provisioning model in order to provision the customers with the
right service profile.
This is not different with what it happens today for IPv4: let's say you
are a customer that subscribes both Internet and IPTV service, while I'm a
customer that only subscribes the internet service: my "user profile" on
RADIUS server will be different from yours.

> more complex, so I'd rather number it outside the PD if it needs to be
[RM] I'm not familiar with security, I cannot comment on firewall, but I
can add some more details on the prefix to be used for the WAN link.
Actually using a /64 taken from the prefix delegated via DHCP-PD to number
the WAN link at the time we wrote the first version of TR-187 was not
allowed by RFC3633 because the WAN is the link from where the prefix was
received.
More recently RFC 6603 about Prefix exclude was published so today you
could theoretically do that if you use prefix exclude option, but I'm not
sure how much this model has been adopted. It is referenced in
 draft-ietf-v6ops-6204bis WPD-8.

> customers will get, regardless of what they put into their DHCPv6 PD
[RM] back to my previous comment: provision the customer/service profile in
the RADIUS server is a common practice in Service Provider's environment.

> /128 addresses be given out via stateful DHCPv6.  But R-29 says /64 for
[RM] TR-187 allows for both options either DHCPv6 or SLAAC can be used to
number the WAN link: there are Service Providers that would like to use
DHCPv6 other that prefer SLAAC.

Infect R-22 says "[....]   when using DHCPv6 for address assignment" and
R-29 says " When SLAAC is used to number the WAN link".

You use either R-22 (if you do DHCPv6) or R-29 (if you do SLAAC) or none
for unnumbered.

Thanks

Roberta

---

From: Roberta Maglione <[email-masked]>
Date: Fri, 15 Nov 2013 13:32:44 -0500

Please see comments inline [RM]
Thanks
Roberta

On Fri, Nov 15, 2013 at 10:28 AM, Wuyts Carl <[email-masked]>wrote:

> 1. Wan links don't NEED global IP address.  This will depend on different
> factors and used protocols.  E.g. a PPP does not need a global IP for sure,
> however, what if you want to run remote management on it through IPv6 ?
>  It's very unlikely to be on the same link, hence link-local might not be
> sufficient.
>
[RM] agree. Remote management was one of the use cases brought up at the
BBF in order to support the numbered model. Somebody argued saying that you
could leave the WAN unnumbered and use the loopback with a prefix taking by
the delegated prefix, but some operators prefer to have a separate single
IPv6 prefix for managing all the RG's.

>
> 2. if the CPE sends an RS, the BNG doesn't have to translate this as
> "please number my link", strange assumption I'd say.
>
> 3. the statement   "After IPV6CP negotiation, the CPE initiates a prefix
> delegation request."  makes sense that DHCPv6 is indeed the local next step
> after PPP IPv6 is "up", however, potentially, manual config is possible, so
> to have this "automatically' in place might be the wrong conclusion
>
> 4. the statement " Further, if the WAN link is numbered as a /64 from
> within the prefix that (will be) delegated, that also would seem to make
> the CPE's firewall even more complex, so I'd rather number it outside the
> PD if it needs to be numbered at all."  Agree that firewall config might be
> more difficult, but don't forget that it saves address space +, more
> important, injects less administration for the ISP to keep track of
> prefixes.
>
[RM] As I mentioned in my other email if you want to use an IPv6 prefix
from the delegate prefix you would need to use prefix exclude option RFC
6603. I agree with you that you would save address space but this model may
not be optimal for the operators that would like to have the management
interface of all the RG's in the same IPv6 prefix in order to
reduce/simplify the number of ACL's that they would need to add in the
network to restrict the access to the management systems.

Thanks
Roberta

> RFC4241 is Informational... why didn't TR-187 come to the IETF to
> standardize 4241?  (Will TR-187 get re-issued with the reference to
> access-16 changed to RFC6911?)
>
> ===
> all customers will have to be provisioned.... while IPv6 space is very
> large, bigger allocations cost ISPs more money, and so this still seems
> silly.
>
> While the customer can be provisioned, the end user may well swap CPEs in
> and out, and may connect desktop computers directly to the DSL connection
> at times, so making the ISP and the end user agree here seems like a way to
> guarantee truck rolls)
>
> It also implies that every customer, even those not yet IPv6 ready, are
> going to get IPv6 prefixes delegated to them, as the various IPv6 radius
> attributes are returned during PPP LCP phase, and before one has any idea
> that the customer is v6 capable.  It also prevents the CPE from turning on
> IPv6 later on without cycling the PPP connection.
>
> I think it would be better to omit that on the first connection, and
> permit the allocation to be driven by the actual DHCPv6.  RFC6911 outlines
> the attributes to be used, but it isn't clear to me that they have to be
> done at PPP LCP time.
>
> Yes,  the delegated prefix could be in the initial Access-Accept, and this
> is easy to do if the prefixes are all statically provisioned.  There are
> radius servers that can do dynamic allocation, but the bigger issue I'm
> concerned about is that the allocation may not be able to reflect what the
> CPE will actually ask for.
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 14:19:25 -0500

Wuyts Carl <[email-masked]> wrote:
    > within the prefix that (will be) delegated, that also would seem to
    > make the CPE's firewall even more complex, so I'd rather number it
    > outside the PD if it needs to be numbered at all."  Agree that firewall
    > config might be more difficult, but don't forget that it saves address
    > space +, more important, injects less administration for the ISP to
    > keep track of prefixes.

Yes, it all seems way more elegate to do it that way.
If you, as a CPE vendor are happy with getting such a thing, then, if one has
to number that WAN link, I'd prefer to do it this way.

I think that this might be a new statement on the homenet side.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 14:54:41 -0500

> standardize

    rm> [RM] Well, basically there were no new protocol extensions to be standardized
    rm> in order to cover this scenario;  the missing piece was a document where
    rm> to glue together all the different pieces and specify requirements for CPE and
    rm> BNG, that's why we (speaking as one of the co-editors of TR-187) did this work
    rm> at the BBF/

The issue is whether the Broadband forum does not have the same trade-agreement
status that the IETF has an SDO.  This matters to many utilities that are
constrained by trade agreements to procure on via "performance
specifications".

The other issue is whether everyone knows to look towards the Broadband forum
to find the document.  I am very glad to find it :-)

    > large,

    rm> [RM] Why do you think it is silly? The ISPs have to make a-priori decision
    rm> about the provisioning model in order to provision the customers with the right
    rm> service profile.
    rm> This is not different with what it happens today for IPv4: let's say you are a
    rm> customer that subscribes both Internet and IPTV service, while I'm a customer
    rm> that only subscribes the internet service: my "user profile" on RADIUS server
    rm> will be different from yours.

The ISP is forced to provision IPv6 to *all* customers in an area, regardless
of what the customer actually asks for, or whether they are ready to do
IPv6.

In IPv4 speak, this is like provisioning IPv4 space (and a /29 at that) to
every person in your service area, on the chance that they might use it.

    > Actually using a /64 taken from the prefix delegated via DHCP-PD to number the
    > WAN link at the time we wrote the first version of TR-187 was not allowed by
    > RFC3633 because the WAN is the link from where the prefix was received.  

    > More recently RFC 6603 about Prefix exclude was published so today you could
    > theoretically do that if you use prefix exclude option, but I'm not sure how
    > much this model has been adopted. It is referenced in  draft-ietf-v6ops-6204bis
    > WPD-8.

Thanks also for this.
TR187 does not mention 6603...

---

From: Athanasios Douitsis <[email-masked]>
Date: Fri, 15 Nov 2013 22:59:06 +0200

>  draft-ietf-v6ops-6204bis WPD-8.

Hello,

Shouldn't there also be a Prefix Exclude Option RADIUS attribute? I can
imagine that the delegating router vendor could very well use the
Framed-IPv6-Prefix with a different set of semantics (i.e. have a
configuration option to use the Framed-IPv6-Prefix value in the prefix
exclude option instead of an RA), but a separate RADIUS attribute would be
more appropriate.

Kind regards,
-- 
Athanasios Douitsis

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 13:15:54 +0200

(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?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 19 Nov 2013 12:07:40 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

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

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 14:39:32 +0200

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:

Framed-IPv6-Prefix='2001:dead:beef::/64'
Delegated-IPv6-Prefix='2001:dead:beef::/56'

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,
Athanasios

On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) <[email-masked]> wrote:

> On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <[email-masked]>
> wrote:
>
>
>
>  Are there any cases where the Framed-IPv6-Prefix value will not be
> copied as-is in the OPTION_PD_EXCLUDE value?
>
>
>
>

-- 
Athanasios Douitsis

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 19 Nov 2013 14:44:56 +0200

Just a general reminder. If you crosspost, make sure you also have subscribed to the lists you CC.

- Jouni (RADEXT co-chair)

On Nov 19, 2013, at 2:07 PM, Bernie Volz (volz) <[email-masked]> wrote:

> On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <[email-masked]> wrote:
> 
>> 
>> 
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 19 Nov 2013 13:43:29 +0100

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.

Regs
Carl

From: dhcwg [mailto:[email-masked]] On Behalf Of Athanasios Douitsis
Sent: dinsdag 19 november 2013 13:40
To: Bernie Volz (volz)
Cc: [email-masked]; Michael Richardson; Roberta Maglione (robmgl); [email-masked] WG; [email-masked]
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:

Framed-IPv6-Prefix='2001:dead:beef::/64'
Delegated-IPv6-Prefix='2001:dead:beef::/56'
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,
Athanasios

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

- Bernie (from iPad)

--
Athanasios Douitsis

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 19 Nov 2013 13:19:59 +0000

I guess from RFC 4818, Delegated-IPv6-Prefix is used for PD. Whereas it says:

   The Framed-IPv6-Prefix attribute [4] is not designed to support
   delegation of IPv6 prefixes to be used in the user's network, and
   therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may
   be included in the same RADIUS packet.

But, I'm not really clear if that ends up mapping to OPTION_PD_EXCLUDE for the Framed-IPv6-Prefix. Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Athanasios Douitsis
Sent: Tuesday, November 19, 2013 7:40 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Michael Richardson; Roberta Maglione (robmgl); [email-masked] WG; [email-masked]
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

- Bernie (from iPad)

--
Athanasios Douitsis

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 17:00:37 +0200

On Tue, Nov 19, 2013 at 3:19 PM, Bernie Volz (volz) <[email-masked]> wrote:

> But, I’m not really clear if that ends up mapping to OPTION_PD_EXCLUDE for
> the Framed-IPv6-Prefix. Perhaps if the case is as in your example
> (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal)
> then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?
>

Hello,

In some cases like the one you and I have described here, I think it
probably makes sense for the delegating router to use the
Framed-IPv6-Prefix to infer what to put in the OPTION_PD_EXCLUDE. In these
cases, the delegating router probably has all the information it needs to
answer PD requests. Of course, some configuration options (e.g. do copy the
Framed-IPv6-Prefix to OPTION_PD_EXCLUDE) and sanity checks (e.g. make sure
the Framed is contained in the Delegated prefix) may be in order to make it
work right, but the idea remains essentially the same.

What I was also wondering previously is whether there are valid cases where
one would want to explicitly dictate the OPTION_PD_EXCLUDE via RADIUS,
presumably along with the Delegated-IPv6-Prefix. If those cases actually
exist, maybe a separate RADIUS attribute could be useful. Just thinking
loudly, not sure yet.

Kind regards,
-- 
Athanasios Douitsis

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 19 Nov 2013 15:16:45 +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."

Thanks
Roberta

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

Regs
Carl

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

- Bernie (from iPad)

--
Athanasios Douitsis

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 19 Nov 2013 15:20:55 +0000

> Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) >then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

Maybe it could theoretically make sense but is this a common deployment model? Are there any Service Providers that use or plan to use this model?

Thanks
Roberta

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

-        Bernie

- Bernie (from iPad)

--
Athanasios Douitsis

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 19 Nov 2013 16:18:37 +0100

No, indeed, you don't really need pd_exclude, but it saves admin on not having to use separate ia_pd and ia_na

Regs
Carl

From: Roberta Maglione (robmgl) [mailto:[email-masked]]
Sent: dinsdag 19 november 2013 16:17
To: Wuyts Carl; Athanasios Douitsis; Bernie Volz (volz)
Cc: [email-masked]; Michael Richardson; [email-masked] WG; [email-masked]
Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

Hello Carl,

Thanks
Roberta

Regs
Carl

- Bernie (from iPad)

--
Athanasios Douitsis

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 18:07:46 +0200

On Tue, Nov 19, 2013 at 5:20 PM, Roberta Maglione (robmgl) <[email-masked]

> > Perhaps if the case is as in your example (Framed-IPv6-Prefix is
> contained by Delegated-IPv6-Prefix, but not equal) >then using the
> Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?
>
>
>
> Maybe it could theoretically make sense but is this a common deployment
> model? Are there any Service Providers that use or plan to use this model?
>

Hello,

I wonder how common it is for providers to enumerate the WAN with a global
prefix. If one wants to enumerate the WAN with a global prefix one should
unavoidably have to find a /64 additionally to the /56 (or whatever is
allocated) per customer. Without PD_EXCLUDE, the framed /64 must be foreign
to the delegated /56, which means different prefix pools, double the size
of the routing table in your delegating router, etc. Basically the "3 -
Problem Background" from rfc6603 says it much better than me.

In our setup (moderate size provider with PPP links over DSL enumerated
with NDRA and then DHCPv6-PD), we use both Framed-IPv6-Prefix (global) and
Delegated-IPv6-Prefix (also global) to tell the delegating router what to
give out. Obviously these two prefixes come from different pools of global
prefixes, foreign to each other. I really don't know how common it is, but
if instead of maintaining two separate prefix pools for framed and
delegated we could just use a single pool of /56 prefixes where the framed
/64 comes from inside the corresponding /56 for each customer, that would
be indeed great.

-- 
Athanasios Douitsis

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 19 Nov 2013 18:22:49 +0200

On Nov 19, 2013, at 3:19 PM, Bernie Volz (volz) <[email-masked]> wrote:

> But, I’m not really clear if that ends up mapping to OPTION_PD_EXCLUDE for the Framed-IPv6-Prefix. Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> what you put into RA, Delegated-IPv6-Prefix -> what you delegate via DHCPv6. And in this case what was in Framed-IPv6-Prefix goes into OPTION_PD_EXCLUDE.

- Jouni

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 18:38:29 +0200

On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen <[email-masked]>wrote:

> 3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> what
> you put into RA, Delegated-IPv6-Prefix -> what you delegate via DHCPv6. And
> in this case what was in Framed-IPv6-Prefix goes into OPTION_PD_EXCLUDE.

Hello,

In your opinion, should the copying Framed-IPv6-Prefix -> OPTION_PD_EXCLUDE
be rather be done (1) by the RADIUS server (assuming that a new separate
hypothetical RADIUS attribute exists) or (2) by the delegating router?

In other words, do you see any benefits in (1)?

-- 
Athanasios Douitsis

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 19 Nov 2013 16:42:10 +0000

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.

-          Bernie

From: Athanasios Douitsis [mailto:[email-masked]]
Sent: Tuesday, November 19, 2013 11:38 AM
To: Jouni Korhonen
Cc: Bernie Volz (volz); [email-masked]; [email-masked]; Roberta Maglione (robmgl); [email-masked] WG; Michael Richardson
Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen <[email-masked]<mailto:[email-masked]>> wrote:
3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> what you put into RA, Delegated-IPv6-Prefix -> what you delegate via DHCPv6. And in this case what was in Framed-IPv6-Prefix goes into OPTION_PD_EXCLUDE.

Hello,

In your opinion, should the copying Framed-IPv6-Prefix -> OPTION_PD_EXCLUDE be rather be done (1) by the RADIUS server (assuming that a new separate hypothetical RADIUS attribute exists) or (2) by the delegating router?
In other words, do you see any benefits in (1)?

--
Athanasios Douitsis

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 18:49:44 +0200

On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <[email-masked]> 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

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 19 Nov 2013 17:10:42 +0000

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.
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.
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?
Thanks
Roberta

From: Athanasios Douitsis [mailto:[email-masked]]
Sent: Tuesday, November 19, 2013 11:50 AM
To: Bernie Volz (volz)
Cc: Jouni Korhonen; [email-masked]; [email-masked]; Roberta Maglione (robmgl); [email-masked] WG; Michael Richardson
Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> 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

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 19 Nov 2013 19:36:46 +0200

In 3GPP system in this particular setup the first hop router (for the device/cpe) is also the delegating router and the RADIUS client. 

- Jouni

On Nov 19, 2013, at 6:42 PM, "Bernie Volz (volz)" <[email-masked]> 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.
>  
> -          Bernie
>  
> On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen <[email-masked]> wrote:

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 19 Nov 2013 19:42:48 +0200

> 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 RADI…

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 i…

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…

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

- Jouni

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 19 Nov 2013 17:47:46 +0000

>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.

Ok, you are right this is a way to do it.

Thanks
Roberta
 
-----Original Message-----
From: radext [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, November 19, 2013 12:43 PM
To: Roberta Maglione (robmgl)
Cc: [email-masked]; Athanasios Douitsis; Bernie Volz (volz); Michael Richardson; [email-masked] WG; [email-masked]
Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

- Jouni

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Athanasios Douitsis <[email-masked]>
Date: Tue, 19 Nov 2013 21:27:35 +0200

Hello,

Thanks for the comments!

Indeed in a scenario where all the requesting routers connecting to a
delegating router (BNG) would have PD_EXCLUDE capability, using the
Framed-IPv6-Prefix to infer what to put into the OPTION_PD_EXCLUDE field is
sufficient.

But if there is a mix of PD_EXCLUDE-capable and not capable requesting
clients, the situation becomes more complex. The fundamental problem is
that Prefix Delegation usually happens after the RADIUS exchange, so the
RADIUS server cannot really know whether the customer is exclude-capable or
not.

If, for example, the client is not exclude-capable, then having the RADIUS
return a Framed-IPv6-Prefix that is part of the (greater)
Delegated-IPv6-Prefix is problematic for obvious reasons. In fact, I, for
one, cannot wrap my head around a way to cover both cases (exclude-capable
and non-exclude-capable) using only the two existing RADIUS attributes
*and* at the same time maintain backwards compatibility with old
customers.

As suggested, one approach would be to define a new RADIUS attribute (say
IPv6-Excluded-Prefix) which would be used to enumerate the WAN (and be put
in the OPTION_PD_EXCLUDE of course) in case of an exclude-capable customer.
But this gets rather messy, in the sense that iff the customer is
exclude-capable and the IPv6-Excluded-Prefix is returned, then the
IPv6-Excluded-Prefix is used to enumerate the WAN, otherwise the normal
avenue (Framed-IPv6-Prefix or Framed-IPv6-Pool or Framed-IPv6-Address, etc)
is followed and the IPv6-Excluded-Prefix is ignored. And, admittedly,
having to always provide a Framed-IPv6-Prefix foreign to the
Delegated-IPv6-Prefix kind of defeats the whole purpose of RFC6603 in some
ways.

Any comments on that? How do you believe the case of mixed clients should
be handled without breaking existing conventions?

Kind regards,
Athanasios Douitsis

On Tue, Nov 19, 2013 at 7:47 PM, Roberta Maglione (robmgl) <[email-masked]

> >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.
>
> Cc: [email-masked]; Athanasios Douitsis; Bernie Volz (volz); Michael
> Richardson; [email-masked] WG; [email-masked]
> > 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.
>
> > 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?
>
> > Cc: Jouni Korhonen; [email-masked]; [email-masked]; Roberta Maglione
> (robmgl); [email-masked] WG; Michael Richardson
> DHCPv6 packet itself) - as it is the one that constructs the Advertise and
> > 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
> >
> >
>

-- 
Athanasios Douitsis

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 20 Nov 2013 10:55:01 +0200

On Nov 19, 2013, at 9:27 PM, Athanasios Douitsis <[email-masked]> wrote:

> Hello,
> 
> Thanks for the comments! 
> 
> Indeed in a scenario where all the requesting routers connecting to a delegating router (BNG) would have PD_EXCLUDE capability, using the Framed-IPv6-Prefix to infer what to put into the OPTION_PD_EXCLUDE field is sufficient.  
> 
> But if there is a mix of PD_EXCLUDE-capable and not capable requesting clients, the situation becomes more complex. The fundamental problem is that Prefix Delegation usually happens after the RADIUS exchange, so the RADIUS server cannot really know whether the customer is exclude-capable or not.  
> 
> If, for example, the client is not exclude-capable, then having the RADIUS return a Framed-IPv6-Prefix that is part of the (greater) Delegated-IPv6-Prefix is problematic for obvious reasons. In fact, I, for one, cannot wrap my head around a way to cover both cases (exclude-capable and non-exclude-capable) using only the two existing RADIUS attributes *and* at the same time maintain backwards compatibility with old customers.  

I don't think having multiple attributes brings any additional value. That would mean you allocate "just to be sure" a prefix from another block. What I would do in this specific case is just to halve delegated prefix and pick the single prefix from there and delegate the rest to the client. That wastes half of the delegated prefix but I as a delegating router am allowed to do so. This would make the logic/provisioning on the RADIUS server and the client always the same. The additional logic would be in the delegating router to device whether it halves the delegated prefix or not.

- Jouni

> As suggested, one approach would be to define a new RADIUS attribute (say IPv6-Excluded-Prefix) which would be used to enumerate the WAN (and be put in the OPTION_PD_EXCLUDE of course) in case of an exclude-capable customer. But this gets rather messy, in the sense that iff the customer is exclude-capable and the IPv6-Excluded-Prefix is returned, then the IPv6-Excluded-Prefix is used to enumerate the WAN, otherwise the normal avenue (Framed-IPv6-Prefix or Framed-IPv6-Pool or Framed-IPv6-Address, etc) is followed and the IPv6-Excluded-Prefix is ignored. And, admittedly, having to always provide a Framed-IPv6-Prefix foreign to the Delegated-IPv6-Prefix kind of defeats the whole purpose of RFC6603 in some ways. 
> 
> Any comments on that? How do you believe the case of mixed clients should be handled without breaking existing conventions? 
> 
> Kind regards,
> Athanasios Douitsis
> 
> 
> 
> 
> 
> 
> On Tue, Nov 19, 2013 at 7:47 PM, Roberta Maglione (robmgl) <[email-masked]> wrote:

---

From: Athanasios Douitsis <[email-masked]>
Date: Wed, 20 Nov 2013 11:59:01 +0200

On Wed, Nov 20, 2013 at 10:55 AM, Jouni Korhonen <[email-masked]>wrote:

> I don't think having multiple attributes brings any additional value. That
> would mean you allocate "just to be sure" a prefix from another block. What
> I would do in this specific case is just to halve delegated prefix and pick
> the single prefix from there and delegate the rest to the client. That
> wastes half of the delegated prefix but I as a delegating router am allowed
> to do so. This would make the logic/provisioning on the RADIUS server and
> the client always the same. The additional logic would be in the delegating
> router to device whether it halves the delegated prefix or not.

Hello,

Yes, using one prefix and halving it if necessary is simpler and more
elegant from a certain point of view. Admittedly allocating "just to be
sure" is by the same token ugly.

The only downside that I'd like to mention is that many administrators
generally like to do as much as possible in the RADIUS and rely on
specialized router features as little as possible. Not only is it easier to
add functionality and logic on the side of the RADIUS, but it makes one
more standards compliant and vendor independent in case one would like to
make a switch in the future. From that point of view, relying on the BNG to
halve (or in any other way modify) the prefixes if necessary can be
slightly disadvantageous. Especially if it is not possible to tell what
eventually happened with the prefix(es), even by looking at the radius
accounting records.

My regards and thanks very much,
-- 
Athanasios Douitsis

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2013 09:03:52 -0500

Roberta Maglione (robmgl) <[email-masked]> wrote:
    > 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.

    > 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.

If the DHCPv6 server that is constructing the PD can know what how the WAN
link is numbered, then it can include the PD_EXCLUDE based upon a simple
calculation.

If one assumes the inclusion of the Framed-IPv6-Prefix in the DHCPv6 RADIUS
option added by a relay, then even if the DHCPv6 is not co-located, it could
know about the Framed-IPv6-Prefix.  That might not cover all situations
however, in particular, it won't cover cases where the WAN link was not
numbered as a result of RADIUS attributes.  Is a DHCP relay that isn't
talking to a radius server allowed to synthesize that attribute, or do we
need another way to do this?

Or we are just overthinking things?

Roberta, is PD_EXCLUDE widely implemented in CPEs that do 6204?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2013 09:08:36 -0500

> But if there is a mix of PD_EXCLUDE-capable and not capable requesting clients,
    > the situation becomes more complex. The fundamental problem is that Prefix
    > Delegation usually happens after the RADIUS exchange, so the RADIUS server
    > cannot really know whether the customer is exclude-capable or not. 

Note that CPEs ought to be smart enough to exclude the subnet that their WAN
link is in, but it's certainly the case that many are not yet that smart.
(the dnsmasq PD implementation was missing related smarts at first)

    > Delegated-IPv6-Prefix is problematic for obvious reasons. In fact, I, for one,
    > cannot wrap my head around a way to cover both cases (exclude-capable and
    > non-exclude-capable) using only the two existing RADIUS attributes *and* at the
    > same time maintain backwards compatibility with old customers.

If the CPE is not EXCLUDE capable, and not smart enough to avoid the WAN
link, then it doesn't matter what the set of attributes returned is, does it?
Assuming simple minded prefix assignment by CPEs, if they start at subnet
"1", then using subnet "0" probably works.  But, using subnet "ff" for the
WAN link is perhaps simpler.

---

From: Athanasios Douitsis <[email-masked]>
Date: Wed, 20 Nov 2013 16:59:04 +0200

Hello Michael,

When I said "problematic" yesterday, I meant problematic for the delegating
router. If the other side (requesting router - CPE) is not exclude-capable
then is it not illegal for the delegating router to delegate a prefix and
at the same time use part of it to enumerate one its interfaces? So a set
of attributes where the Framed-IPv6-Prefix is contained in the
Delegated-IPv6-Prefix may result in error.

Apologies if I didn't understand correctly what you are saying.

Kind regards,
-- 
Athanasios Douitsis

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2013 11:03:49 -0500

> router. If the other side (requesting router - CPE) is not exclude-capable then
    > is it not illegal for the delegating router to delegate a prefix and at the
    > same time use part of it to enumerate one its interfaces? So a set of
    > attributes where the Framed-IPv6-Prefix is contained in the

How could a BNG know if the requesting router is exclude capable?

Would this by having the option in the DHCPv6 Request list?

If the WAN was numbered by RA, then I guess the DHCPv6 server would have to
do the split prefix in half trick.

---

From: Athanasios Douitsis <[email-masked]>
Date: Wed, 20 Nov 2013 19:07:38 +0200

> Would this by having the option in the DHCPv6 Request list?

Yes. 

> do the split prefix in half trick.

Yes, that was suggested by Jouni previously.