As with UDP and TCP port numbers, the Internet Assigned Numbers Authority (IANA) maintains a list of registered IP multicast groups. The current list can be found in RFC 1700. For more information about the IANA, see RFC 1700. Figure 12.1 shows only some of the well-known groups.

The first 256 groups (224.0.0.0 to 224.0.0.255) are reserved for protocols that implement IP unicast and multicast routing mechanisms. Datagrams sent to any of these groups are not forwarded beyond the local network by multicast routers, regardless of the TTL value in the IP header.

Every level-2 conforming system is required to join the 224.0.0.1 (INADDR_ALLHOSTS_GROUP) group on all multicast interfaces at system initialization time (Figure 6.17) and remain a member of the group until the system is shut down. There is no multicast group that corresponds to every interface on an internet.

Unicast and multicast routers may join group 224.0.0.2 to communicate with each other. The ICMP router solicitation message and router advertisement messages may be sent to 224.0.0.2 (the all-routers group) and 224.0.0.1 (the all-hosts group), respectively, instead of to the limited broadcast address (255.255.255.255).

The 224.0.0.4 group supports communication between multicast routers that implement DVMRP. Other groups within the local multicast group range are similarly assigned for other routing protocols. Beyond the first 256 groups, the remaining groups (224.0.1.0-239.255.255.255) are assigned to various multicast application protocols or remain unassigned. Figure 12.1 lists two examples, the Network Time Protocol (224.0.1.1), and SGI-Dogfight (224.0.1.2).

Throughout this chapter, we note that multicast packets are sent and received by the transport layer on a host. While the multicasting code is not aware of the specific transport protocol that sends and receives multicast datagrams, the only Internet transport protocol that supports multicasting is UDP.

Three new global variables are introduced in this chapter:???

The code in this chapter updates a few of the counters maintained in the global ipstat structure.???

Link-level multicast statistics are collected in the ifnet structure (Figure 4.5) and may include multicasting of protocols other than IP.

Because Ethernet supports multiple protocols, a method to allocate the multicast addresses and prevent conflicts is needed. Ethernet addresses allocation is administered by the IEEE. A block of Ethernet multicast addresses is assigned to the IANA by the IEEE to support IP multicasting. The addresses in the block all start with 01:00:5e.

Figure 12.5 illustrates the construction of an Ethernet multicast address from a class D IP address.

Figure 12.5. Mapping between IP and Ethernet addresses.

The mapping illustrated by Figure 12.5 is a many-to-one mapping. The high-order 9 bits of the class D IP address are not used when constructing the Ethernet address. 32 IP multicast groups map to a single Ethernet multicast address (Exercise 12.3). In Section 12.14 we’ll see how this affects input processing. Figure 12.6 shows the macro that implements this mapping in Net/3.

---------------------------------------------------------------------- if_ether.h
 61 #define ETHER_MAP_IP_MULTICAST(ipaddr, enaddr) 
 62     /* struct in_addr *ipaddr; */ 
 63     /* u_char enaddr[6];       */ 
 64 { 
 65     (enaddr)[0] = 0x01; 
 66     (enaddr)[1] = 0x00; 
 67     (enaddr)[2] = 0x5e; 
 68     (enaddr)[3] = ((u_char *)ipaddr)[1] & 0x7f; 
 69     (enaddr)[4] = ((u_char *)ipaddr)[2]; 
 70     (enaddr)[5] = ((u_char *)ipaddr)[3]; 
 71 }
---------------------------------------------------------------------- if_ether.h

61-71

ETHER_MAP_IP_MULTICAST implements the mapping shown in Figure 12.5. ipaddr points to the class D multicast address, and the matching Ethernet address is constructed in enaddr, an array of 6 bytes. The first 3 bytes of the Ethernet multicast address are 0x01,0x00, and 0x5e followed by a 0 bit and then the low-order 23 bits of the class D IP address.

147-153

enm_addrlo and enm_addrhi specify a range of Ethernet multicast addresses that should be received. A single Ethernet address is specified when enm_addrlo and enm_addrhi are the same. The entire list of ether_multi structures is attached to the arpcom structure of each Ethernet interface (Figure 3.26). Ethernet multicasting is independent of ARP usin g the arpcom structure is a matter of convenience, since the structure is already included in every Ethernet interface structure.

enm_ac points back to the arpcom structure of the associated interface and enm_refcount tracks the usage of the ether_multi structure. When the reference count drops to 0, the structure is released. enm_next joins the ether_multi structures for a single interface into a linked list. Figure 12.8 shows a list of three ether_multi structures attached to le_softc[0], the ifnet structure for our sample Ethernet interface.

Figure 12.8. The LANCE interface with three ether_multi structures.

In Figure 12.8 we see that:

The ETHER_LOOKUP_MULTI macro, shown in Figure 12.9, searches an ether_multi list for a range of addresses.

