From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 23:53:15 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B85316A409 for ; Tue, 20 Mar 2007 23:53:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD2113C4D1 for ; Tue, 20 Mar 2007 23:53:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 8E1DD209C36 for ; Tue, 20 Mar 2007 19:53:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Tue, 20 Mar 2007 19:53:12 -0400 X-Sasl-enc: zKBM5X7r3Iuk4QKeSgJSLrmO0ajgkpp+sFagMGZZiHxn 1174434794 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id AC28810E92 for ; Tue, 20 Mar 2007 19:53:14 -0400 (EDT) Message-ID: <460073E8.2080803@incunabulum.net> Date: Tue, 20 Mar 2007 23:53:12 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Proposal: Merge RFC3678 multicast APIs 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: Tue, 20 Mar 2007 23:53:15 -0000 Hi, I propose that we merge the RFC3678 advanced multicast APIs. Doing so gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions about how to deal with the include header issue below. I have already started merging the basic definitions into p4 branch bms_netdev. Background: * RFC3678 specifies user and kernel APIs for any-source and specific-source multicast for IPv4, IPv6, and protocol-independent use. * this includes struct ip_mreq_source and friends * SIOCSIPMSFILTER and SIOCGMSFILTER are historical and may be ignored. Impact: * It requires that struct sockaddr_storage is visible to . * This change breaks the following files in the kernel: in4_cksum.c inet_ntoa.c ip_ecn.c in6_cksum.c in_cksum.c slcompress.c ...which do not include where this structure is defined. Benefit: * We get the SSM API. We don't support IGMPv3 or SSM yet, but this is part of the work. * Better to do this now and incrementally; the IGMPv3 implementations out there for FreeBSD have been published as patch sets which are now bitrotting. * This lets us eliminate the ugly RFC1724 hack from the IPv4 stack, which is used to specify an outgoing IPv4 multicast interface by passing a 24-bit interface index in the host portion of a 0.0.0.0/8 address. * This behaviour is not portable; Microsoft Windows Vista uses the full 32-bit wide interface index space in both its IPv4 and IPv6 stack. No snickering from the gallery please -- Dave Thaler has done excellent work bringing the MS stack closer to IETF standards. * routed uses this; it can be patched to not do so; the RFC3678 API for this is to use the generic MCAST_JOIN_GROUP socket option which accepts an interface index as an argument in struct group_req. * Linux defines a struct ip_mreqn as a workaround for applications using the pre RFC3678 API. Inside the kernel it maps IFA to IFP when handling IP_ADD_MEMBERSHIP, thus avoiding the 0.0.0.0/8 hack. See ip(4) in HEAD for the polite rendering of my rant about doing IGMP correctly and its implications for addressing in the IPv4 stack (short: you need an IP address for it to work properly, and source address selection, or IPv6, is looking like a really good idea in a wireless/manet/mobile/ad-hoc world). Regards, BMS