On 22/07/13 14:32, Arran Cudbard-Bell wrote:
On 22 Jul 2013, at 14:15, Phil Mayers <p.mayers@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"