---------------------------------------------------------------------- if_ether.h
166 #define ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm) 
167     /* u_char addrlo[6]; */ 
168     /* u_char addrhi[6]; */ 
169     /* struct arpcom *ac; */ 
170     /* struct ether_multi *enm; */ 
171 { 
172     for ((enm) = (ac)->ac_multiaddrs; 
173         (enm) != NULL && 
174         (bcmp((enm)->enm_addrlo, (addrlo), 6) != 0 || 
175          bcmp((enm)->enm_addrhi, (addrhi), 6) != 0); 
176         (enm) = (enm)->enm_next); 
177 }
---------------------------------------------------------------------- if_ether.h

166-177

addrlo and addrhi specify the search range and ac points to the arpcom structure containing the list to search. The for loop performs a linear search, stopping at the end of the list or when enm_addrlo and enm_addrhi both match the supplied addrlo and addrhi addresses. When the loop terminates, enm is null or points to a matching ether_multi structure.

111-118

inm_addr is a class D multicast address (e.g., 224.0.0.1, the all-hosts group). inm_ifp points back to the ifnet structure of the associated interface and inm_ia points back to the interface’s in_ifaddr structure.

An in_multi structure exists only if at least one process on the system has notified the kernel that it wants to receive multicast datagrams for a particular {interface, group} pair. Since multiple processes may elect to receive datagrams sent to a particular pair, inm_refcount keeps track of the number of references to the pair. When no more processes are interested in the pair, inm_refcount drops to 0 and the structure is released. This action may cause an associated ether_multi structure to be released if its reference count also drops to 0.

inm_timer is part of the IGMP protocol implementation described in Chapter 13. Finally, inm_next points to the next in_multi structure in the list.

Figure 12.13 illustrates the relationship between an interface, its IP unicast address, and its IP multicast group list using the le_softc[0] sample interface.

Figure 12.13. An IP multicast group list for the le interface.

We’ve omitted the corresponding ether_multi structures for clarity (but see Figure 12.34). If the system had two Ethernet cards, the second card would be managed through le_softc[1] and would have its own multicast group list attached to its arpcom structure. The macro IN_LOOKUP_MULTI (Figure 12.14) searches the IP multicast list for a particular multicast group.

------------------------------------------------------------------------ in_var.h
131 #define IN_LOOKUP_MULTI(addr, ifp, inm) 
132     /* struct in_addr addr; */ 
133     /* struct ifnet *ifp; */ 
134     /* struct in_multi *inm; */ 
135 { 
136      struct in_ifaddr *ia; 
137 
138     IFP_TO_IA((ifp), ia); 
139     if (ia == NULL) 
140         (inm) = NULL; 
141     else 
142         for ((inm) = ia->ia_multiaddrs; 
143             (inm) != NULL && (inm)->inm_addr.s_addr != (addr).s_addr; 
144              (inm) = inm->inm_next) 
145              continue; 
146 }
------------------------------------------------------------------------ in_var.h

131-146

IN_LOOKUP_MULTI looks for the multicast group addr in the multicast group list associated with interface ifp. IFP_TO_IA searches the Internet address list, in_ifaddr, for the in_ifaddr structure associated with the interface identified by ifp. If IFP_TO_IA finds an interface, the for loop searches its IP multicast list. After the loop, inm is null or points to the matching in_multi structure.

100-106

ip_output routes outgoing multicast datagrams through the interface pointed to by imo_multicast_ifp or, if imo_multicast_ifp is null, through the default interface for the destination multicast group (Chapter 14).

imo_multicast_ttl specifies the initial IP TTL value for outgoing multicasts. The default is 1, which causes multicast datagrams to remain on the local network.

If imo_multicast_loop is 0, the multicast datagram is not looped back and delivered to the transmitting interface even if the interface is a member of the multicast group. If imo_multicast_loop is 1, the multicast datagram is looped back to the transmitting interface if the interface is a member of the multicast group.

Finally, the integer imo_num_memberships and the array imo_membership maintain the list of {interface, group} pairs associated with the structure. Changes to the list are communicated to IP, which announces membership changes on the locally attached network. Each entry in the imo_membership array is a pointer to an in_multi structure attached to the in_ifaddr structure of the appropriate interface.

A subset of routers on the Internet supports IP multicast routing. This multicast backbone is called the MBONE, which is described in [Casner 1993]. It exists to support experimentation with IP multicasting in particular with audio and video data streams. In the MBONE, threshold values limit how far various data streams propagate. In Figure 12.18, we see that local event video packets always start with a TTL of 31. An interface with a threshold of 32 always blocks local event video. At the other end of the scale, IETF channel 1 low-rate audio is restricted only by the inherent IP TTL maximum of 255 hops. It propagates through the entire MBONE. An administrator of a multicast router within the MBONE can select a threshold value to accept or discard MBONE data streams selectively.

Another use of the multicast TTL is to probe the internet for a resource by varying the initial TTL value of the probe datagram. This technique is called an expanding-ring search ([Boggs 1982]). A datagram with an initial TTL of 0 reaches only a resource on the local system associated with the outgoing interface. A TTL of 1 reaches the resource if it exists on the local subnet. A TTL of 2 reaches resources within two hops of the source. An application increases the TTL exponentially to probe a large internet quickly.

