[Swan-dev] addresspool and handing out network/broadcast addresses

Paul Wouters paul at nohats.ca
Sun May 4 22:54:55 EEST 2014


On Fri, 2 May 2014, D. Hugh Redelmeier wrote:

> | subnet=192.0.2.0/24 while also handing out 192.0.2.x/32 addresses.
>
> No, not from the address-pool address range, but from the LAN we
> ourselves are probably on.

No, this one had a left=%defaultroute with rightsubnet=192.0.2.0/24,
and would then get an addresspool range from  192.0.2.0-192.0.2.255,
so it would setup a tunnel from 192.0.2.0/32 to 192.0.2.0/24. Pretty
atrocious IMHO.


> And likely we
> know the IP address of various furniture within that subnet
> - broadcast
> - gateway
> - local DNS server
> - IP addresses given out by DHCP
> - print server IP address
> - addresses already occupied (based on ARP traffic)
> - ...
>
> How far do we wish to go down this rathole?

SunOS basically ruined .0 and we shouldn't hand out a broadcast address.
That's as far as I want to go.

> (It sure would be nice if the warnings were apparent to our users, but
> that's another issue.)

We can do that using dbus and NM. Once we have native dbus support, we
can ensure everything that's RC_SERIOUS goes to whack as well as
dbus/NM.

> If it is our job, why even have them specify an address-pool?  We can
> make it up ourself.

Because the addresspool could be routed/reserved locally with the rest
of the network. You know this :P

> I'm against kludgy software full of heuristics that might break in too
> many interesting ways.
>
> Blocking 0.0.0.0/0.0.255.0 and 0.0.255.0/0.0.255.0 seems arbitrary.
> Doesn't even work for my network, and I have a Class C.

I'm suggesting to block *.*.*.0 and *.*.*.255 irrespective of netmask.
This of course only prevents network/broadcast addresses for the "class
A, B and C" networks. Perhaps we can assume people using differently
sized pool know enough about network/broadcast address to exclude these.

Although we could attempt to convert the range to CIDR and find out if
we understand the broadcast/network address, we might not be able to
know if they specify a random section, eg 192.0.2.14-192.0.2.139.

> | And if we allowed CIDR syntax, we per definition have this problem too,
> | eg: leftaddresspool=192.0.2.0/24 - you cannot really exclude it using
> | that syntax.
>
> Sure.  But we don't support CIDR syntax for an address-pool.  Maybe
> this is a good reason not to.

If we do allow CIDR, we should again blacklist the first+last address of
the pool to avoid problems.

Paul


More information about the Swan-dev mailing list