Add netmask support to IpTunnel

This pull request introduces two new config options for `allowedConnections` entries: `ip4Prefix` and `ip6Prefix`. These hold the prefix/netmask length that the IpTunnel client should use on the IPv4/IPv6 address assigned by the server. These are sent over the wire to the IpTunnel client, and replace the hardcoded prefix length of 0 (or 3 on Mac) which was used before.

This change is backwards-compatible; older IpTunnel clients will ignore the extra dict entries, and clients connecting to older servers will default to a prefix length of 0 (or 3 for IPv6 on Mac).

This change allows a server to advertise a whole IPv4 private network (like say 192.168.33.0/24) and have clients automatically send packets for that network to the server without the client having to manually add any routes. The same works for IPv6 networks that might not necessarily want all a client's IPv6 Internet traffic, and an `ip6Prefix` of 0 (which is the default if none is specified) retains the old behavior of gobbling up all a client's IPv6 traffic (at least if it doesn't have IPv6 connectivity already).

An `ip4Prefix` of 0 does not seem to do the same (my Linux system seems to think the interface is doing something P-t-P-related), but the behavior isn't different from when the IPv4 prefix length was hardcoded to 0.
I don't think that that is what's currently being configured. My reading of
the original code has it giving a 0 prefixLen, or 3 for OS X, for both IPv4
and IPv6. Am I missing something? I'll look again...

I could definitely make /32 the default to send if unconfigured or to use
if none is received.

On Fri, Nov 7, 2014 at 3:11 PM, Caleb James DeLisle <
notifications@github.com> wrote:

> In tunnel/IpTunnel_admin.c:
>
> >                                              (ip4Address) ? &ip4ToGive.addr : NULL,
> > +                                            (ip4Prefix) ? (uint8_t) (*ip4Prefix) : 0,
>
> I feel like if the server updates and makes no change to their config, we
> should send a /32 since that's what is currently being configured, does
> this make sense to you?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cjdelisle/cjdns/pull/692/files#r20044208>.
>