Summary

  • RFC 3678 preserved existing multicast membership calls for source and binary compatibility, then added source-filter options and functions rather than changing the old interface.
  • A delta call changes one source in the current filter. A full-state call replaces the mode and list together; RFC 3678 says that form is needed for mode changes without leaving the group and is useful for large lists because the change can be atomic.

The existing call could not be stretched

The first constraint was not a router. It was the program already using the socket. Before source filtering, a multicast receiver could join a group and, where needed, choose a local interface. That established membership but did not let the application describe which senders it wanted. Altering the established call itself was not a safe way to add the missing information: RFC 3678 says those interfaces could not change without breaking binary compatibility.

So the document took an additive route. It asked new APIs to preserve both source compatibility—old source still compiles and behaves—and binary compatibility—an existing executable continues to run on a system that supports the extension. It also called for small changes and a way for applications to notice when the new options were unavailable, then respond gracefully. This is an API design memo, not evidence that every operating system implemented the same calls. RFC 3678

One source at a time

The delta interface changes the filter incrementally. For an any-source multicast membership, the receiver starts by accepting sources generally; a block or unblock operation changes one sender's treatment. In source-specific multicast, the receiver adds or removes a particular source from the set it wants. The state before the call matters: the RFC defines certain option/membership combinations as invalid, while an already-blocked or unjoined source can produce a different error.

This is an economical grammar when an application has one small change to make. It can say “block this source” or “join this source” without resubmitting the rest of the list. The meaning is tied to the current filter and membership state, though. The operation is a delta, not a complete declaration of what the filter should be afterward. The API surface includes IPv4-specific options such as IP_ADD_SOURCE_MEMBERSHIP and protocol-independent options such as MCAST_JOIN_SOURCE_GROUP. RFC 3678

Or replace the whole state

The full-state API has a different job. It supplies the filter mode—MCAST_INCLUDE or MCAST_EXCLUDE—and the entire source list to include or exclude. The call replaces the prior filter instead of applying one membership change to it.

RFC 3678 names two cases where that distinction matters. An application that needs to switch between INCLUDE and EXCLUDE without leaving the group must use the full-state API. An application with a large source list should also use it because the list can be changed atomically in one operation. A sequence of deltas may eventually describe the same set, but the full-state form expresses one replacement, not a succession of intermediate edits.

The getter has its own contract: the application can provide a buffer estimate, receive the total source count, and repeat the call if the buffer was too small. If an implementation imposes a maximum list size, a set that exceeds it can fail with ENOBUFS. Those details make “replace all” a state-management tool, not an unlimited-capacity promise. RFC 3678

One group, two address families

The memo kept IPv4-specific structures and options for applications that needed minimal changes to IPv4 source code. It also defined protocol-independent forms. These carry a group and source in address-family-capable socket structures while identifying the local interface separately by its interface index. RFC 3493 had supplied much of the IPv6 socket vocabulary, but not protocol-independent multicast join and leave operations; RFC 3678 filled that gap. RFC 3493

That separation is easy to overlook in a function signature: a group address names the multicast destination, a source address names a sender, and an interface index scopes the operation to a local attachment. The verified technical erratum 2524 later corrected section 5.2.2's description of the getter argument from “local IP address” to “interface index,” matching the setter one section earlier. A separate verified editorial erratum fixed a cross-reference to the error-code section. Neither erratum changes the source-filter model; both help preserve what the arguments actually mean. RFC 3678 errata

Filtering here is not filtering everywhere

A source filter can operate in the host even when routers do not support IGMPv3 or MLDv2. The application may therefore gain local filtering without proving that unwanted packets stopped traversing the local link. The protocols communicate filter information toward a router; that is a separate mechanism from the socket call and has its own state and path. RFC 3376, RFC 3810 and RFC 4604 describe pieces of that network-side behavior. RFC 3376 RFC 3810 RFC 4604

Nor does filtering authenticate a sender. RFC 3678 warns that source filtering alone cannot stop a packet whose source address is spoofed to look like an allowed source; reverse-path checks may help in some routing arrangements, but are not a guarantee. A socket call succeeding is evidence about an API operation, not proof of router state, reduced bandwidth, authenticated traffic, packet receipt or application success. RFC 3678

The document is Informational and explicitly says it is not an Internet Standard; it also points readers to the official sockets specification. Its historical contribution is narrower and more useful: old membership calls were protected, single-source changes stayed cheap, and a complete filter could still be replaced in one step when state or scale called for it. Read through Lu Heng's later Notes 64 and 65, this is an example of compatibility and local adoption as design lenses—not a claim that he authored, endorsed or influenced the 2004 memo. RFC 3678 status Note 64 Note 65

Sources