IPv6 accounting RADIUS SQL schema?

[Michael Ducharme]

OK, thanks, that confirms basically everything I thought. My question 
is, then, since those attributes are so standard with IPv6 RADIUS 
accounting, and they each store different things, why are those three 
fields not already in the database schema? Is it just because nobody has 
submitted a patch (pull request) that adds those three fields into the 
schema and adds the proper queries? Or is it because the developers feel 
that most people aren't going to need them? I might assume the latter, 
but in that event, I'm just concerned that it's going to end up being a 
big mess when it comes to software that integrates with FreeRADIUS/MySQL 
if everybody adds those fields themselves but they name them in 
different ways. For instance, our billing system, which is designed for 
our NAS and integrates with FreeRADIUS/MySQL -- it doesn't support IPv6 
RADIUS accounting yet because our NAS doesn't support it, but our NAS 
vendor is currently in the process of adding support for IPv6 RADIUS 
accounting. Once they add support, our billing system vendor will need 
to read from those three fields in the radacct table, but if all of 
their customers name them differently then you end up with a bit of a 
mess in terms of integration. I can add these three fields myself into 
our instance, but would rather know that those are the same field names 
that others are going to use. Chances are that others will name them 
similarly, of course (it would seem obvious to name them like the 
attributes but all lower case without hyphens) but at least if it is in 
FreeRADIUS by default, I know that that naming is the standard that 
should be used.

I just don't want to be in the position where I am adding those three 
fields on a dozen RADIUS servers, then a year from now someone decides 
to add them to FreeRADIUS as built-in fields but the fields have 
different names, and then for integration purposes I now need to go back 
to all of these RADIUS servers that I set up and rename the fields in 
the database in order for them to work with the third party software. Do 
you understand my concern?

If you say that it is likely that if I add those three fields and adjust 
the queries and submit a pull request that it will be accepted, I will 
do so.

Thanks.


On 8/16/2018 6:55 PM, Alan DeKok wrote:
>> On Aug 16, 2018, at 4:10 PM, Michael Ducharme <mducharme at gmail.com> wrote:
>>
>> Hi Alan,
>>
>> Thanks for the info. However, how does that solution handle dual stack? If client gets both IPv4 and IPv6, a user would want to record both, not just one or the other. Although I am not a FreeRADIUS expert by any means, I looked at the unlang manpage, it looks like that query will store the IPv6 address in the field only if the client is not getting an IPv4 address. If the client is getting both, if I understand the unlang manpage correctly, it will store only the IPv4 and the IPv6 address will go unrecorded.
>    Yes.  That's why I suggested updating the query.
>
>    If you want to add a "framedipv6address" field to SQL, it's simple.  It's just a text file... add another line, and then update the SQL queries.
>
>> Also, if I understand the RFC correctly (and it's possible that I do not), this attribute handles only cases where a single host requests an address via DHCPv6, rather than a router requesting a prefix, or a NAS assigning a framed prefix for SLAAC assignment. If I understand things correctly, these cases would be reported only through Framed-IPv6-Prefix and/or Delegated-IPv6-Prefix accounting. I don't believe those prefixes would be reported in Framed-IPv6-Address?
>    They're different attributes, so no.
>
>> Based on that I had planned to add three new fields into our radacct table in MySQL - one for framed IPv6 address, one for Framed-IPv6-Prefix, and one for Delegated-IPv6-Prefix. Adding three new fields however seems not only a bit messy, it may not be in line with what the developers had in mind, which is why I asked the question.
>    If they're different... they should be recorded.
>
>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html