IPv6 accounting RADIUS SQL schema?

[Nathan Ward]

> On 19/08/2018, at 6:57 PM, Michael Ducharme <mducharme at gmail.com> wrote:
> 
> On 8/18/2018 10:49 PM, Nathan Ward wrote:
>> If this would be the approach then I think it’s best left as examples of what could be done, rather than change the standard schema - a standard schema needs to support 0+ of each of the fields you suggest here, not simply 0-1. 
> There *needs* to be a standard schema for IPv6 soon, the billing system we use does not support IPv6 RADIUS accounting yet mainly because there are no standard FreeRADIUS/MySQL field names to read the data from (hence the reason for my question and my pull request). How can I get our billing system vendor to support IPv6 RADIUS accounting in FreeRADIUS/MySQL when there are not even standard fields for storing this data?

I would query why that data is in your billing system, but, I’m sure you have your reasons.
Generally I prefer to expose data to “external” systems through APIs, rather than give them direct database access and tightly couple two applications together though a DB schema which may need to change for one side or the other.

> And, regarding 0+ instead of 0-1, even though the attributes may technically be usable multiple times, how often does this happen in practice? I would expect extremely rarely, based on what I have seen, especially in an automated sense. If there are multiple Delegated-IPv6-Prefix attributes, chances are that it is not due to an automated system but instead due to RADIUS assignment of Delegated-IPv6-Prefix, and that case is like the IPv4 Framed-Route attribute. If Delegated-IPv6-Prefix is assigned via RADIUS from the beginning, then at least there is a record that that prefix was assigned to that customer besides the accounting record.

> I just don't want this to turn into a "lets do nothing" situation, due to a few potential corner case situations, because then nothing is going to happen.

I don’t think this is a hard problem to solve in a more flexible manner. Given that, I think we should do so.

--
Nathan Ward