[Swan-dev] overlapping address pools

D. Hugh Redelmeier hugh at mimosa.com
Mon Apr 21 04:31:07 EEST 2014

| From: Paul Wouters <paul at nohats.ca>

| On Sun, 20 Apr 2014, D. Hugh Redelmeier wrote:
| > Each conn can have an address pool.  If two conns' address pools are
| > identical, they are shared (a single common pool).
| Sounds good.
| > If two address-pools overlap, but not exactly, each pool is separate in
| > the addresspool logic: each pool could allocate the same address without
| > being aware of it.
| I think that's a bug.

I agree.  Loading a conn that tries to do this should fail.  That way
we have won't get into an inconsistent situation inside Pluto.

| However, what happens when one client using 1 ID connects to both conns?
| Does it get the same IP or is it "taken"? I don't care much as long as
| we handle this case without causing server errors.

Within a single pool, a single client ID will get a single IP address
across all connections that share that pool.

If connections use different pools, the same ID will be given
different IPs through each pool.

Note 1: Currently, the unique ids setting has no effect on this
behaviour.  Perhaps !unique ids should change behaviour.

Note 2: if the ID is ID_NONE, the rules are different.  We cannot tell
if two things with ID_NONE are the same or different.  So (I think) we
act as if every one is different.

Note 1, meet Note 2:  It seems to me that the !unique ids setting
should make all IDs behave like ID_NONE.  This might not be useful.
So perhaps !unique ids logic isn't useful in the context of

| The alternative is to have pools completely disjoint from connections as
| their own "entities".

My model is that pools are distinct entities.  They are identified by
their IP range: different ranges are different pools.  Connections
share a pool if the pool ranges they specified are identical.

| I
| am all in favour or a simple solution, and if it gets too complicated to
| hand the job over to something else (eg Radius / Diameter or dhcpd)

I don't know what they can do, but I agree with the sentiment.

More information about the Swan-dev mailing list