Re: HEADSUP: arp-v2 has been committed

Hi Ian,

Well, yuletide and new year is a good time to clean out the cupboards, 
so... without further ado...

Ian FREISLICH wrote:
> ...
>> Do you have applications which do not explicitly specify the interface 
>> address to use for multicast group joins?
>>
>> If they do not,  that's a bug in the application -- IPv4 and IPv6 
>> multicast *requires* that a link be specified somehow, either using the 
>> new APIs which take an ifindex, or an IPv4 "primary address".
>>     
>
> quagga does specify the ifindex passed in a struct ip_mreqn in the
> imr_ifindex member to setsockopt, which reading the documentation
> should be sufficient, yet it is not.  I have checked that it does
> set the correct ifindex.   Setting the IP address in the imr_address
> member of the same struct correctly chooses the interface.
>   

I seem to remember there was some breakage in Quagga after the 
introduction of in_mcast.c over 18 months ago.

I did make a patch available for using the new MCAST_JOIN APIs for the 
Rhyolite.com routed, but for whatever reason, the necessary changes 
didn't get incorporated upstream into Quagga.

This is despite their reference platform, Linux, having supported these 
APIs for many years.

The APIs in question are well covered in the literature (UNIX Network 
Programming 3e) and RFCs which were published over 3 years ago, it seems 
regrettable for Quagga to not have incorporated/tested these changes -- 
despite Microsoft Windows, Linux and MacOS X having supported the APIs 
for some time.

Of course, that said, I'm not a Quagga developer, and have no formal 
relationship, fiscal or professional, with that project.

My door has always been open to guide and advise how to fix their code 
to move with the times, and I certainly don't bill for advice given with 
warmth.

The impression I got from their response to this was that they perhaps 
saw me as someone throwing a rulebook at them, which is hardly the case, 
I just want IP multicast to work properly across the board.

>   
>> Unfortunately there has been historical breakage in the multicast APIs. 
>> There are some apps which run before all interfaces have been ifconfig'd 
>> up in the system, and they need to create multicast sockets.
>>
>> The kernel behaviour you describe is historical and I had to reintroduce 
>> it to avoid breaking such applications. It is a kludge which we probably 
>> can't retire until their developers fix their multicast apps to be aware 
>> of multiple interfaces on the system.
>>     
>
> Is this the BSD struct ip_mreq hack?  This particular code isn't
> using that.
>   

No. This is when applications issue IP_ADD_MEMBERSHIP on a socket whilst 
specifying an IP address of 0.0.0.0 (i.e. INADDR_ANY). This is 
officially unsupported behaviour.

What most implementations try to do, is to treat this as meaning "I want 
this socket to join the group on the interface pointing towards the 
default route". If there is no default route, then the first multicast 
capable interface in the system is used.

Please see src/sys/netinet/in_mcast.c change history for full details.

I'm sure you can understand this leads to comedy of errors if there are 
multiple default routes, and FreeBSD is fast hurtling towards equal-cost 
multipathing support.

Unfortunately apps which want to run before IPv4 addresses have been 
configured still try to do this.

This was accepted practice before IGMP was further formalized as a 
protocol, but it stems from an apparent misunderstanding of how IPv4 
multicasting actually works.

This isn't a problem with IPv6, because MLDv1 and MLDv2 specs both 
require that the link-scoped address is used for multicast group 
memberships.

Most implementations, including FreeBSD's, will choose the first IPv4 
address ('primary address') configured on the link as the source address 
for all IGMP control traffic.  Removing the address selected for such 
traffic will break IGMP and lead to inconsistent membership reports 
being received by the upstream IGMP querier.

There is currently no clean way to deal with the IGMP endpoint address 
problem in the FreeBSD implementation. I believe from memory that Linux 
has the same issues.

If you look at the Microsoft implementation, Dave Thaler and his team 
did a lot of good work on bringing Windows up to speed with where their 
stack needed to be. There are reasons why Windows is being used as a 
multicast media delivery platform where Linux and FreeBSD aren't, and 
that's just one of them.

Whilst I would love to fix it all, time resources and motivation are 
finite, and developer focus tends to go where the bread-and-butter is -- 
that's just how the world is.

thanks,
BMS