665-679

When a new ip_moptions structure is allocated, ip_setmoptions initializes the default multicast interface pointer to null, initializes the default TTL to 1 (IP_DEFAULT_MULTICAST_TTL), enables the loopback of multicast datagrams, and clears the group membership list. With these defaults, ip_output selects an outgoing interface by consulting the routing tables, multicasts are kept on the local network, and the system receives its own multicast transmissions if the outgoing interface is a member of the destination group.

680-860

The body of ip_setmoptions consists of a switch statement with a case for each option. The default case (for unknown options) sets error to EOPNOTSUPP.

861-872

After the switch statement, ip_setmoptions examines the ip_moptions structure. If all the multicast options match their respective default values, the structure is unnecessary and is released. ip_setmoptions returns 0 or the posted error code.

When optname is IP_MULTICAST_IF, the mbuf passed to ip_setmoptions contains the unicast address of a multicast interface, which specifies the particular interface for multicasts sent on this socket. Figure 12.20 shows the code for this option.

---------------------------------------------------------------------- ip_output.c
681     case IP_MULTICAST_IF:
682         /*
683          * Select the interface for outgoing multicast packets.
684          */
685         if (m == NULL || m->m_len != sizeof(struct in_addr)) {
686             error = EINVAL;
687             break;
688         }
689         addr = *(mtod(m, struct in_addr *));
690         /*
691          * INADDR_ANY is used to remove a previous selection.
692          * When no interface is selected, a default one is
693          * chosen every time a multicast packet is sent.
694          */
695         if (addr.s_addr == INADDR_ANY) {
696             imo->imo_multicast_ifp = NULL;
697             break;
698         }
699         /*
700          * The selected interface is identified by its local
701          * IP address.  Find the interface and confirm that
702          * it supports multicasting.
703          */
704         INADDR_TO_IFP(addr, ifp);
705         if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0) {
706             error = EADDRNOTAVAIL;
707             break;
708         }
709         imo->imo_multicast_ifp = ifp;
710         break;
---------------------------------------------------------------------- ip_output.c

681-698

If no mbuf has been provided or the data within the mbuf is not the size of an in_addr structure, ip_setmoptions posts an EINVAL error; otherwise the data is copied into addr. If the interface address is INADDR_ANY, any previously selected interface is discarded. Subsequent multicasts with this ip_moptions structure are routed according to their destination group instead of through an explicitly named interface (Figure 12.40).

699-710

If addr contains an address, INADDR_TO_IFP locates the matching interface. If a match can’t be found or the interface does not support multicasting, EADDRNOTAVAIL is posted. Otherwise, ifp, the matching interface, becomes the multicast interface for output requests associated with this ip_moptions structure.

When optname is IP_MULTICAST_TTL, the mbuf is expected to contain a single byte specifying the IP TTL for outgoing multicasts. This TTL is inserted by ip_output into every multicast datagram sent on the associated socket. Figure 12.21 shows the code for this option.

---------------------------------------------------------------------- ip_output.c
711     case IP_MULTICAST_TTL:
712         /*
713          * Set the IP time-to-live for outgoing multicast packets.
714          */
715         if (m == NULL || m->m_len != 1) {
716             error = EINVAL;
717             break;
718         }
719         imo->imo_multicast_ttl = *(mtod(m, u_char *));
720         break;
---------------------------------------------------------------------- ip_output.c

711-720

If the mbuf contains a single byte of data, it is copied into imo_multicast_ttl. Otherwise, EINVAL is posted.

In general, multicast applications come in two forms:

The IP_MULTICAST_LOOP option (Figure 12.22) selects the loopback policy associated with an ip_moptions structure.

---------------------------------------------------------------------- ip_output.c
721     case IP_MULTICAST_LOOP:
722         /*
723          * Set the loopback flag for outgoing multicast packets.
724          * Must be zero or one.
725          */
726         if (m == NULL || m->m_len != 1 ||
727             (loop = *(mtod(m, u_char *))) > 1) {
728             error = EINVAL;
729             break;
730         }
731         imo->imo_multicast_loop = loop;
732         break;
---------------------------------------------------------------------- ip_output.c

721-732

If m is null, does not contain 1 byte of data, or the byte is not 0 or 1, EINVAL is posted. Otherwise, the byte is copied into imo_multicast_loop. A 0 indicates that datagrams should not be looped back, and a 1 enables the loopback mechanism.

Figure 12.23 shows the relationship between, the maximum scope of a multicast datagram, imo_multicast_ttl, and imo_multicast_loop.

Figure 12.23 shows that the set of interfaces that may receive a multicast packet depends on what the loopback policy is for the transmission and what TTL value is specified in the packet. A packet may be received on an interface if the hardware receives its own transmissions, regardless of the loopback policy. A datagram may be routed through the network and arrive on another interface attached to the system (Exercise 12.6). If the sending system is itself a multicast router, outgoing packets may be forwarded to the other interfaces, but they will only be accepted for input processing on one interface (Chapter 14).

