Subject: FreeBSD and default IP Multicast support

From: Amancio Hasty <[email-masked]>
Date: Tue, 23 Jun 1998 20:39:14 -0700

Got curious as to what was the latest as to why our default kernels 
are not being compile with IP Multicast enabled. 

Fortunately, in FreeBSD land is very easy to compile a kernel or 
to build ip_mroute_mod loadable kernel module.

After my recent failure to locate an ISP which supports both ADSL and
MBONE in *Silicon Valley*  I can't blame Jordan for being upset.

	Cheers,
	Amancio

 "Jordan K. Hubbard" <[email-masked]> :
>> Any reason why MROUTING is not enabled in the default kernel
>> configuration.

> Sure.  Because for 99% of the userbase, it would only constitute
> unnecessary bloat.  How many here out of the some 10,000 readers of
> this list are using multicast?  100?  500?  You don't need to respond
> with a yes/no on this (please don't! :), my point simply being that
> it's a small fraction of the user base and even those who really want
> to run multicast these days still often find themselves blocked
> upstream by ISPs who DON'T want to run multicast traffic. :-)

> I've also never heard any complaints from the remaining 1% that it was
> difficult to enable or anything.  If you're clued-in enough to even
> know how to get multicast traffic at your site, you probably also know
> how to compile a kernel. :) 

On a second follow up Jordan said:

[email-masked] said:
> I still don't see how an MBONE capable PC, suitably dumbed-down or
> not, is going to solve the user's basic MBONE connectivity issues
> (without which the whole point is really rather moot).

> Can you tell us all here how you intend to grapple with the latter
> problem, especially given that it's been a critical problem since the
> very beginning of the MBONE project?  Without a clear strategy for
> getting people *on* the MBONE and making mbone routing something even
> Joe ISP can (and is willing to) do, I just can't see the client issues
> as all that pressing.  It's kind of like arguing what color the
> telephone in your mountain cabin should be despite the fact that
> you're not going to see an actual phone line run all the way up there
> anytime in the forseeable future. :-)

> - Jordan

>> The question of mbone capable PC Unix systems keeps coming up on
>> the mbone mailing list. Linux is a little bit behind however it
>> is catching to FreeBSD in terms of mbone and audio /video conferencing
>> tools . The first step for wider MBONE deployment is for the PCs
>> whether they run Unix or WinXX is for them to be MBONE capable
>> by clueless users . The server side (mrouted) you are correct
>> in that the users usually have the sufficient expertise however
>> on the client side it is an entirely different matter.
>> 
>> 	Amancio

---

From: [email-masked] (Bruce A. Mah)
Date: Tue, 23 Jun 1998 21:28:51 -0700

> are not being compile with IP Multicast enabled. 

I think people might get the wrong impression from this statement.  As I 
understand things, IP multicast *host* support (i.e. igmp, sending and 
receiving of packets) is always enabled in FreeBSD.  The functionality that 
doesn't come in the default kernel is multicast *routing*, which isn't 
necessary on end hosts.

> to build ip_mroute_mod loadable kernel module.

This much is true.  If someone's clued enough to run a multicast router 
successfully, they ought to be able to deal with this.

Cheers,

Bruce.

(Risking embarassment on the mbone list twice in one day...a new record.)

---

From: Joao Carlos Mendes Luis <[email-masked]>
Date: Wed, 24 Jun 1998 01:57:46 -0300 (EST)

CC:ing to [email-masked], where this discussion should probably
continue.

#define quoting(Amancio Hasty)
// Got curious as to what was the latest as to why our default kernels 
// are not being compile with IP Multicast enabled. 

Because 99% or more of the FreeBSD user community does not need it ?
IMHO, I think that to understand what the MBone is and to setup a well
understood tunnel is not easier than compile a new FreeBSD kernel.

// Fortunately, in FreeBSD land is very easy to compile a kernel or 

You get my point...

// to build ip_mroute_mod loadable kernel module.

