Re: 7.0-BETA2 routed and multicast registration

On Sat, 17 Nov 2007, Bruce M Simpson wrote:

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

Speaking of deprecated -- are the interfaces marked as deprecated in the 6.x 
man pages?  If not, there's a reasonabl argument to be made that they weren't 
deprecated, only eliminated. :-)  At this point, in the interest of shipping 
working apps, it's sounding like we may need to re-add the interfaces to 7.x 
with clear deprecation markings.  I'm not sure I'd go for Julian's suggestion 
of a sysctl, which simply makes things that should be easy harder for our 
users, as opposed to third party developers.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> 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/ssm_phase1/ssm_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
>