RFC 1519 / RFC 4632 — Require contiguous netmasks

[rye]

Conceptually, it's possible to have non-contiguous netmasks when you're building networks.

Some background I've found during research:

• IETF RFC 950 (1985) specifies that contiguous netmasks are not a requirement. Explicitly,

  Since the bits that identify the subnet are specified by a
  bitmask, they need not be adjacent in the address. However, we
  recommend that the subnet bits be contiguous and located as the
  most significant bits of the local address.

• IETF RFC 1519 (1993) (superseded by IETF RFC 4632, 2006) seems to require contiguous netmasks instead, though:

  An implementation following these rules should also be generalized,
  so that an arbitrary network number and mask are accepted for all
  routing destinations. The only outstanding constraint is that the
  mask must be left contiguous.

This comes down to a question of intention. I intend for this crate to be used in any networking scenario, and with this scope corner cases abound. I could foresee a network operator deciding that—despite it being a terrible practice—using non-contiguous netmasks is a good idea, and they might want to check only a certain subset of the netmask. The question at hand is: is it even feasible for non-contiguous netmasks to be specified?

• On the public internet, the answer is no. Since allocations are now based on left-contiguous netmasks only (per RFC1519 and 4632), it's not really possible to get something other than a /xx.
• But in the private space, the answer is maybe. For example, what if I (as the operator) wanted only to give out DHCP leases that were odd-numbered, within a subnet? Or noncontiguous groups of devices? There's nothing stopping me from doing so.

The problem is that supporting noncontiguous netmasks means we cannot use standard traits like core::ops::RangeBounds. Users might expect those to be implemented, or might not care very much.