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

[D. Hugh Redelmeier]

| 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:10.0.0.0/8,%v4:!10.0.0.0/24
| 
| I guess this is not the overlap you mean? 10.0.0.2/32 should get
| rejected here, but 10.1.2.3/32 would not get rejected.

That example is fine.

Consider
 	virtual_private=%v4:!10.0.0.0/8,%v4:10.0.0.0/24
No addresses are private in this case.  I imagine that that surprises
you.

Consider
 	virtual_private=%v4:10.0.0.0/8,%v4:!10.0.0.0/16,%v4:10.0.0.0/24
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 
message).

| > 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.