733-746

ip_setmoptions starts by validating the request. If no mbuf was passed, if it is not the correct size, or if the address (imr_multiaddr) within the structure is not a multicast group, then ip_setmoptions posts EINVAL. mreq points to the valid ip_mreq structure.

747-774

If the unicast address of the interface (imr_interface) is INADDR_ANY, ip_setmoptions must locate the default interface for the specified group. A route structure is constructed with the group as the desired destination and passed to rtalloc, which locates a route for the group. If no route is available, the add request fails with the error EADDRNOTAVAIL. If a route is located, a pointer to the outgoing interface for the route is saved in ifp and the route entry, which is no longer needed, is released.

If imr_interface is not INADDR_ANY, an explicit interface has been requested. The macro INADDR_TO_IFP searches for the interface with the requested unicast address. If an interface isn’t found or if it does not support multicasting, the request fails with the error EADDRNOTAVAIL.

775-792

The last check performed on the request is to examine the imo_membership array to see if the selected interface is already a member of the requested group. If the for loop finds a match, or if the membership array is full, EADDRINUSE or ETOOMANYREFS is posted and processing of this option stops.

793-803

At this point the request looks reasonable. in_addmulti arranges for IP to begin receiving multicast datagrams for the group. The pointer returned by in_addmulti points to a new or existing in_multi structure (Figure 12.12) in the interface’s multicast group list. It is saved in the membership array and the size of the array is incremented.

in_addmulti and its companion in_delmulti (Figures 12.27 and 12.36) maintain the list of multicast groups that an interface has joined. Join requests either add a new in_multi structure to the interface list or increase the reference count of an existing structure.

---------------------------------------------------------------------- in.c
469 struct in_multi *
470 in_addmulti(ap, ifp)
471 struct in_addr *ap;
472 struct ifnet *ifp;
473 {
474     struct in_multi *inm;
475     struct ifreq ifr;
476     struct in_ifaddr *ia;
477     int     s = splnet();

478     /*
479      * See if address already in list.
480      */
481     IN_LOOKUP_MULTI(*ap, ifp, inm);
482     if (inm != NULL) {
483         /*
484          * Found it; just increment the reference count.
485          */
486         ++inm->inm_refcount;
487     } else {
---------------------------------------------------------------------- in.c

469-487

ip_setmoptions has already verified that ap points to a class D multicast address and that ifp points to a multicast-capable interface. IN_LOOKUP_MULTI (Figure 12.14) determines if the interface is already a member of the group. If it is a member, in_addmulti updates the reference count and returns.

If the interface is not yet a member of the group, the code in Figure 12.28 is executed.

---------------------------------------------------------------------- in.c
487     } else {
488         /*
489          * New address; allocate a new multicast record
490          * and link it into the interface's multicast list.
491          */
492         inm = (struct in_multi *) malloc(sizeof(*inm),
493                                          M_IPMADDR, M_NOWAIT);
494         if (inm == NULL) {
495             splx(s);
496             return (NULL);
497         }
498         inm->inm_addr = *ap;
499         inm->inm_ifp = ifp;
500         inm->inm_refcount = 1;
501         IFP_TO_IA(ifp, ia);
502         if (ia == NULL) {
503             free(inm, M_IPMADDR);
504             splx(s);
505             return (NULL);
506         }
507         inm->inm_ia = ia;
508         inm->inm_next = ia->ia_multiaddrs;
509         ia->ia_multiaddrs = inm;
510         /*
511          * Ask the network driver to update its multicast reception
512          * filter appropriately for the new address.
513          */
514         ((struct sockaddr_in *) &ifr.ifr_addr)->sin_family = AF_INET;
515         ((struct sockaddr_in *) &ifr.ifr_addr)->sin_addr = *ap;
516         if ((ifp->if_ioctl == NULL) ||
517             (*ifp->if_ioctl) (ifp, SIOCADDMULTI, (caddr_t) & ifr) != 0) {
518             ia->ia_multiaddrs = inm->inm_next;
519             free(inm, M_IPMADDR);
520             splx(s);
521             return (NULL);
522         }
523         /*
524          * Let IGMP know that we have joined a new IP multicast group.
525          */
526         igmp_joingroup(inm);
527     }
528     splx(s);
529     return (inm);
530 }
---------------------------------------------------------------------- in.c

487-509

If the interface isn’t a member yet, in_addmulti allocates, initializes, and inserts the new in_multi structure at the front of the ia_multiaddrs list in the interface’s in_ifaddr structure (Figure 12.13).

510-530

If the interface driver has defined an if_ioctl function, in_addmulti constructs an ifreq structure (Figure 4.23) containing the group address and passes the SIOCADDMULTI request to the interface. If the interface rejects the request, the in_multi structure is unlinked from the interface and released. Finally, in_addmulti calls igmp_joingroup to propagate the membership change to other hosts and routers.

in_addmulti returns a pointer to the in_multi structure or null if an error occurred.

Multicast group processing for the SLIP and loopback interfaces is trivial: there is nothing to do other than error checking. Figure 12.29 shows the SLIP processing.

