I take more time out of the weekend to shout about legacy kludge...

We can put a nice big comment in that says "this is an old crusty hack,
it is NOT SUPPORTED for new code", but it's better not to have kludges
there in the first place.

We can bring it back in the 7-current train to keep folk happy for now,
sure, but I strongly suggest we get rid of it in future, otherwise, we
risk not taking the step of progress -- EBIKESHED.

If ye wish to know more, read on.

Marko Zec wrote:
> Nobody is questioning the benefits of having RFC 3678 support added to
> the kernel, but quickly skimming through that document I can't find a
> line stipulating that it should deprecate older interfaces already in
> use. What is the exact benefit of deprecating the 0.0.0.0/8 hack (i.e.
> RFC 1724 compliant ifnet addressing), i.e. why couldn't we have support
> for both the new and the old interface for legacy applications, given
> that the interfaces don't seem to be in conflict?
>


They aren't mutually exclusive.

However, sometimes the only way to get people to sit up and take notice
about the finer things in life is to wave a black flag -- even if this
happens 6 months after something actually occurred -- because I can't
compel or use force to make anyone to agree with me, so I have to resort
to other methods, like being irritating to others.

It is a crusty old hack that creates yet another special case in a bunch
of kernel code. It gives special meaning to the first eight bits of an
IPv4 address which happen to be zero. It ain't elegant. RFC 1724 was
only ever intended to be specific to RIP.

This is just not the right way to support unnumbered interfaces in IPv4.
In fact, if you look at Linux, they already dealt with this problem by
implementing scoped IPv4 addresses in-kernel -- too many bits of IPv4
depend upon having an address on a link, such as sockets, routing
protocols, IGMP, hence Stuart Cheshire coming up with RFC 3927.

Which is why I backported their answer to the problem in the legacy API
-- ip_mreqn. I encourage everyone to look at the patch:
http://people.freebsd.org/~bms/dump/...sm_phase1.diff

I draw everyone's attention to the comment re the use of the ip_mreqn
structure, clearly visible at the top of this patch.

In short, it needs to go. I realize this is an argument that mostly
appeals to those who don't follow the Law of Excluded Middle in logic,
but, sometimes that's the way the cookie crumbles.

Open source often serves as an example for how to do things, and the
code that is there is sometimes accepted as gospel, particularly by
students, who might not always question its wisdom or lack thereof; and
this is another thing that I'm getting at.

Of course anything that comes out of my mouth is, mutatis mutandis,
subject to the same judgement. If I ain't in trouble, I ain't doing my job!

best,
BMS
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"