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

[Michael Richardson <[e-mail]>]

Athanasios Douitsis <[e-mail]> wrote:
    > 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. 

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)

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

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.


--
Michael Richardson <[e-mail]>, Sandelman Software Works