---------------------------------------------------------------------- if_sl.c
673     case SIOCADDMULTI:
674     case SIOCDELMULTI:
675         ifr = (struct ifreq *) data;
676         if (ifr == 0) {
677             error = EAFNOSUPPORT;   /* XXX */
678             break;
679         }
680         switch (ifr->ifr_addr.sa_family) {

681         case AF_INET:
682             break;

683         default:
684             error = EAFNOSUPPORT;
685             break;
686         }
687         break;
---------------------------------------------------------------------- if_sl.c

673-687

EAFNOSUPPORT is returned whether the request is empty or not for the AF_INET protocol family.

Figure 12.30 shows the loopback processing.

---------------------------------------------------------------------- if_loop.c
152     case SIOCADDMULTI:
153     case SIOCDELMULTI:
154         ifr = (struct ifreq *) data;
155         if (ifr == 0) {
156             error = EAFNOSUPPORT;   /* XXX */
157             break;
158         }
159         switch (ifr->ifr_addr.sa_family) {

160         case AF_INET:
161             break;

162         default:
163             error = EAFNOSUPPORT;
164             break;
165         }
166         break;
---------------------------------------------------------------------- if_loop.c

152-166

The processing for the loopback interface is identical to the SLIP code in Figure 12.29. EAFNOSUPPORT is returned whether the request is empty or not for the AF_INET protocol family.

Recall from Figure 4.2 that leioctl is the if_ioctl function for the LANCE Ethernet driver. Figure 12.31 shows the code for the SIOCADDMULTI and SIOCDELMULTI options.

---------------------------------------------------------------------- if_le.c
657     case SIOCADDMULTI:
658     case SIOCDELMULTI:
659         /* Update our multicast list  */
660         error = (cmd == SIOCADDMULTI) ?
661             ether_addmulti((struct ifreq *) data, &le->sc_ac) :
662             ether_delmulti((struct ifreq *) data, &le->sc_ac);

663         if (error == ENETRESET) {
664             /*
665              * Multicast list has changed; set the hardware
666              * filter accordingly.
667              */
668             lereset(ifp->if_unit);
669             error = 0;
670         }
671         break;
---------------------------------------------------------------------- if_le.c

657-671

leioctl passes add and delete requests directly to the ether_addmulti or ether_delmulti functions. Both functions return ENETRESET if the request changes the set of IP multicast addresses that must be received by the physical hardware. If this occurs, leioctl calls lereset to reinitialize the hardware with the new multicast reception list.

Every Ethernet driver calls ether_addmulti to process the SIOCADDMULTI request. This function maps the IP class D address to the appropriate Ethernet multicast address (Figure 12.5) and updates the ether_multi list. Figure 12.32 shows the first half of the ether_addmulti function.

---------------------------------------------------------------------- if_ethersubr.c
366 int
367 ether_addmulti(ifr, ac)
368 struct ifreq *ifr;
369 struct arpcom *ac;
370 {
371     struct ether_multi *enm;
372     struct sockaddr_in *sin;
373     u_char  addrlo[6];
374     u_char  addrhi[6];
375     int     s = splimp();

376     switch (ifr->ifr_addr.sa_family) {

377     case AF_UNSPEC:
378         bcopy(ifr->ifr_addr.sa_data, addrlo, 6);
379         bcopy(addrlo, addrhi, 6);
380         break;

381     case AF_INET:
382         sin = (struct sockaddr_in *) &(ifr->ifr_addr);
383         if (sin->sin_addr.s_addr == INADDR_ANY) {
384             /*
385              * An IP address of INADDR_ANY means listen to all
386              * of the Ethernet multicast addresses used for IP.
387              * (This is for the sake of IP multicast routers.)
388              */
389             bcopy(ether_ipmulticast_min, addrlo, 6);
390             bcopy(ether_ipmulticast_max, addrhi, 6);
391         } else {
392             ETHER_MAP_IP_MULTICAST(&sin->sin_addr, addrlo);
393             bcopy(addrlo, addrhi, 6);
394         }
395         break;

396     default:
397         splx(s);
398         return (EAFNOSUPPORT);
399     }
---------------------------------------------------------------------- if_ethersubr.c

366-399

First, ether_addmulti initializes a range of multicast addresses in addrlo and addrhi (both are arrays of six unsigned characters). If the requested address is from the AF_UNSPEC family, ether_addmulti assumes the address is an explicit Ethernet multicast address and copies it into addrlo and addrhi. If the address is in the AF_INET family and is INADDR_ANY (0.0.0.0), ether_addmulti initializes addrlo to ether_ipmulticast_min and addrhi to ether_ipmulticast_max. These two constant Ethernet addresses are defined as:

u_char ether_ipmulticast_min[6] = { 0x01, 0x00, 0x5e, 0x00, 0x00, 0x00 };
u_char ether_ipmulticast_max[6] = { 0x01, 0x00, 0x5e, 0x7f, 0xff, 0xff };

IP multicast routers must listen for all IP multicasts. Specifying the group as INADDR_ANY is considered a request to join every IP multicast group. The Ethernet address range selected in this case spans the entire block of IP multicast addresses allocated to the IANA.

ETHER_MAP_IP_MULTICAST maps any other specific IP multicast group to the appropriate Ethernet multicast address. Requests for other address families are rejected with an EAFNOSUPPORT error.

While the Ethernet multicast list supports address ranges, there is no way for a process or the kernel to request a specific range, other than to enumerate the addresses, since addrlo and addrhi are always set to the same address.

The second half of ether_addmulti, shown in Figure 12.33, verifies the address range and adds it to the list if it is new.

---------------------------------------------------------------------- if_ethersubr.c
400     /*
401      * Verify that we have valid Ethernet multicast addresses.
402      */
403     if ((addrlo[0] & 0x01) != 1 || (addrhi[0] & 0x01) != 1) {
404         splx(s);
405         return (EINVAL);
406     }
407     /*
408      * See if the address range is already in the list.
409      */
410     ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm);
411     if (enm != NULL) {
412         /*
413          * Found it; just increment the reference count.
414          */
415         ++enm->enm_refcount;
416         splx(s);
417         return (0);
418     }
419     /*
420      * New address or range; malloc a new multicast record
421      * and link it into the interface's multicast list.
422      */
423     enm = (struct ether_multi *) malloc(sizeof(*enm), M_IFMADDR, M_NOWAIT);
424     if (enm == NULL) {
425         splx(s);
426         return (ENOBUFS);
427     }
428     bcopy(addrlo, enm->enm_addrlo, 6);
429     bcopy(addrhi, enm->enm_addrhi, 6);
430     enm->enm_ac = ac;
431     enm->enm_refcount = 1;
432     enm->enm_next = ac->ac_multiaddrs;
433     ac->ac_multiaddrs = enm;
434     ac->ac_multicnt++;
435     splx(s);
436     /*
437      * Return ENETRESET to inform the driver that the list has changed
438      * and its reception filter should be adjusted accordingly.
439      */
440     return (ENETRESET);
441 }
---------------------------------------------------------------------- if_ethersubr.c

