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

On Nov 19, 2013, at 9:27 PM, Athanasios Douitsis <aduitsis@gmail.com> 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) <robmgl@cisco.com> wrote:
> >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:radext-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Tuesday, November 19, 2013 12:43 PM
> To: Roberta Maglione (robmgl)
> Cc: radext@ietf.org; Athanasios Douitsis; Bernie Volz (volz); Michael Richardson; dhcwg@ietf.org WG; homenet@ietf.org
> Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
> 
> 
> On Nov 19, 2013, at 7:10 PM, "Roberta Maglione (robmgl)" <robmgl@cisco.com> wrote:
> 
> > 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.
> 
> 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 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?
> 
> I would do the check rather than define a new attribute.
> 
> - Jouni
> 
> 
> > Thanks
> > Roberta
> >
> > From: Athanasios Douitsis [mailto:aduitsis@gmail.com]
> > Sent: Tuesday, November 19, 2013 11:50 AM
> > To: Bernie Volz (volz)
> > Cc: Jouni Korhonen; radext@ietf.org; homenet@ietf.org; Roberta Maglione (robmgl); dhcwg@ietf.org WG; Michael Richardson
> > Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
> >
> >
> > On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <volz@cisco.com> 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
> >
> >
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
> 
> 
> 
> -- 
> Athanasios Douitsis
> 
> 