This is a discussion on Re: 7.0-BETA2 routed and multicast registration - FreeBSD ; 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 ...
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
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
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.
[* The Quagga maintainers should know better -- Linux is after all their
main development platform, and it has supported RFC 3678 for some time
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"