400-418

ether_addmulti checks the multicast bit (Figure 4.12) of the high and low addresses to ensure that they are indeed Ethernet multicast addresses. ETHER_LOOKUP_MULTI (Figure 12.9) determines if the hardware is already listening for the specified multicast addresses. If so, the reference count (enm_refcount) in the matching ether_multi structure is incremented and ether_addmulti returns 0.

419-441

If this is a new address range, a new ether_multi structure is allocated, initialized, and linked to the ac_multiaddrs list in the interfaces arpcom structure (Figure 12.8). If ENETRESET is returned by ether_addmulti, the device driver that called the function knows that the multicast list has changed and the hardware reception filter must be updated.

Figure 12.34 shows the relationships between the ip_moptions, in_multi, and ether_multi structures after the LANCE Ethernet interface has joined the all-hosts group.

Figure 12.34. Overview of multicast data structures.

804-830

The mbuf must contain an ip_mreq structure, within the structure imr_multiaddr must be a multicast group, and there must be an interface associated with the unicast address imr_interface. If these conditions aren’t met, EINVAL or EADDRNOTAVAIL is posted and processing continues at the end of the switch.

831-856

The for loop searches the group membership list for an in_multi structure with the requested {interface, group} pair. If a match isn’t found, EADDRNOTAVAIL is posted. Otherwise, in_delmulti updates the in_multi list and the second for loop removes the unused entry in the membership array by shifting subsequent entries to fill the gap. The size of the array is updated accordingly.

Since many processes may be receiving multicast datagrams, calling in_delmulti (Figure 12.36) results only in leaving the specified group when there are no more references to the in_multi structure.

---------------------------------------------------------------------- in.c
534 int
535 in_delmulti(inm)
536 struct in_multi *inm;
537 {
538     struct in_multi **p;
539     struct ifreq ifr;
540     int     s = splnet();

541     if (--inm->inm_refcount == 0) {
542         /*
543          * No remaining claims to this record; let IGMP know that
544          * we are leaving the multicast group.
545          */
546         igmp_leavegroup(inm);
547         /*
548          * Unlink from list.
549          */
550         for (p = &inm->inm_ia->ia_multiaddrs;
551              *p != inm;
552              p = &(*p)->inm_next)
553             continue;
554         *p = (*p)->inm_next;
555         /*
556          * Notify the network driver to update its multicast reception
557          * filter.
558          */
559         ((struct sockaddr_in *) &(ifr.ifr_addr))->sin_family = AF_INET;
560         ((struct sockaddr_in *) &(ifr.ifr_addr))->sin_addr =
561             inm->inm_addr;
562         (*inm->inm_ifp->if_ioctl) (inm->inm_ifp, SIOCDELMULTI,
563                                    (caddr_t) & ifr);
564         free(inm, M_IPMADDR);
565     }
566     splx(s);
567 }
---------------------------------------------------------------------- in.c

534-567