I've never heard of a ip_mrouted_mod loadable kernel module.  If it's
possible to have mrouting capability as a LKM, this could be available
by default.  Why is it not ?  To avoid lamers building tunnels wihtout
understanding what they are doing ?  :)

					Jonny

--
Joao Carlos Mendes Luis            M.Sc. Student
[email-masked]                 Universidade Federal do Rio de Janeiro

---

From: Amancio Hasty <[email-masked]>
Date: Tue, 23 Jun 1998 22:13:08 -0700

> --==_Exmh_-217138758P
> Content-Type: text/plain; charset=us-ascii
> 
Tnks Bruce, you are correct FreeBSD out of the box is IP Multicast enabled
and apologies for putting you in the spot.

The condition for multicast routing remains , that is to rebuild/install the 
kernel with option MROUTING or build/load  ip_mroute_mod .

	Best Regards,
	Amancio

---

From: Amancio Hasty <[email-masked]>
Date: Tue, 23 Jun 1998 22:39:52 -0700

{hasty} pwd
/usr/src/lkm/ip_mroute_mod
{hasty} vi Makefile 
#       $Id: Makefile,v 1.3 1997/02/22 12:48:12 peter Exp $

.PATH:  ${.CURDIR}/../../sys/netinet
KMOD=   ip_mroute_mod
SRCS=   ip_mroute.c
NOMAN=
CFLAGS+= -DMROUTE_LKM -DMROUTING

.include <bsd.kmod.mk>

----------------------------------------------------

So yes, there is an ip_mroute_mod, however I have never  used it whenever
I have needed ip multicast routing in one of my systems I just recompiled
the kernel.

	Cheers,
	Amancio

---

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 24 Jun 1998 10:05:00 +0200 (MET DST)

> > this list are using multicast?  100?  500?  You don't need to respond

To add: MROUTING is not relevant for the end user (with a single exception;
see below).

MROUTING is only relevant for somebody providing multicast routing to a LAN
or for an end user using DVMRP to tunnel.

Multicast capability per se does not depend on MROUTING.

[My personal knowledge is from NetBSD, but this arrangement of code originated
 in the original 4.4BSD whereupon both are based. Correct me if I'm wrong
 wrt. FreeBSD, please.]

Regards,
	-is

---

From: Amancio Hasty <[email-masked]>
Date: Wed, 24 Jun 1998 01:11:56 -0700

You are correct and for my home site (rah) until very recently I was
forced to use a dvmrp tunnel . Native ip multicast functionality in
routers is more prevalent now days.

	Cheers,
	Amancio

---

From: Hugh LaMaster <[email-masked]>
Date: Fri, 26 Jun 1998 09:26:48 -0700 (PDT)

> > receiving of packets) is always enabled in FreeBSD.  The functionality that 

To go one step further, every "modern" OS, including "personal
system"/ "client" OS's, should have multicast by default.  And,
in fact, they have, for years, supported multicast and IGMPv1.
Nowadays, they should support IGMPv2, if not now, soon, and so on.  
For example, Windows95, way back then, supported IGMPv1, Windows98 
is said to support IGMPv2.

That is not to say that there are not bugs in various vendors code, 
as we have also seen on this group.  But, multicast host support should
not be an issue.

The distinction, as several people have pointed out, is the ability
of the kernel to interface with multicast routing daemons and support
multicast packet forwarding - in other words, be a router.

The ability to be a multicast router is a necessary feature for 
OS's used for net research, such as FreeBSD and NetBSD, but is
probably of lesser significance all the time for ordinary 
consumers, or, at least it should be, because of the growing
support of native multicast routing in routers and in some
carriers and ISPs.  In other words, the number of people who
have to run their own copy of mrouted and tunnel to someone
else running mrouted should be stabilizing now, rather than
growing.

However, for people doing their own routing locally via a
workstation running local routing daemons, either operationally
or for net research, multicast routing is an important *option*.
But, I see no reason for it to be in the default kernels on
something like FreeBSD, which should be as small as possible.  
For larger commercial OS's, it should probably be a system
boot option controlled by, e.g., /etc/system or whatever...

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.