Re: 7.0-BETA2 routed and multicast registration

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?

Marko

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