in_delmulti starts by decrementing the reference count of the in_multi structure and returning if the reference count is nonzero. If the reference count drops to 0, there are no longer any processes waiting for the multicast datagrams on the specified {interface, group} pair. igmp_leavegroup is called, but as we’ll see in Section 13.8, the function does nothing.

The for loop traverses the linked list of in_multi structures until it locates the matching structure.

After the loop, the matching in_multi structure is unlinked and in_delmulti issues the SIOCDELMULTI request to the interface so that any device-specific data structures can be updated. For Ethernet interfaces, this means the ether_multi list is updated. Finally, the in_multi structure is released.

When IP releases an in_multi structure associated with an Ethernet device, the device may be able to release the matching ether_multi structure. We say may because IP may be unaware of other software listening for IP multicasts. When the reference count for the ether_multi structure drops to 0, it can be released. Figure 12.37 shows the ether_delmulti function.

---------------------------------------------------------------------- if_ethersubr.c
445 int
446 ether_delmulti(ifr, ac)
447 struct ifreq *ifr;
448 struct arpcom *ac;
449 {
450     struct ether_multi *enm;
451     struct ether_multi **p;
452     struct sockaddr_in *sin;
453     u_char  addrlo[6];
454     u_char  addrhi[6];
455     int     s = splimp();

456     switch (ifr->ifr_addr.sa_family) {

457     case AF_UNSPEC:
458         bcopy(ifr->ifr_addr.sa_data, addrlo, 6);
459         bcopy(addrlo, addrhi, 6);
460         break;

461     case AF_INET:
462         sin = (struct sockaddr_in *) &(ifr->ifr_addr);
463         if (sin->sin_addr.s_addr == INADDR_ANY) {
464             /*
465              * An IP address of INADDR_ANY means stop listening
466              * to the range of Ethernet multicast addresses used
467              * for IP.
468              */
469             bcopy(ether_ipmulticast_min, addrlo, 6);
470             bcopy(ether_ipmulticast_max, addrhi, 6);
471         } else {
472             ETHER_MAP_IP_MULTICAST(&sin->sin_addr, addrlo);
473             bcopy(addrlo, addrhi, 6);
474         }
475         break;

476     default:
477         splx(s);
478         return (EAFNOSUPPORT);
479     }

480     /*
481      * Look up the address in our list.
482      */
483     ETHER_LOOKUP_MULTI(addrlo, addrhi, ac, enm);
484     if (enm == NULL) {
485         splx(s);
486         return (ENXIO);
487     }
488     if (--enm->enm_refcount != 0) {
489         /*
490          * Still some claims to this record.
491          */
492         splx(s);
493         return (0);
494     }
495     /*
496      * No remaining claims to this record; unlink and free it.
497      */
498     for (p = &enm->enm_ac->ac_multiaddrs;
499          *p != enm;
500          p = &(*p)->enm_next)
501         continue;
502     *p = (*p)->enm_next;
503     free(enm, M_IFMADDR);
504     ac->ac_multicnt--;
505     splx(s);
506     /*
507      * Return ENETRESET to inform the driver that the list has changed
508      * and its reception filter should be adjusted accordingly.
509      */
510     return (ENETRESET);
511 }
---------------------------------------------------------------------- if_ethersubr.c

445-479

ether_delmulti initializes the addrlo and addrhi arrays in the same way as ether_addmulti does.

480-494

ETHER_LOOKUP_MULTI locates a matching ether_multi structure. If it isn’t found, ENXIO is returned. If the matching structure is found, the reference count is decremented and if the result is nonzero, ether_delmulti returns immediately. In this case, the structure may not be released because another protocol has elected to receive the same multicast packets.

495-511

The for loop searches the ether_multi list for the matching address range. The matching structure is unlinked from the list and released. Finally, the size of the list is updated and ENETRESET is returned so that the device driver can update its hardware reception filter.

876-914

The three arguments to ip_getmoptions are: optname, the option to fetch; imo, the ip_moptions structure; and mp, which points to a pointer to an mbuf. m_get allocates an mbuf to hold the option data. For each of the three options, a pointer (addr, ttl, and loop, respectively) is initialized to the data area of the mbuf and the length of the mbuf is set to the length of the option data.

For IP_MULTICAST_IF, the unicast address found by IFP_TO_IA is returned or INADDR_ANY is returned if no explicit multicast interface has been selected.

For IP_MULTICAST_TTL, imo_multicast_ttl is returned or if an explicit multicast TTL has not been selected, 1 (IP_DEFAULT_MULTICAST_TTL) is returned.

For IP_MULTICAST_LOOP, imo_multicast_loop is returned or if an explicit multicast loopback policy has not been selected, 1 (IP_DEFAULT_MULTICAST_LOOP) is returned.

Finally, EOPNOTSUPP is returned if the option isn’t recognized.

214-245

This entire section of code is skipped if the destination address is not an IP multicast group. If the address is a multicast group and the system is configured as an IP multicast router (ip_mrouter), ip_id is converted to network byte order (the form that ip_mforward expects), and the packet is passed to ip_mforward. If ip_mforward returns a nonzero value, an error was detected or the packet arrived through a multicast tunnel. The packet is discarded and ips_cantforward incremented.

