2.x.x and radtest: no IPv6?

[Phil Mayers]

On 22/07/13 14:32, Arran Cudbard-Bell wrote:
>
> On 22 Jul 2013, at 14:15, Phil Mayers <p.mayers at imperial.ac.uk>
> wrote:
>
>> On 22/07/13 13:47, Arran Cudbard-Bell wrote:
>>>
>>> It'd be nice to get some feedback from people though... do you
>>> think you'll ever need to record both your NAS IPv4 and IPv6
>>> addresses?
>>>
>>> I'm guessing for dual stacking it'd be nice to record
>>> Framed-IP-Address and Framed-IPv6-Prefix, should they both be
>>> used to identify clients in areas like session management? It
>>> seems like the safest way of doing it to me.
>>
>> Yes. It's important to record them separately, and useful for the
>> reasons you suggest.
>
> For the NAS too? Or would it be OK to have a single attribute?.

Good question. Not sure on that one - I think most NASes treat an IPv4 
and IPv6 RADIUS server as a separate server, so I guess treating it as a 
separate client is no big problem. OTOH two columns == less rows for 
dual-stack NAS.

My guess is dual-stack NAS->RADIUS is going to be rare.

>>> But would it break things? What if the NAS started just using the
>>> SRC IPv6 address in packets, and source IP protection was
>>> enabled? Does this happen in the real world?
>>
>> Not sure I follow here; can you expand on this?
>
> Envisaging use in session identification. If the NAS was dumb, and
> was just looking at packets coming from one of it's directly
> connected devices, and pulling off the SRC IP address and using it to
> enrich Accounting-Requests, you may have that IP change during the

Ah, gotcha.

> course of a session.

Some NASes already do something similar with Framed-IP-Address only 
being present in some acct packets. We handle this with:

update radacct set
  ...
  framedipaddress=coalesce(nullif('%{..}', ''), framedipaddress)
  ...

...which is basically "use the IP from the packet if set, or on the 
existing row if unset"