From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 20:10:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3128416A41A for ; Sat, 12 Jan 2008 20:10:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id E51A713C478 for ; Sat, 12 Jan 2008 20:10:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id AEF7587617; Sat, 12 Jan 2008 15:10:58 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 12 Jan 2008 15:10:58 -0500 X-Sasl-enc: ptZIH/64VejXG+gTzBY6o3Pwjf4mRrKZEM3Bf+07Gkgq 1200168658 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2EDCD6310; Sat, 12 Jan 2008 15:10:58 -0500 (EST) Message-ID: <47891ED1.6070506@FreeBSD.org> Date: Sat, 12 Jan 2008 20:10:57 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Fredrik Lindberg References: <47889F53.4010605@shapeshifter.se> <4788B90A.2080901@FreeBSD.org> <4788DDAB.7080408@shapeshifter.se> In-Reply-To: <4788DDAB.7080408@shapeshifter.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unexpected multicast IPv4 socket behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 20:10:59 -0000 Fredrik Lindberg wrote: > > I would expect this _without_ IP_MULTICAST_IF set, however as I said > the interface had been explicitly set with IP_MULTICAST_IF in all 4 > cases, so there indeed is enough information in the stack to send > the packet. Correct. You found a bug. Well done. > > If IP_MULTICAST_IF should be considered legacy, I'll move away from it. > But, as you said, there is probably a lack of knowledge on how the > APIs should be used and I have never seen anyone or any document > (maybe I haven't looked hard enough) that suggests that this usage is > deprecated. The fact that IPv4 multicast sends appear to work using the default route is a historical quirk. It is not multicast forwarding. For a host/endstation, the mere fact that the group was joined on a given socket, on a given interface, should be enough IP layer reachability information for the inpcb layer to figure out where to send the packets. From that point on, it's the problem of the multicast routers on the path between the end-station and the other members of the channel, which are normally speaking PIM-SM. If one follows how IGMP works, then the problem with multicast joins which are not scoped to an interface is readily obvious. IGMP/MLD is necessary to inform upstream routers that the channel is being opened -- otherwise, you will not receive traffic for the group, as the state about the end-station's participation in the channel is never communicated to routers. The endpoint address used by the local end of the path in MLD is the link-scope IPv6 address. In IGMP, it's the first IPv4 address configured on the interface. Both IGMP and MLD are always scoped to the local link -- they deal with multicast forwarding and membership state ONLY in the domain of the link they are used on. IPv4 has historically not had link-scope addresses, which are one possible answer to the problem. Ergo there is a problem if the interface is unnumbered -- or if the inpcb laddr is 0.0.0.0 -- which you have seen. It should be possible to use IP_MULTICAST_IF as a workaround for this, however, you found that path is buggy... I guess the textbooks out there haven't caught up with reality. > > I wouldn't expect anything in 224.0.0.0/4 to fail > _with_ IP_MULTICAST_IF set. Correct. This makes the bug even more damaging. It is reasonable for a system to be using multicast during early boot when all interfaces are unnumbered. In fact the IGMPv3 RFC suggests no IGMP traffic should be sent for groups in 224.0.0.0/24, becuase upstream IGMP routers should never be forwarding these groups between links. Unfortunately, in practice, this can break layer 2 multicasts for these groups which traverse IGMP snooping switches. > > IP_SENDIF/SO_BINDTODEVICE seems to show up from time to time, is > the only reason that it hasn't been implemented simply that nobody > has done it? Yup. Everyone seems to be too worried about unicast traffic and bulk I/O performance to bother much with other applications of IP, so, this sort of issue gets more airtime elsewhere. later BMS