Re: 7.0-BETA2 routed and multicast registration

Marko Zec wrote:
> Note that with a recent port of Quagga multicast doesn't work as well, 
> so now we don't have neither RIP nor OSPF support there which is kind 
> of funny.  Though I think it's not only the missing RFC1724 support in 
> the kernel that is crippling mcast support in Quagga...
>
>   

We all know that major point releases are the place for changes like 
this to happen.

It's been over 6 months since these changes were committed, and heads-up 
messages were sent to the appropriate lists. I guess the bigger question 
is, why is this a problem now?

The reasoning behind the change is quite clear, to support IP multicast 
in new network environments, e.g. mobile and ad-hoc IP, as well as 
supporting source-specific multicast, we SHOULD be following a published 
API which supports those environments, rather than relying on a hack 
which was clearly only ever intended as a temporary workaround, and 
highly specific to FreeBSD's IP implementation.

RFC 3678 specifies such an API. It is over 3 years old. Andre had given 
backing to deprecating the 0.0.0.0/8 hack when I announced my intentions 
on -net.

Also, supporting a published API brings FreeBSD back up to par with its 
competitors in this area (i.e. Linux, Windows). Otherwise, we perpetuate 
a kludge at the expense of progress in other areas of IPv4/IPv6.

If you check the archives for -current you'll see that Ian Frieslich had 
contacted the Quagga maintainers about the change, the outcome of this 
discussion I don't know. 3rd party applications are beyond FreeBSD's 
control, or mine, for that matter. [*]

I did however spend time on routed support, which I am happy to do as it 
hasn't been moved to ports (it is still part of the base system), and 
made it clear that this patch was available to work from, and that 
people were most very welcome to contact me about the matter to get RFC 
3678 support into these applications.

Now, my situation is not so free and fluid, as I am in the thick of a 
new project and have sadly little free time as it is to do work outside 
the scope of that project.

If we collectively are satisfied that this change is a change too far on 
this occasion, then I retract my objection to ip_multicast_if() being 
re-imported, on the grounds that its deprecation has inadvertently 
broken user applications, on the grounds that 6 months was, apparently, 
not enough notice for the maintainers of these applications to take action.

However, I register a very strong technical objection to this patch on 
the grounds that this is an area where open source networking needs to 
move ahead. POLA wasn't violated on this occasion, as the scope of the 
work happened entirely within -CURRENT, and the appropriate individuals 
were notified of the changes.

These are the facts as I see them, I am very happy to hear feedback from 
others.

Sadly I can't get actively involved in proactively fixing the situation 
at the present time i.e. at the level of code, and besides... that's 
going to require communication and coordination between all the people 
involved, the lack of which it seems has created an unnecessary situation.

very best,
BMS

[* The Quagga maintainers should know better -- Linux is after all their 
main development platform, and it has supported RFC 3678 for some time 
now.]