This is a discussion on Re: 7.0-BETA2 routed and multicast registration - FreeBSD ; Marko Zec wrote: > On Saturday 17 November 2007 12:45:34 Bruce M Simpson wrote: >> 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 ...
Marko Zec wrote:
> On Saturday 17 November 2007 12:45:34 Bruce M Simpson wrote:
>> 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.
> 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?
probably we should have the hack, clearly marked and disabled by default.
>> 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
>> 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,
>> [* The Quagga maintainers should know better -- Linux is after all
>> their main development platform, and it has supported RFC 3678 for
>> some time now.]
> email@example.com mailing list
> To unsubscribe, send any mail to "firstname.lastname@example.org"
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"