If ip_mforward returns 0, ip_id is converted back to host byte order and ipintr may continue processing the packet.

If ip points to an IGMP packet, it is accepted and execution continues at ours (ipintr, Figure 10.11). A multicast router must accept all IGMP packets irrespective of their individual destination groups or of the group memberships of the incoming interface. The IGMP packets contain announcements of membership changes.

246-257

The remaining code in Figure 12.39 is executed whether or not the system is configured as a multicast router. IN_LOOKUP_MULTI searches the list of multicast groups that the interface has joined. If a match is not found, the packet is discarded. This occurs when the hardware filter accepts unwanted packets or when a group associated with the interface and the destination group of the packet map to the same Ethernet multicast address.

If the packet is accepted, execution continues at the label ours in ipintr (Figure 10.11).

129-155

The code in Figure 12.40 is executed only if the packet is destined for a multicast group. If so, ip_output sets M_MCAST in the mbuf and dst is reset to the final destination as it may have been set to the next-hop router earlier in ip_output (Figure 8.24).

If an ip_moptions structure was passed, ip_ttl and ifp are changed accordingly. Otherwise, ip_ttl is set to 1 (IP_DEFAULT_MULTICAST_TTL), which prevents the multicast from escaping to a remote network. The interface selected by consulting the routing tables or the interface specified within the ip_moptions structure must support multicasting. If they do not, ip_output discards the packet and returns ENETUNREACH.

156-167

If the source address is unspecified, the for loop finds the Internet unicast address associated with the outgoing interface and fills in ip_src in the IP header.

Unlike a unicast packet, an outgoing multicast packet may be transmitted on more than one interface if the system is configured as a multicast router. Even if the system is not a multicast router, the outgoing interface may be a member of the destination group and may need to receive the packet. Finally, we need to consider the multicast loopback policy and the loopback interface itself. Taking all this into account, there are three questions to consider:

Figure 12.41 shows the code from ip_output that answers these questions.

168-176

If IN_LOOKUP_MULTI determines that the outgoing interface is a member of the destination group and imo_multicast_loop is nonzero, the packet is queued for input on the output interface by ip_mloopback. In this case, the original packet is not considered for forwarding, since the copy is forwarded during input processing if necessary.

178-197

If the packet is not looped back, but the system is configured as a multicast router and the packet is eligible for forwarding, ip_mforward distributes copies to other multicast interfaces. If ip_mforward does not return 0, ip_output discards the packet and does not attempt to transmit it. This indicates an error with the packet.

To prevent infinite recursion between ip_mforward and ip_output, ip_mforward always turns on IP_FORWARDING before calling ip_output. A datagram originating on the system is eligible for forwarding because the transport protocols do not turn on IP_FORWARDING.

198-209

Packets with a TTL of 0 may be looped back, but they are never forwarded (ip_mforward discards them) and are never transmitted. If the TTL is 0 or if the output interface is the loopback interface, ip_output discards the packet since the TTL has expired or the packet has already been looped back by ip_mloopback.

210-211

If the packet has made it this far, it is ready to be physically transmitted on the output interface. The code at sendit (ip_output, Figure 8.25) may fragment the datagram before passing it (or the resulting fragments) to the interface’s if_output function. We’ll see in Section 21.10 that the Ethernet output function, ether_output, calls arpresolve, which calls ETHER_MAP_IP_MULTICAST to construct an Ethernet multicast destination address based on the IP multicast destination address.

ip_mloopback relies on looutput (Figure 5.27) to do its job. Instead of passing a pointer to the loopback interface to looutput, ip_mloopback passes a pointer to the output multicast interface. The ip_mloopback function is shown in Figure 12.42.

---------------------------------------------------------------------- ip_output.c
935 static void
936 ip_mloopback(ifp, m, dst)
937 struct ifnet *ifp;
938 struct mbuf *m;
939 struct sockaddr_in *dst;
940 {
941     struct ip *ip;
942     struct mbuf *copym;

943     copym = m_copy(m, 0, M_COPYALL);
944     if (copym != NULL) {
945         /*
946          * We don't bother to fragment if the IP length is greater
947          * than the interface's MTU.  Can this possibly matter?
948          */
949         ip = mtod(copym, struct ip *);
950         ip->ip_len = htons((u_short) ip->ip_len);
951         ip->ip_off = htons((u_short) ip->ip_off);
952         ip->ip_sum = 0;
953         ip->ip_sum = in_cksum(copym, ip->ip_hl << 2);
954         (void) looutput(ifp, copym, (struct sockaddr *) dst, NULL);
955     }
956 }
---------------------------------------------------------------------- ip_output.c

929-956

Copying the packet isn’t enough; the packet must look as though it was received on the output interface, so ip_mloopback converts ip_len and ip_off to network byte order and computes the checksum for the packet. looutput takes care of putting the packet on the IP input queue.