2.x.x and radtest: no IPv6?

Phil Mayers p.mayers at imperial.ac.uk
Mon Jul 22 16:14:25 CEST 2013

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"

More information about the Freeradius-Users mailing list