Subject: all-routers multicast group

From: Dave Thaler <[email-masked]>
Date: Tue, 21 Jan 1997 14:27:00 -0500 (EST)

I've searched through a number of RFC's, and the only place so far that
I've found a reference to ALL-ROUTERS.MCAST.NET (224.0.0.2) is in the 
IGMPv2 draft.

The question I have occurs when you have a router with a point-to-point
link (or a tunnel) to another router.  It seems to me that in this case
there is no reason to run IGMP on that link (or tunnel).  The question
is then, specifically, is there any reason to join the all-routers group 
on that link?

It could easily happen that a router could _only_ have p2p links to other
routers, never run IGMP, and (I assume) never join the all-routers group
on any interface.

Is this legal, or would anything break?

-Dave

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Jan 1997 12:18:19 -0800

>> routers, never run IGMP, and (I assume) never join the all-routers group

    No matter what type of interface, you shouldn't be joining 224.0.0.2 with
    IGMP because it is in the reserved-local range of 224.0.0.x.

Dino

---

From: Dave Thaler <[email-masked]>
Date: Tue, 21 Jan 1997 15:22:18 -0500 (EST)

>     IGMP because it is in the reserved-local range of 224.0.0.x.

First, the question was not about joining it with IGMP messages, it was
about telling the kernel to accept packets to 224.0.0.2.

However, as Bill has previously pointed out, routers joining 224.0.0.2 
_should_ join it (and any other link-local groups they join except 
224.0.0.1) with IGMP messages because of bridges that snoop on IGMP 
messages and you need to reach routers on other segments.

-Dve

---

From: Steve Deering <[email-masked]>
Date: Tue, 21 Jan 1997 12:25:35 -0800

> I've found a reference to ALL-ROUTERS.MCAST.NET (224.0.0.2) is in the

It's also defined in the assigned numbers web pages, of course.

> is then, specifically, is there any reason to join the all-routers group

(a) If there is any chance that the machine at either end of the p2p
    link or tunnel will wish to join a multicast group greater than
    224.255.255.255 on its interface to that link (or pseudo-interface
    to that tunnel), then IGMP should be run over the link/tunnel.
    That chance is high if one end of the link is a host, and is also
    quite possible if both ends are routers.

    (Note that we do not run IGMP over MBone tunnels, because the Unix
    mcast routing code doesn't support joining a multicast group on a
    tunnel interface.  I consider that to be a [minor] bug.)

(b) Whether or not to join the all-routers group is a separate question
    from whether or not run IGMP.  By "join the all-routers group" I mean
    that a packet addressed to 224.0.0.2 and received over that interface
    will be accepted by the router as being addressed to itself.  A router
    should join the all-routers multicast group on all of its physical
    interfaces, and on its tunnel pseudo-interfaces if group-joining in
    general is supported on the pseudo-interfaces, whether or not it is
    running IGMP to report that membership to its neighbor.

Steve

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Jan 1997 12:26:22 -0800

>> about telling the kernel to accept packets to 224.0.0.2.

    Okay, but there are cases where there might be hosts on the other side
    of those p2p links. So I believe you'd want to run IGMP on p2p links.

>> messages and you need to reach routers on other segments.

    Well, our switches can work without IGMP reporting 224.0.0.2.

Dino

---

From: Dave Thaler <[email-masked]>
Date: Tue, 21 Jan 1997 15:39:29 -0500 (EST)

Steve, thanks for the response - this is the sort of info I wanted, but
I have a clarifying question or two :)

>     tunnel interface.  I consider that to be a [minor] bug.)

Can you give a simple example or two of when a router (not a host) would 
want to join a multicast group > 224.255.255.255?  (when this fact would
not already be obvious to the multicast routing protocol without using igmp)

>     running IGMP to report that membership to its neighbor.

This is indeed what I was asking about.  I can't find the above rule
stated in any standards document or I-D (not that it isn't stated, I
just haven't found it yet :).  So, if you aren't running IGMP on a link, 
what else is the 224.0.0.2 group used for?

-Dave

---

From: Bill Fenner <[email-masked]>
Date: Tue, 21 Jan 1997 12:37:56 PST

If you're not doing either ICMP Router Discovery or IGMPv2, then there
is no need to join all-routers.mcast.net; those are the only two protocols
that I know of that use all-routers.

The mtrace client uses all-routers to locate a router on a link, but
that's not required to work, especially in the P<>P link case where
you know all of the entities on the link.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 21 Jan 1997 13:39:15 -0800

>> that I know of that use all-routers.

    And PIMv1.

Dino

---

From: Steve Deering <[email-masked]>
Date: Tue, 21 Jan 1997 13:51:10 -0800

> not already be obvious to the multicast routing protocol without using igmp)

Some examples of why a router might want to join a non-local group are
to run an RTCP monitor tool or mtrace to diagnose a routing problem, or
maybe a multicast SNMP trap catcher (hypothetical future application).
At the logical level, routers are just hosts with an extra job to do
(forwarding packets), and should be fully capable of running end-system
applications, whether its telnet, http, or sdr -- in fact some routers
are just general-purpose computers, like Unix workstations.

One example of when the desired effect could not be achieved through the
multicast routing protocol alone is in DVMRP: if the p2p link happens to
be a leaf with respect to a given multicast source, and the router on one
end of the link is the DVMRP "parent" of the link (e.g., has the shortest
path back to the source), but the router on the other end of the link
wishes to receive the multicast packets via the link (i.e, has joined
the group on its interface to the link), then in the absence of IGMP,
the parent router has no way of knowing that someone else on the link
needs to receive copies of the packets.  The member router at the other
end will assume that it will get packets over the link, so it will prune
off any other recption branch.  (I hope that's clear; if not, I'll have
to walk you through it in a wb session or something.)

> >                                                              A router
> just haven't found it yet :)

It's implicit in the name: the ALL-routers group.  Actually, it doesn't
include routers that don't understand IP multicasts, but the intent is
those will become the null set.

> So, if you aren't running IGMP on a link, what else is the 224.0.0.2
> group used for?

Anything that requires sending a packet to all neigboring routers.  At the
moment, that's just IGMP, but there may well be other uses of that address
in the future.

May I ask why you are asking these questions?  It sounds like you are
trying to micro-optimize some router.  I'm especially curious as to why
you would want to eliminate joining 224.0.0.2 on an interface (as opposed
to disabling IGMP) -- being prepared to accept packets to 224.0.0.2 must
have such tiny processing/memory/complexity cost that it's hard to imagine
a big win by not doing it.  Are you building a router for light-bulb
sockets or something?  :-)

Steve

---

From: Steve Deering <[email-masked]>
Date: Tue, 21 Jan 1997 14:33:08 -0800

> moment, that's just IGMP, but there may well be other uses of that address

From Bill's and Dino's messages, it's clear I was wrong: more than just
IGMP uses 224.0.0.2.  The future is now.

Steve

---

From: masha boitchouk <[email-masked]>
Date: Tue, 21 Jan 1997 19:56:18 -0500 (EST)

Can anyone provide a suggestion or information on unsubscribing from this
list. No matter what I try, I still keep getting mail. Please help!

-Masha