7.0-BETA2 routed and multicast registration

Bruce M Simpson bms at incunabulum.net
Sat Nov 17 08:49:17 PST 2007

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

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!


More information about the freebsd-current mailing list