Re: ifconfig v2

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> You seem to think [renumbering] would have been trivial, or at least
> 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.

Odd, then, that it caused me no maintenance headaches at all.  Or at
least none that I can remember now; it's been many years, but I think I
would have remembered anything I could reasonably ascribe to the
non-contiguous netmask.  Even then I knew I was in relatively untested
territory doing that.

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

I didn't feel it needed any answer beyond what I wrote in my other list
post.  I see two immediately obvious possibilities ("pick one" and
"send to all"); there are doubtless plenty of others.  It's a matter
for local policy, even if that policy is to abidcate responsibility to
"whatever this implementation happens to do".

>> That depends on your implementation.
> Which implementation?  There are likely to be several different ones.

Which implementation?  The one being run on the machine where that
packet send occurs, or which handles the routed packet in question, of
course.  Which other one could possibly be relevant?

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

I don't see any need to nail it down.  Let different implementations
experiment with support for different algorithms; maybe standardize if
one clear winner emerges, but, even if not, so what?  I see no need to
have prescribed behaviour nailed down in all possible cases, especially
when there is no "rough consensus" to standardize on.

In fact, about the only thing that strikes me as stupider than that in
a case like this is forbidding experimentation. :-)

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

Yes.  On an implementation that doesn't take pains to do any particular
thing when faced with a configuration like that, it becomes "don't do
that, then".  Unix has never had a shortage of brain-dead ways to
configure a system; I see no need to pay this one any particular mind.

>> 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; [...real masks vs widths...]
> Internally, yes of course, but they don't need to be visible anywhere
> outside the guts of the routing/forwarding code.

My point is that it is very hard to _not_ invent noncontiguous
netmasks, even if only within the kernel, even if only as unrealized
potential.

Indeed, given the generality of the routing table code, I suspect
noncontiguous v6 netmasks might well work if a way existed to set them.
(Well, work as well as v4 noncontiguous netmasks do, at least.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B