Re: ifconfig v2

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 12 Jun 2013 18:36:05 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201306122236.SAA20580%Chip.Rodents-Montreal.ORG@localhost>

  | Only at the price of using addresses assigned to other people.

Yes, the network needs a consistent addressing plan, which
should be decided, and implemented, by the network manager.

  | (Well, and, it'd be 240 in the last octet of the mask, not 224.)

Arithmetic was never my strong point, clearly I miscounted the number of 1's...

  | You seem to think that would have been trivial, or at least easy;

Not at all (and you come back to that point again later, I won't
duplicate the reply...)   I know renumbering can be difficult, though in
a /24 it is generally tractable.  As you suggest, I've been involved in
this more than once, and I know what's involved.  The point was that it
is a one off (even if it takes a few intermediate steps to accomplish, and
gets spread out over some time) - on the other hand, using a non-contig
mask is a forever decision, it causes maintenance headaches for the rest
of eternity.   Renumbering is certainly a more painful course to take
than the costs of dealing with a non-contig netmask right now, but when
you add up all the costs, over the years (people making mistakes with
config, difficulties spotting which subnet as it isn't obvious, ... lots
and lots of little things, over and over again - especially as personel
changes) and almost always the one off renumbering will turn out to be
the lesser evil.


  | > the real question is what happens when someone sends to 1.2.1.1 ?
  | Or any of the 15 other addresses which are on-net for each interface.

yes, of course.   And I note that you didn't answer...

  | That depends on your implementation.

Which implementation?  There are likely to be several different ones.

There never was any thought seriously given to how this should work (back
when this was being discussed, we did try to come up with a definition for
how it should all work ... and failed)

Attempting to seriuously use stuff which is "however the implementation
decides to do it" is seriously a brain dead choice.

  | But I actually think that, as long as they're spoken of as masks, the
  | possibility of noncontiguous masks is obvious, or at most only barely
  | latent; if nothing else, someone will make a coding mistake and
  | generate, say, 255.255.7.0 instead of 255.255.224.0 somewhere.

Sure, so (as v6 does, or should be doing, as non-contig is definitely not
supported there) the config code should check for invalid values and
reject them.   The test is easy.

  | To avoid that, you'd really need to store them as widths instead of masks,

No - you could just have the config be a width, but then calculate the
mask and use that (which is how v6 gets done, though the calc is done in
userland so a broken program could do odd things, or attempt them, I have
never looked to see if the v6 kernel code checks the masks for sanity) or the
code can just check the mask when it is assigned, and reject bad ones.

  | which is inconvenient enough to use that using real masks is an obvious
  | optimization.

Internally, yes of course, but they don't need to be visible anywhere
outside the guts of the routing/forwarding code.

kre