ipaddr, ipv4addr ipv6addr

[Alan DeKok]

Brian Julin wrote:
> Going way out on the limb of conjecture here, when I get back to working
> on DDDS, the part I haven't even begun to tackle yet is that the server
> is expected to dynamically determine IPs from DNS.  This will require
> a rather extensive rewire of the internals, which gets a bit messy when
> you have ongoing EAP conversations during a DNS change that alters
> either the availability or weightings of servers in a server pool, since
> some sort of server affinity mechanism needs to override the DNS
> for existing conversations for a grace period.

  The cache module should be able to take care of that, I think.  It
should cache the destination home server, and re-use that for the next
packet.

> For home servers, the conjectural behavior when DNS fails for
> all servers in the pool would be an empty pool would be brought up, so
> the server would still start, but would behave as if it had no non-dead
> servers in that pool.  Then things would start working when DNS started
> working again.

  That isn't the issue.  The issue is that DNS failures can take 30s to
time out.  So the server will be down for 30s... potentially for each
DNS lookup.  That's bad.

  The solution is to delay the DNS lookups until some later time.
But... when?  And how long does it keep retrying?  Does that go into a
child thread?  If so, how does it update the structures in the main thread?

>  Also as far as AAAA/A records it would try both unless
> told otherwise, so worst case there is we end up load balancing needlessly
> between the A and AAAA sockets on the same server, or having
> a useless marked-dead home server hanging around for one of the
> address records if ipv4 or ipv6 were broken.

  And when some DNS admin (i.e. non-RADIUS) adds another A record
without telling you... the proxy is suddenly going to be trying an
address which has no RADIUS server.

  The failure cases for DDNS lookups are many, and hard to get right.

> For clients I haven't thought much into that, because validation of incoming
> requests in the use case for DDDS relies on PKI/realms.

  That's a lot easier, TBH.  When clients use certificates, you really
don't care what the source IP is.

  Alan DeKok.