[Swan-dev] virutal-private [was: overlapping address pools]

D. Hugh Redelmeier hugh at mimosa.com
Tue Apr 22 04:18:07 EEST 2014

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

| On Mon, 21 Apr 2014, D. Hugh Redelmeier wrote:

| > There are two virtual-private subnet lists: inclusive and exclusive.
| > An address is considered private if it is covered by at least one
| > subnet in the inclusive list and no subnet in the  exclusive list.
| >
| > No consideration is given to overlap.
| What overlap are you thinking of?  The most common case is like:
| 	virtual_private=%v4:,%v4:!
| I guess this is not the overlap you mean? should get
| rejected here, but would not get rejected.

That example is fine.

No addresses are private in this case.  I imagine that that surprises

In this one, the /24 will not have an effect.

| If multiple includes overlap, why would we care as long as we match it?
| If multiple excludes overlap, why would we care as long as we match it?

any matching exclude (no matter how broad) trumps any include (no
matter how narrow).

| > It seems to me that the conventional test would be:
| >
| >    What is the smallest subnet that includes the address in question?
| >    If it is in the inclusive set, the address is private.
| I believe that is already they case? See the above example.

No.  See the above example :-)  And read the rule I gave (top of this 

| > Also, it would seem to be a mistake to have the same subnet appear
| > twice or more (either in the same or different lists).  This would be
| > a mistake in the lists.
| Seems a pretty harmless mistake. We could ignore the second one and log
| a warning. Causing an error seems excessive and might break things.

It seems pretty harmless unless there is one in each list.  Which
takes priority?  The answer is easy right now: the one in the exclude
list wins.  If we change to "narrowest wins", then the issue comes up.

Note: I don't see a disaster here, only an awkwardness and a surprise.
My guess is that most virtual-private specifications are simple and
don't hit this lack of expressive power.

More information about the Swan-dev mailing list