| From: Paul Wouters <[email protected]> | 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 addresspool. | 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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
