]> 5}="yes"?> Futurewei Technologies USA

USA tte@cs.fau.de

PIM This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces for everything but its specification of the IGMP version 1 protocol.

STATUS OF THIS MEMO [ To be removed before publication: Summary of considerations for reviews by different groups: This -bis is intended to replace RFC1112 maintaining it internet standard designation, but extending it for IPv6, additional terminology (ASM/SSM), and refining the specification with established industry practices. The core parts of the document are changed as little as possible to maintain all original rfc1112 text (except IGMPv1) as much as possible - given how it has very well stood the test of time: all well-known IP multicast host stack implementations including IPv6 - even though unspecified there - are based on the principles of rfc1112. New sections and existing, minimally changed sections can easily be recognized by using rfcdiff against RFC1112. All changes/enhancements are meticulously matched against implementation and operational practices that have evolved and are detailled in this memo: this -bis should match the ubiquitously deployed IP multicast service better than rfc1112. SECDIR is asked primarily to review section 12 (Security Considerations). INTDIR: This document would logically belong to INT as it extends the IPv4/IPv6 host stack for IP Multicast (and references to SSM). It simply evolved as a PIM document due to PIM-WG ongoing ownership of all of IP multicast below application layer. IPv6 is added mostly "by-reference", because in the absence of an earlier attempt to add IPv6 support into an rfc1112bis, all normatively necessary aspects of IPv6 multicast where added to a scattered set of RFCs, which are now comprehensively referenced in this memo. TSVDIR: Consider this document to be normative for all "UDP" independent service and abstract API aspects of datagram IP multicast service. Its hence related to the work by TAPS. The Security Considerations sections specifically discusses challenges of adopting the socket model from unicast to multicast. IOTDIR: IP multicast is widely in IOT, often without IP multicast routing just locally in LANs, radio-LANs. This memo should be the best common reference for the quirks of IP multcast host stacks, specifically with the added discussion of link-local addresses and socket (security) challenges. ] This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces for everything except for its specification of the IGMP version 1 protocol.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

INTRODUCTION

Summary This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast. It replaces for everything except the specification of the IGMP version 1 protocol in Appendix I of . This document declares , including IGMP version 1, historic. specified IP multicast for version 4 of the IP protocol (IPv4, ), and referred to that version as IP. This document applies both to version 4 of the IP protocol and version 6 of the IP protocol (IPv6, ). THE TERM IP IS USED IN THIS DOCUMENT FOR TEXT APPLYING EQUALLY TO IPv4 AND IPv6. Where specifications in support of IP multicast for version 6 of the IP protocol were already provided by other RFCs, this document provides references to those pre-existing specifications, so that this document can serve as a complete single point of reference for the host extensions for IP multicast with either version of IP. "Source Specific Multicast" (SSM, ) introduced a complementary extension to the IP service specified here. It relies on all aspects of the host stack extensions specified here, such as , and uses or extends them. The service specified here is called "Any Source Multicast" (ASM) to distinguish it explicitly from SSM. This document also describes where SSM changes specifications from . Due to the existence of both ASM and SSM, the term "IP multicast" best refers to the complete set of IP host extensions in support of either service option: this specification for ASM plus . When the term IP multicast is used to refer to the IP multicast service without further qualification, ASM is implied. See also . This specification aims to maintain all the original text of where technically appropriate. This entails the use of some historic language, such as "(internet) gateway" to sometimes refer to IP routers, and capitalization of chapter headings. [RFCeditor: please remove this remark before publication. Reviewers: Please use rfcdiff to easier recognize the sections inherited from RFC1112 and distinguish them from new chapters and sections. The pre-existing text attempts to include only necessary technical enhancements but not other editorial enhancements. ] See and for a detailed list of changes from .

Overview IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e., the datagram is not guaranteed to arrive intact at all members of the destination group or in the same order relative to other datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it. A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address, not the membership of the group, that is permanent; at any time a permanent group may have any number of members, even zero. Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups which exist only as long as they have members. Internetwork forwarding of IP multicast datagrams is handled by "multicast routers" which may be co-resident with, or separate from, internet gateways. A host transmits an IP multicast datagram as a local network multicast which reaches all immediately-neighboring members of the destination host group. If the datagram has an IPv4 time-to-live or IPv6 hop limit greater than 1, the multicast router(s) attached to the local network take responsibility for forwarding it towards all other networks that have members of the destination group. On those other member networks that are reachable within the IPv4 time-to-live or IPv6 hop limit, an attached multicast router completes delivery by transmitting the datagram as a local multicast. This memo specifies the extensions required of a host IP implementation to support IP multicasting, where a "host" is any internet host or gateway other than those acting as multicast routers. The algorithms and protocols used within and between multicast routers are transparent to hosts and are specified in separate documents. This memo also does not specify how local network multicasting is accomplished for all types of network, although it does specify the required service interface to an arbitrary local network and gives an Ethernet specification as an example. Specifications for other types of network will be the subject of future memos.

LEVELS OF CONFORMANCE There are four levels of conformance to this specification. They apply independently for IPv4 and IPv6. All Internet hosts and gateways are RECOMMENDED to conform to Level 2 for the versions of IP that they support. Hosts or gateways supporting IPv4 that cannot conform to Level 2 for it are RECOMMENDED to conform to Level 2L. Hosts or gateways supporting IPv6 that cannot conform to Level 2 for IPv6 are REQUIRED to conform to Level 2L. This option is introduced in support of the requirements from , section 2.8. See also for further explanations of the use of link local addresses.

Level 0: no support for IP multicasting. Level 0 hosts will, in general, be unaffected by multicast activity. The only exception arises on some types of local network, where the presence of level 1 or 2 hosts may cause misdelivery of multicast IP datagrams to level 0 hosts. Such datagrams can easily be identified by the presence of an IP multicast address in their destination address field; they SHOULD be quietly discarded by hosts that do not support IP multicasting. Class D addresses in support of multicasting with IPv4 are described in ; IPv6 addresses for IP multicasting are described in section 2.7 of and .

Level 1: support for sending but not receiving multicast IP datagrams. Level 1 allows a host to partake of some multicast-based services, such as resource location or status reporting, but it does not allow a host to join any host groups. An IP implementation may be upgraded from level 0 to level 1 very easily and with little new code. Only sections 4, 5, and 6 of this memo are applicable to level 1 implementations.

Level 2: full support for IP multicasting. Level 2 allows a host to join and leave host groups, as well as send IP datagrams to host groups. Most IPv6 hosts require Level 2 support because IPv6 Neighbor Discovery (, as used on most link types, see , section 5.4) depends on multicast and requires that nodes join Solicited Node multicast addresses. Level 2 requires implementation of the host side of the Internet Group Management Protocol (IGMP) for IPv4 and the equivalent host side of the Multicast Listener Discovery Protocol (MLD) for IPv6 and extension of the IP and local network service interfaces within the host as specified or referred to in the following sections. The current protocol versions for full Level 2 support of IP multicasting are and or lightweight versions of either protocol . All of the following sections of this memo are applicable to level 2 implementations.

Level 2L: support for only link local IP multicasting. Level 2L has the same functionality as Level 2 except that it does not include the implementation of IGMP for IPv4 or MLD for IPv6. Level 2L hosts can only send/receive IP multicast on their local network. Level 2L hosts SHOULD only join/leave Link-Local host groups (see ) and send IP datagrams to Link-Local host groups - but not other host groups.

HOST GROUP ADDRESSES IPv4 Host groups are identified by class D IPv4 addresses, i.e., those with "1110" as their high-order four bits. Class E IPv4 addresses, i.e., those with "1111" as their high-order four bits, are reserved for future addressing modes. In Internet standard "dotted decimal" notation, IPv4 host group addresses range from 224.0.0.0 to 239.255.255.255. IPv4 host group addresses in the "Local Network Control Block", 224.0.0.0 - 224.0.0.255, are called Link-Local IPv4 host group addresses. IP datagrams with a Link-Local destination address are called Link-Local multicast packets. The IPv4 link local address 224.0.0.0 is guaranteed not to be assigned to any group, and 224.0.0.1 is assigned to the permanent group of all IPv4 hosts (including gateways). This is used to address all IP multicast hosts (including gateways) on the directly connected network. There is no multicast address (or any other IP address) for all hosts on the total Internet. For naming consistency across versions of IP, this document calls 224.0.0.1 the all-nodes group. It was called the all-hosts group in and is called the all-systems group in and the IANA "IPv4 Multicast Address Space" registry . Its IPv6 equivalent is called the all-nodes group, as introduced by , section 2.7.1, and the IANA "IPv6 Multicast Address Space" registry . The addresses of well-known, permanent IPv4 multicast groups are to be published in "Assigned Numbers", see , currently through the IANA "IPv4 Multicast Address Space" Registry . and specify more detailed allocation and use of different sub-blocks of 224.0.0.0/4. Allocation guidelines for Link-Local IPv4 multicast group addresses are specified in , section 4. The IPv6 Link-Local all-nodes group address is ff02::1. IPv6 Host groups are identified by IPv6 addresses as defined in section 2.7 and updated by and . The addresses of other groups are currently published via the IANA "IPv6 Multicast Address Space" registry . IP addresses as specified in are not used for ASM IP multicast and are not considered host groups by , Terminology section, third paragraph. They are instead only the destination address part G of Source Specific Multicast (SSM) IP multicast (S,G) channels. The term IP multicast address covers both ASM host group addresses and SSM destination addresses. contains some background discussion of several issues related to host group addresses.

MODEL OF A HOST IP IMPLEMENTATION The multicast extensions to a host IP implementation are specified in terms of the layered model illustrated below in . In this model, ICMP/ICMPv6 and (for level 2 hosts) IGMP/MLD are considered to be implemented within the IP module, and the mapping of IP addresses to local network addresses is considered to be the responsibility of local network modules. This model is for expository purposes only, and should not be construed as constraining an actual implementation.

Note that as described in , ND () itself operates on top of the IPv6 Service Interface as extended by this document because it relies on sending/receiving IPv6 multicast packets. However, it is shown as part of the Local Network Module because that is the component in this host stack model that relies on ND to perform its operation. To provide level 1 multicasting, a host IP implementation MUST support the transmission of multicast IP datagrams. To provide level 2 multicasting, a host MUST also support the reception of multicast IP datagrams. Each of these two new services is described in a separate section, below. For each service, extensions are specified for the IP service interface, the IP module, the local network service interface, and an Ethernet local network module. Extensions to local network modules other than Ethernet are mentioned briefly, but are not specified in detail.

SENDING MULTICAST IP DATAGRAMS

Extensions to the IP Service Interface Multicast IP datagrams are sent using the same "Send IP" operation used to send unicast IP datagrams; an upper-layer protocol module merely specifies an IP host group address, rather than an individual IP address, as the destination. However, a number of extensions may be necessary or desirable. First, the service interface SHOULD provide a way for the upper-layer protocol to specify the IPv4 time-to-live or IPv6 hop limit of an outgoing multicast datagram, if such a capability does not already exist. If the upper-layer protocol chooses not to specify a time-to-live/hop limit, it SHOULD default to 1 for all multicast IP datagrams, so that an explicit choice is required to multicast beyond a single network. Second, for hosts that may be attached to more than one network, the service interface SHOULD provide a way for the upper-layer protocol to identify which network interface is to be used for the multicast transmission. Only one interface is used for the initial transmission; multicast routers are responsible for forwarding to any other networks, if necessary. If the upper-layer protocol chooses not to identify an outgoing interface, a default interface SHOULD be used, preferably under the control of system management. Third (level 2/2L implementations only), for the case in which the host is itself a member of a group to which a datagram is being sent, the service interface SHOULD provide a way for the upper-layer protocol to inhibit local delivery of the datagram; by default, a copy of the datagram is looped back. This is a performance optimization for upper-layer protocols that restrict the membership of a group to one process per host (such as a routing protocol), or that handle loopback of group communication at a higher layer (such as a multicast transport protocol). IPv6 socket extensions supporting these functions are defined in , section 5.2.

Extensions to the IP Module To support the sending of multicast IP datagrams, the IP module MUST be extended to recognize IP host group addresses when routing outgoing datagrams. Most IP implementations include the following logic:

To allow multicast transmissions, the routing logic MUST be changed to:

If the sending host is itself a member of the destination group on the outgoing interface, a copy of the outgoing datagram MUST be looped-back for local delivery, unless inhibited by the sender. (Level 2/2L implementations only.) The IP source address of the outgoing datagram MUST be one of the individual addresses corresponding to the outgoing interface. An IP multicast address MUST NOT be placed in the source address field or anywhere in a source route or record route option of an outgoing IP datagram. These packets are not IP multicast packets but simply invalid packets.

Extensions to the Local Network Service Interface No change to the local network service interface is required to support the sending of multicast IP datagrams. The IP module merely specifies an IP host group destination, rather than an individual IP destination, when it invokes the existing "Send Local" operation.

Extensions to an Ethernet Local Network Module The Ethernet directly supports the sending of local multicast packets by allowing multicast addresses in the destination field of Ethernet packets. All that is needed to support the sending of multicast IP datagrams is a procedure for mapping IP host group addresses to Ethernet multicast addresses. An IPv4 host group address is mapped to an Ethernet multicast address by placing the low-order 23-bits of the IPv4 address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IPv4 host group address, more than one host group address may map to the same Ethernet multicast address. These address mappings apply not only to host group addresses, but also to IP multicast addresses that are SSM destination addresses. Mapping of IPv6 multicast addresses (both host group addresses and SSM destination addresses) to Ethernet addresses is defined in and . Note that establishes an "IANA OUI Ethernet Numbers" registry covering the IPv4 and IPv6 multicast MAC address ranges.

Extensions to Local Network Modules other than Ethernet Other networks that directly support multicasting, such as rings or buses conforming to the IEEE 802.2 standard, may be handled the same way as Ethernet for the purpose of sending multicast IP datagrams. For a network that supports broadcast but not multicast, such as the Experimental Ethernet, all IP host group addresses may be mapped to a single local broadcast address (at the cost of increased overhead on all local hosts). For a point-to-point link joining two hosts (or a host and a multicast router), multicasts SHOULD be transmitted exactly like unicasts. For a store-and-forward network like the ARPANET or a public X.25 network, all IP host group addresses might be mapped to the well-known local address of an IP multicast router; a router on such a network would take responsibility for completing multicast delivery within the network as well as among networks.

RECEIVING MULTICAST IP DATAGRAMS

Extensions to the IP Service Interface Incoming multicast IP datagrams are received by upper-layer protocol modules using the same "Receive IP" operation as normal, unicast datagrams. Selection of a destination upper-layer protocol is based on the protocol field in the IPv4 header or the next header field in the IPv6 header or IPv6 extension header preceding the upper-layer protocol header (when IPv6 extension headers are used). This is regardless of the destination IP address. However, before any datagrams destined to a particular group can be received, an upper-layer protocol must ask the IP module to join that group. Thus, the IP service interface MUST be extended to provide two new operations:

The JoinHostGroup operation requests that this host become a member of the host group identified by "group-address" on the given network interface. The LeaveGroup operation requests that this host give up its membership in the host group identified by "group-address" on the given network interface. The interface argument may be omitted on hosts that support only one interface. For hosts that may be attached to more than one network, the upper-layer protocol may choose to leave the interface unspecified, in which case the request will apply to the default interface for sending multicast datagrams (see section 6.1). It is permissible to join the same group on more than one interface, in which case duplicate multicast datagrams may be received. It is also permissible for more than one upper-layer protocol to request membership in the same group. Both operations SHOULD return immediately (i.e., they are non- blocking operations), indicating success or failure. Either operation may fail due to an invalid group address or interface identifier. JoinHostGroup may fail due to lack of local resources. LeaveHostGroup may fail because the host does not belong to the given group on the given interface. LeaveHostGroup may succeed, but the membership persist, if more than one upper-layer protocol has requested membership in the same group. IPv6 socket extensions supporting these functions are defined in , section 5.2. specifies socket options for these functions for ASM and also includes socket options in support of SSM. See also .

Extensions to the IP Module To support the reception of multicast IP datagrams, the IP module MUST be extended to maintain a list of host group memberships associated with each network interface. An incoming datagram destined to one of those groups is processed exactly the same way as datagrams destined to one of the host's individual addresses. Incoming datagrams destined to groups to which the host does not belong are discarded without generating any error report or log entry. On hosts with more than one network interface, if a datagram arrives via one interface, destined for a group to which the host belongs only on a different interface, the datagram MUST be quietly discarded. (These cases should occur only as a result of inadequate multicast address filtering in a local network module.) An incoming datagram is not rejected for having an IPv4 time-to-live of 1 or IPv6 Hop Limit of 1. This field MUST NOT automatically be decremented on arriving datagrams that are not being forwarded. An incoming datagram with an IP multicast address in its source address field is quietly discarded. An ICMP/ICMPv6 error message (Destination Unreachable, Time Exceeded, Parameter Problem, Source Quench, or Redirect) is never generated in response to a datagram destined to an IP host group or SSM range destination IP address. The list of host group memberships is updated in response to JoinHostGroup and LeaveHostGroup requests from upper-layer protocols. Each membership should have an associated reference count or similar mechanism to handle multiple requests to join and leave the same group. On the first request to join and the last request to leave a group on a given interface, the local network module for that interface is notified, so that it may update its multicast reception filter (see section 7.3). When supporting Level 2, the IP module MUST also be extended to implement the IGMP protocol for IPv4 and the MLD protocol for IPv6 depending on the version(s) of IP to be supported. IGMP/MLD are used to keep neighboring multicast routers informed of the host group memberships present on a particular local network. Level 2 hosts and gateways MAY omit the sending of IGMP messages to report membership for Link-Local IPv4 host group addresses, especially on networks known not to (be able to) use any form of IGMP snooping. This also applies to the IPv6 Link-Local all-nodes group ff02::1, but not to other Link-Local IPv6 host group addresses. See and . Level 2/2L hosts and gateways SHOULD permanently join the Link-Local all-nodes group for the version of IP they implement. See .

Extensions to the Local Network Service Interface Incoming local network multicast packets are delivered to the IP module using the same "Receive Local" operation as local network unicast packets. To allow the IP module to tell the local network module which multicast packets to accept, the local network service interface is extended to provide two new operations:

where "group-address" is an IP host group address. The JoinLocalGroup operation requests the local network module to accept and deliver up subsequently arriving packets destined to the given IP host group address. The LeaveLocalGroup operation requests the local network module to stop delivering up packets destined to the given IP host group address. The local network module is expected to map the IP host group addresses to local network addresses as required to update its multicast reception filter. Any local network module is free to ignore LeaveLocalGroup requests, and may deliver up packets destined to more addresses than just those specified in JoinLocalGroup requests, if it is unable to filter incoming packets adequately. The local network module MUST NOT deliver up any multicast packets that were transmitted from that module; loopback of multicasts is handled at the IP layer or higher.

Extensions to an Ethernet Local Network Module To support the reception of multicast IP datagrams, an Ethernet module MUST be able to receive packets addressed to the Ethernet multicast addresses that correspond to the host's IP multicast addresses (host group addresses or SSM destination addresses). It is highly desirable to take advantage of any address filtering capabilities that the Ethernet hardware interface may have, so that the host receives only those packets that are destined to it. Unfortunately, many current Ethernet interfaces have a small limit on the number of addresses that the hardware can be configured to recognize. Nevertheless, an implementation MUST be capable of listening on an arbitrary number of Ethernet multicast addresses, which may mean "opening up" the address filter to accept all multicast packets during those periods when the number of addresses exceeds the limit of the filter. For interfaces with inadequate hardware address filtering, it may be desirable (for performance reasons) to perform Ethernet address filtering within the software of the Ethernet module. This is not mandatory, however, because the IP module performs its own filtering based on IP destination addresses.

Extensions to Local Network Modules other than Ethernet Other multicast networks, such as IEEE 802.2 networks, can be handled the same way as Ethernet for the purpose of receiving multicast IP datagrams. For pure broadcast networks, such as the Experimental Ethernet, all incoming broadcast packets can be accepted and passed to the IP module for IP-level filtering. On point-to-point or store-and-forward networks, multicast IP datagrams will arrive as local network unicasts, so no change to the local network module should be necessary.

ROUTING MULTICAST IP DATAGRAMS IP multicast routers are recommended to support the IP host stack extensions as specified in this document especially to support applications using the IP Service Interface (, ) to send/receive IP multicast packets including those commonly required for IPv6 (). Because the behavior of IP multicast routers, including their behavior for IGMP/MLD, differs from that of other nodes, their Local Network Module layer and IGMP/MLD protocol requirements MAY be optimized/changed from what is required by this document. See for more details/examples. IPv4 datagrams with a Link-Local destination address MUST NOT be forwarded to a different link by multicast routers, regardless of their time-to-live. See for explanations. The equivalent requirement is specified for IPv6 in , section 2.5.6. Rules for forwarding of non Link-Local IP multicast packets are outside the scope of this document.

Status changes

Moving RFC1112 and IGMPv1 to historic status This document moves to historic status, which also moves the IGMP version 1 protocol as specified in Appendix I of to historic status, as it is no longer included in this document. All other aspects of besides IGMPv1 are kept and updated by this document and maintain their current Internet Standard designation from through the normative status of this document.

Backward compatibility with IGMPv1 Current versions of IGMP (, ) and other protocols/mechanisms including, but not limited to, and do include backward compatibility with IGMPv1. This requires them to refer to as the specification for IGMPv1. Backward compatibility here means that a specification supports IGMPv1 in addition to any newer version of IGMP starting with , and prefers the newer version over IGMPv1. This document does not ask for any change to any current or future specifications or implementations that include any form of support for IGMPv1 for backward compatibility reasons. Any new or updated specification that wants to maintain such backward compatibility with IGMPv1 needs to continue to reference as the specification of IGMPv1. Any future reference for new or updated work to any other definition from (host extensions for IP multicast and/or Any Source Multicast service) needs to refer to this document instead of .

Update to RFC 791 This document is an update to because none of the core procedures to send and receive IP multicast packets described in this document match those defined for IP unicast packets in . Instead, IP multicast carves out parts of the IP address space to trigger completely new forwarding for completely new entities: host groups in ASM, channels in SSM. [RFC-editor: please remove the following sentence before publication.] See for further discussions.

Update to RFC 1122 This document updates section 3.2.3 by making support for Level 2 conformance and hence support for IGMP recommended instead of optional, as specified by . See .

Update to STD 5 This document replaces in , which defines IPv4 () including its core extensions. Note: As there is no precedent for STD86 (IPv6) to include any specifications for extension of IPv6, this document does not ask to become part of STD86.

Changes from RFC1112 Beyond the status changes described in , this document introduces the following changes over . All changes to requirements are intended to make this specification aligned with long-term, most widely implemented, deployed and standardized RFCs for IP multicast, so that this document does not create the need to change existing implementations or deployments, as could be the case if (without IGMPv1) were to be implemented today.

Normative language This document introduces the use of normative language through capitalization. preceded and hence did not include this language.

References to IGMPv1 References to IGMPv1 in are replaced with references to in this text.

New summary The new summarizes the scope of this document and the core new changes over .

Any-Source Multicast (ASM) This update introduces the term "ASM IP multicast" (ASM) as a new term for the IP service interface specified in this document (and previously in ) as explained in .

SSM explains the relationship of this document to SSM (). adds the specification that the term host group specified in this document does not apply to destination addresses used for SSM. The term IP multicast address applies to both host group addresses and SSM destination addresses. No functional changes to the IP multicast service are incurred by these changes, except that it acknowledges the existence of SSM which reduces the range of host group addresses used for ASM.

Applicability to both IPv4 and IPv6 This document is written to apply to both IPv4 and IPv6 by adding detail for IPv6 where only covered IPv4. This includes addressing and protocols in support of the service - Multicast Listener Discovery for IPv6 versus IGMP for IPv4. IPv6 documents such as and all its updates (e.g., ) define the necessary wire encoding aspects of IP multicast under the assumption of the service of for IPv6, but without being able to refer to , as it was only defined for IPv4. Future documents can refer to this document as the IP multicast / ASM service for both IPv4 and IPv6. Additional text provides references for IETF UDP socket API specifications that instantiate the abstract APIs defined in this document. No functional changes to the IP multicast service are incurred by these changes.

RFC1122 and Level 2L did not require support for IPv4 multicasting ("there is at this time no requirement that all IP implementations support IP multicasting"). Instead, recommends support for IPv4 multicast (according to ), but makes support for IGMP optional, specifying that sending/receiving IPv4 multicast from/to the local networks works without IGMP and that this is the recommended form to support IPv4 multicasting. See also . Whereas was not even specifying the combination of supporting sending/receiving IPv4 multicast but not supporting IGMP, this document now adds that option by specifying it as conformance Level 2L. Introducing this text also does not change long-term deployment practices but only formalizes them.

RFC4291 and Level 2L According to , IPv6 nodes must support a variety of Link-Local IPv6 multicast addresses. This translates into the requirement for IPv6 hosts to at least support Level 2L, which is sufficient to support Link-Local IPv6 multicast. Choosing to support only Level 2L is also the only option in which an IPv6 host or gateway will not need to send MLD messages for Link-Local groups because the specification (unlike IGMP) chose to mandate the sending of MLD messages even for Link-Local host groups. See for more details.

IP multicast support With now being Internet Standard, there is sufficient experience to also make support for conformance Level 2 of IPv4 multicasting recommended through this document. This is also documented as an update to the IGMP support requirement in from optional to recommended. See . Unlike , does not directly raise a requirement for support of MLD for every node supporting IPv6. Instead, it explains the dependencies on IPv6 multicast and hence MLD for core IPv6 protocols used on most link types (ND, SLAAC). With now being Internet standard, and over two decades of experience with IPv6 multicast availability and use on almost all IPv6 implementations, this document now also recommends support for Level 2 conformance for IPv6 multicast, see . Note that this is not declared as an update to , because it is outside that BCP document's scope.

IPv4 Local Network Control Block defines the requirement for IPv4 datagrams to the all-nodes group 224.0.0.1 to never be forwarded beyond a single network. In later RFCs, this behavior became the BCP for the whole IPv4 Local Network Control Block 224.0.0.0 - 224.0.0.255, making it the Link-Local host group address block for IPv4 multicast. and , section 4 are the BCPs covering this requirement. This document formalizes this BCP behavior as a standard requirement in , superseding and encompassing the more specific requirement for just 224.0.0.1 from , and mirroring the same standardized behavior for IPv6 link local addresses. Because this is actually a requirement on IP multicast routers and not hosts, this is now also accordingly described in a separate section. This requirement does not incur changes to how IP multicast is implemented or deployed.

Permanent membership for Link-Local all-nodes groups , section 7.2 introduced the requirement for hosts to permanently join 224.0.0.1. It explains this requirement to be in support of IGMP (version 1). , section 6. and , section 5. inherit this requirement, and , section 6. and section 6. also define the same requirement for the IPv6 Link-Local all-nodes address ff02::1. explains this choice with "(1) it is simpler", and "(3) the all-hosts address may serve other routing-oriented purposes, such as advertising the presence of gateways or resolving local addresses." Technically, there is no necessity to permanently join the Link-Local all-nodes group. Like any other group, reception of packets could be enabled through the JoinHostGroup()/LeaveHostGroup(), as described in . However, all known host implementations that support IP multicast since are based on its definitions and there is no obvious benefit in changing this. Hence this functionality is a SHOULD requirement in this document. Note that one simplification that this requirement enables is to avoid supporting the JoinHostGroup()/LeaveHostGroup() API inside an operating system kernel, but still allow kernel level protocols to receive packets sent to the Link-Local all-nodes group. This is for example common in support of ICMP/ICMPv6 echo: "ping 224.0.0.1" to discover IP hosts with IP multicast support on the local network. However, this functionality is not enabled by default anymore in modern systems for security reasons (e.g., Linux: net.ipv4.icmp_echo_ignore_broadcasts=1 default configuration). The requirements text in this spec therefore does not incur any requirements changes for implementations of these existing versions of IGMP/MLD. By making the requirement only a SHOULD, it is also clear that future versions of IGMP/MLD or new host stack implementations may change this if they find good reasons to do so - without requiring an update to this specification. Note that omits this requirement.

IGMP/MLD messages for Link-Local IP host group addresses , Appendix I (IGMPv1), , , , require hosts to not send IGMP/MLD messages for the all-nodes group. This would be in conflict with the general rules of (outside of its IGMPv1 specific definitions), and equally with this specification if it were not enhanced. This specification therefore contains new text that makes it compatible with existing IGMP/MLD specifications, and with long-term established and deployed implementation practices. New text in explains how after , it became a commonplace implementation choice to not send IGMP messages for any IPv4 Link-Local host group address, and explains how this was done with good technical reason at the time. This behavior is so common that mandates explicit support for it in IGMP snooping implementations. Referring to that explanation, a new MAY requirement in allowing (but not recommending) this behavior makes existing specifications and deployments compatible with this document's specifications. It is only a MAY even though it is common in IPv4, because the experience with IPv6 shows that it does work (of course) equally well if this is not done, and can then support better MLD snooping than IGMP snooping.

Standard for IP multicasting in controlled networks This document removes the claim in the abstract of that these host extensions are "... the recommended standard for IP multicasting in the Internet." The reason for this is that deprecated the ASM service across the Internet because there is no Internet Standard solution for protocols to support interdomain ASM except for , which is only applicable to IPv6, and even that solution does not resolve the challenges to source access control in interdomain deployments. As a result, ASM is today "only" a recommended solution for controlled networks including controlled federated networks for applications for which SSM is not preferable. However, these limitations to the applicability of ASM do not impact the applicability of any parts of the host stack described in this document for other IP multicast service interfaces, specifically "Source Specific Multicast", , which inherits all aspects of ASM specified in this document, especially the sending (, ) of IP multicast packets as well as the mapping to Ethernet (). It only amends the joining of IP multicast traffic on IP multicast receivers with additional procedures fitting into the host stack described in this document.

Terminology In , all IPv4 multicast addresses were designated to be used with ASM and were thus host group addresses. As a result, the terms multicast address and host group address could be used interchangeably. With the introduction of SSM in , subsets of IP multicast addresses were carved out for use with SSM instead of ASM. Since then, not every multicast address is a host group address, but every host group address is still a multicast address. In , the equivalent to a host group is the SSM channel. It is addressed by the packets (S,G) - the combination of the unicast source and multicast destination address. Multicast addresses used for SSM by themselves are called SSM destination addresses. Terms like "SSM channel address" or "SSM multicast address" are ambiguous and should be avoided: They could either refer to a specific (S,G) channel, in which case it should be called an SSM channel (S,G) address pair, or it could refer to a multicast destination address G used for SSM, which can be part of many different SSM (Si,G) channels, in which case it should be called an SSM destination address. Specifications whose behavior does not differ between ASM and SSM can continue to refer to multicast addresses, implying the meaning of multicast to be the superset of ASM and SSM. This is for example true for and . New documents should explicitly indicate whether they apply to only ASM and/or SSM even if their behavior applies to both ASM and SSM identically. Otherwise, it is left to the reader to guess whether the text also applies to SSM. If the term multicast is used to indicate behavior that only applies to ASM, this should equally be called out explicitly. Behavior applying only to ASM may use the terms host group address or ASM multicast address.

IANA Considerations

Protocol Numbers registry IANA is asked to replace the Reference field for the IGMP protocol in the Protocol Numbers registry from to [THIS-RFC]. Explanation: This protocol number is used by all versions of IGMP, including and and is unaffected by making IGMP version 1 historic.

IGMP Type Numbers registry IANA is asked to replace the Reference to for the 0x11 / "IGMP Membership Query" entry in the "IGMP Type Numbers" registry with ", [RFC2236], [RFC3376]". Explanation: This message type was introduced by , but modified versions of it were also introduced by [RFC2236] and [RFC3376], so it is clearer to list all three RFCs. All other references to in this registry are specifically referring to that RFC in its role of defining IGMP version 1 and thus need to continue to refer to and not [THIS-RFC].

Multicast 48-bit MAC Addresses registry IANA is asked to replace the Reference field for the IPv4 Multicast range entry in the "IANA Multicast 48-bit MAC Addresses" registry from to [THIS-RFC].

IPv4 address range registries IANA is asked to replace the Reference field for the 240.0.0.0/4 entry in the "IPv4 Special-Purpose Address Space" registry from to [THIS-RFC], . IANA is asked to replace the Reference to in the "IPv4 Address Space" registry with [THIS-RFC].

IPv4 Multicast Address Space registry IANA is asked to replace the three references to in the "IPv4 Multicast Address Space" registry with [THIS-RFC].

IP Flow Information Export registry IANA is asked to replace the two references to in the "IPFIX Information Elements" registry with [THIS-RFC].

Security Considerations This section may repeat a few core observations from elsewhere in the document to make it easier for security-interested readers to understand the context without having to understand the whole document. Application Socket Security Considerations are outside the scope of this document yet important for secure operations of an IP multicast host stack. They are hence covered in .

Network forwarding issues Security issues exist in an internetwork when sending IP multicast packets or when joining IP multicast groups leads to internetwork state. Nevertheless, those issues are not caused by the ASM service model itself but are the result of specific choices of forwarding of ASM traffic across routers. For example, these issues do not exist if the internetwork is simply a stateless broadcast domain such as a (non-switched) Ethernet or Wi-Fi network, or if the network uses a stateless forwarding model in routers such as Bit Index Explicit Replication (). Therefore the remainder of this section focuses on issues directly linked to the aspects specified in this document: ASM service model, host stack and some relevant L2 network technologies.

Receiver control Senders in ASM cannot control who receives their traffic because any host can join the group that the sender sends to. The larger address space of IPv6 multicast groups may make it harder for an IPv6 multicast address to be successfully discovered by undesired receivers, but many IPv6 multicast addresses are not random but well-defined. Encryption of ASM traffic and sharing of keys with only desired receivers is another solution against this challenge. For example, specifies a key management mechanism for secure sharing of symmetric group communication keys for ASM (which could also be applied to SSM). Some types of deployed IP multicast based application services such as multicasting of high-value content do not consider such group encryption keys as secure enough alone, especially when they are shared between a large number of legitimate but not necessarily trustworthy receivers. A single compromised receiver may be set up to extract the shared key and pass it on to illegitimate receivers in real-time. This has widely happened in deployed solutions in the past with multicast/broadcast media content transmitted via IP multicast. In these cases, additional, per receiver, per host group authorization can be used to limit what IP multicast traffic is forwarded by the network to each host. These receiver control options are often available in IP multicast implementations in network equipment but are not IETF standardized. Likewise, hardware and/or software solutions on hosts to prohibit such key extraction can be used. These are commonly called "Trusted Execution Environments" (TEE) and solutions applying them to prohibit content leakage are called "Digital Rights Management" (DRM).

Sender control Receivers in ASM cannot control who is sending traffic to them. Especially in IPv6 with its larger address space, random multicast group addresses (see ) may help to limit undesired senders if all allowed senders and receivers can be trusted not to leak the secret address, and the network towards such legitimate senders and receivers cannot easily be observed by attackers to determine the secret random address. If deployed, network filtering may aid in restricting unexpected or unauthorized traffic. This sender control problem is the same as in unicast except that the methods or likelihoods to keep destination host unicast addresses and ASM group addresses private vary significantly. There is no analysis of ASM group address privacy comparable to . The service model eliminates the sender control challenge by requiring receivers to explicitly indicate the desired sender of the multicast traffic. Using an appropriate forwarding method across the network, is better than unicast in protecting against undesired traffic as it can often stop unwanted SSM traffic from even entering the network, whereas in unicast undesired traffic can only be discarded at the receiver. Note too, that an host stack is an extension of the host stack specified in this document. It only enhances further what is specified here but does not replace it.

Packet spoofing Unless sender control is performed, packet spoofing may not even be necessary to perform equivalent attacks as outlined in . The ease of spoofing a sender IP source address and its layer 2 sender address (such as the sender MAC address on Ethernet) highly depends on the (inter)network between sender and receiver. In a simple broadcast domain without active switches between sender and receiver, IP multicast packets are as easily spoofed as IP packets. If switches are introduced, without , then IP multicast packets are equally easy to spoof because they are still broadcast, whereas IP packets become more difficult to spoof because attackers may not even see IP exchanges between a sender to spoof and its receivers, nor may they know their IP addresses. Introducing somewhat levels the playing field and makes spoofing IP multicast packets more difficult, but as long as an attacker can be a valid receiver of IP multicast packets from a sender it wants to spoof and can guess the IP multicast group(s), it can also learn the source IP address and layer 2 address of the sender it wants to spoof by simply joining its IP multicast traffic. [ Note: In internetworks, routers typically perform RPF checks for IP multicast packets as part of stateful forwarding of IP multicast packets, but this varies by the IP multicast routing / tree building protocol and is, as mentioned in , out of scope. ] Authentication of ASM/SSM traffic with mechanisms relying on symmetric group keys, such as , can protect against many cases of spoofing, but it cannot effectively prohibit sender spoofing by any of the legitimate receivers which could potentially be millions. This is because each legitimate receiver knows the symmetric key required to become a sender. Asymmetric (public) key cryptography resolves this issue but is significantly more computationally expensive than symmetric key cryptography. More advanced mechanisms tackling this issue include TESLA and its follow-up documents in as well as , and .

Address management Receiving IP multicast packets from undesired senders may not be malicious but can simply be a result of absent or incorrect IP multicast group address management that needs to assign unique group addresses to every application instance that needs them. Static allocation of IP multicast groups is the most widely used option in deployment today. Early proposals for dynamic address allocation protocols, including and , have not gained traction and most options do not consider IPv6. See , .

Waste traffic in the absence of address management While it is possible to forego address management and (randomly) share IP multicast groups across multiple application instances simply by de-multiplexing at higher layers such as UDP ports and/or encryption layer selectors, relying solely on those higher layers for traffic separation is highly undesirable. Assume an IP multicast application on host H1 joins IP multicast group G with traffic on UDP port P1. Other applications on other hosts are receivers for other IP multicast applications that all (randomly) also use G, but each uses a separate UDP port P2, ... PN. H1 will receive traffic for all applications and discard the received packets in the UDP/socket layer because of their UDP ports. This "waste traffic" can result in overload of resources in H1 and possible unexpected discarding of packets due to such overload. In switched networks with IGMP/MLD snooping and internetworks with IP multicast routers it can even lead to overload of network path segments towards H1 and discarding of packets to other hosts when traffic is admission controlled and this waste traffic is not taken into account.

Waste traffic due to layer 2 to layer 3 mapping Hosts may need to receive and discard IP multicast packets in their IP module (typically in software) for host groups that they have not joined because of possible N:1 mapping issues in the layer 2 mapping of IP multicast. As described in , in IPv4 224.x.y.z, 224.(x+128).y.z, ..., 239.x.y.z, 239.(x+128).y.z will map to the same MAC address 01-00-5E-xx-yy-zz for x=0..127/xx=hex(x), y=0..255/yy=hex(y), z=0..255/zz=hex(z). For IPv6 over Ethernet, similar mapping issues exist. An only slightly overstated example is a broadcast network where a few high-speed hosts receive a high bitrate IPv4 multicast video stream to address 239.128.0.251 and a very small, low-end CPU alarm siren has to be discovered via on 224.0.0.251. Both addresses map to Ethernet address 01-00-5E-00-00-FB. The software infrastructure (CPU, buffers) on the alarm siren gets overloaded by the high-bitrate IP multicast video stream because those packets are not filtered in the MAC hardware filter, and fails to discover the alarm siren when a fire in the building is discovered by a fire sensor. These issues are resolved by avoiding the use of multiple IP multicast group addresses that map to the same Ethernet MAC address. In practice, industry recommendations primarily focus on avoiding the use of IP multicast group addresses that map to statically assigned link-local IP multicast group addresses to avoid impacting key protocols such as in the example.

Multiple application instances If two or more instances of the same (or similar enough in packet format) applications that do not sufficiently distinguish their instances through higher layer methods (transport layer ports, security selectors, application layer identification of instance) are instantiated and (erroneously) re-use the same IP multicast group, then this will not only cause the aforementioned waste traffic problems, but that waste traffic can also leak into the application where it causes malfunction or other application security issues. Examples of this issue are protocols like which do not have instance differentiation in their packet format, so when supposedly separate instances of OSPF are incorrectly wired together, routing problems occur. In , the common solution against this issue is to rely on the authentication option and simply distinguish instances through separate passwords. This is a practical separation strategy, providing an instance identification to protect against accidental incorrect wiring. Applications using well-known transport layer ports are likewise easily subject to this issue.

MAC filters Joining ASM multicast groups uses resources in the host. The challenges in managing resource exhaustion and/or fair share across multiple applications are similar to those for unicast sockets except that filtering of packet reception at layer 2 will typically consume additional hardware limited filtering resources ("MAC filters").

Acknowledgements Many thanks to Stig Venaas for his thorough review (PIM WG chair). Many thanks to Brian Haberman, Dino Farinacci, Alvaro Retana (RTG AD) and Jim Stevens, Pascal Thubert (INTDIR), Zheng Zhang (RTGDIR), Erik Nordmark (IOTDIR). Special thanks to Rob Hinden. Many thanks to Brian Weis (SECDIR), Kyle Rose and Rob Moskowitz for multicast security input. Many thanks to Amanda Barber for IANA review.

Contributors Steve Deering is the author of , which forms the bulk of the specification content contained herein.

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK] This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376. This document specifies the Multicast Listener Discovery version 2 (MLDv2) protocol. MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document updates RFC 2710 and obsoletes RFC 3810. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community. This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK] This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community. This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community. This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK] This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community. Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community. This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community. This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236. The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK] This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK] This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties. This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community. This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice. This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK] This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK] When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK] The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes. Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291. This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits. This document updates RFCs 3956, 3306, and 4291. This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM). This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042. This document presents an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for the purpose of group key management. The protocol is in conformance with the Multicast Security (MSEC) Group Key Management architecture, which contains two components: member registration and group rekeying. Both components are required for a Group Controller/Key Server (GCKS) to provide authorized Group Members (GMs) with IPsec Group Security Associations (GSAs). The GMs then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (specified in RFCs 4861 and 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address. This document also updates the Routing Protocol for Low-Power and Lossy Networks (RPL) (specified in RFCs 6550 and 6553) to add a new Non-Storing multicast mode and new support for anycast addresses in Storing and Non-Storing modes. This document extends RFC 9010 to enable a 6LoWPAN Router (6LR) to inject the anycast and multicast addresses in RPL. IANA IANA IANA IANA IANA IANA IANA IANA Garmin International, Inc. lispers.net Futurewei This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration ("zeroconf") networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks. lispers.net Futurewei This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). GAAP requires no centralized service or coordination for the address-allocation protocol itself, though it depends on ASM-capable multicast routing already being provisioned in the deployment domain, and deployments using encryption or administrative scoping may require additional configuration. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. This document is Experimental, see Section 8 for the rationale and the criteria for concluding the experiment. Akamai Technologies, Inc. Akamai Technologies, Inc. TU Berlin This document defines Asymmetric Manifest-Based Integrity (AMBI). AMBI allows each receiver or forwarder of a stream of multicast packets to check the integrity of the contents of each packet in the data stream. AMBI operates by passing cryptographically verifiable hashes of the data packets inside manifest messages, and sending the manifests over authenticated out-of-band communication channels. Akamai Technologies, Inc. Akamai Technologies, Inc. Establishing authenticity of a stream of datagrams in the presence of multiple receivers is naively achieved through the use of per-packet asymmetric digital signatures, but at high computational cost for both senders and receivers. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) instead employs relatively cheap symmetric authentication, achieving asymmetry via time-delayed key disclosure, while adding latency to verification and imposing requirements on time synchronization between receivers and the sender to prevent forgery. This document introduces Asymmetric Loss-Tolerant Authentication (ALTA), which employs an acyclic graph of message authentication codes (MACs) transmitted alongside data payloads, with redundancy to enable authentication of all received payloads in the presence of certain patterns of loss, along with regularly paced digital signatures. ALTA requires no time synchronization and enables authentication of payloads as soon as sufficient authentication material has been received. HTT Consulting Boston University This document updates TESLA [RFC4082] to current cryptographic methods for use by the International Civil Aviation Organization (ICAO) in their Global Navigation Satellite System (GNSS) Satellite- based augmentation system (SBAS) authentication protocol. The TESLA updates are to align it with current best practices.

HOST GROUP ADDRESS ISSUES This appendix is not part of the IP multicasting specification, but provides background discussion of several issues related to IP host group addresses.

Group Address Binding The binding of IP host group addresses to physical hosts may be considered a generalization of the binding of IP unicast addresses. An IP unicast address is statically bound to a single local network interface on a single IP network. An IP host group address is dynamically bound to a set of local network interfaces on a set of IP networks. It is important to understand that an IP host group address is NOT bound to a set of IP unicast addresses. The multicast routers do not need to maintain a list of individual members of each host group. For example, a multicast router attached to an Ethernet need associate only a single Ethernet multicast address with each host group having local members, rather than a list of the members' individual IP or Ethernet addresses.

Allocation of Transient Host Group Addresses

Original RFC1112 text This memo does not specify how transient group address are allocated. It is anticipated that different portions of the IP transient host group address space will be allocated using different techniques. For example, there may be a number of servers that can be contacted to acquire a new transient group address. Some higher-level protocols (such as VMTP, specified in ) may generate higher- level transient "process group" or "entity group" addresses which are then algorithmically mapped to a subset of the IP transient host group addresses, similarly to the way that IP host group addresses are mapped to Ethernet multicast addresses. A portion of the IP group address space may be set aside for random allocation by applications that can tolerate occasional collisions with other multicast users, perhaps generating new addresses until a suitably "quiet" one is found. In general, a host cannot assume that datagrams sent to any host group address will reach only the intended hosts, or that datagrams received as a member of a transient host group are intended for the recipient. Misdelivery must be detected at a level above IP, using higher-level identifiers or authentication tokens. Information transmitted to a host group address should be encrypted or governed by administrative routing controls if the sender is concerned about unwanted listeners. See for more details.

Evolution since RFC1112 Historically (in the 1990s), SDP over SAP () was used to multicast the session information of application sessions with transient IPv4 multicast addresses via the MBone's sdr tool. When creating a new application instance, sdr would simply avoid picking any of the already assigned IPv4 multicast addresses as known from other SDP/SAP announcements. section 3.5 summarizes and explains the lack of adoption of mechanisms specified in RFCs since for allocation of transient host group addresses. Current evolving mechanisms for zeroconf dynamic host group addresses are based on . It specifically requires solutions to allocate addresses so that different applications do not use IP multicast addresses that map to the same MAC address. Such mapping would defeat the filtering of most IGMP/MLD snooping switches which most often only operate on the MAC level. One protocol supporting these requirements is .

Link local considerations IGMP/MLD are required for Level 2 hosts on a subnet so that IP multicast routers on the same subnet can forward traffic from senders on other subnets. IGMP/MLD are technically not required for IP multicast packets with link local addresses on a broadcast subnet. Such link local IP multicast cannot have senders on different subnets (), and IP multicast traffic from senders on the same subnet is forwarded to all hosts on the subnet if it is a broadcast subnet. If IGMP/MLD snooping is used in a subnet, the subnet loses its broadcast nature for IP multicast traffic and sending of IGMP/MLD messages is often also required to receive IP multicast traffic from local senders in the same subnet, subject to how the IGMP/MLD snooping switch operates. For IPv4 link local addresses, IGMP snooping must not filter traffic due to the historic non-implementation of IGMP in early hosts (such as IP routers using ) and the limited number of link local groups in IPv4 makes it quite unimportant to improve. In IPv6, there are as many link local addresses as there are in other scopes. Therefore link local IPv6 is well suited for non-network-control traffic, such as any IP multicast application that wants its traffic to be constrained to a single subnet (such as large, single-subnet campus networks with MLD snooping switches). Hence the requirement in to also signal MLD for link local IPv6 multicast addresses. However, subnets can be known to never have IGMP/MLD snooping switches, such as radio subnets in IoT mesh networks. And those subnets can also be known to never require any IP multicast traffic other than link local IP multicast protocol packets that use the host stack. An example of this is radio subnets solely between nodes that only use link-local IPv6 multicast in support of . Further extensions to including (but not limited to) provide additional alternatives to MLD. Nodes implementing (only) these mechanisms can still be seen as being in compliance with this document as long as they operate as an IPv6 multicast router and hence do not have a mandatory requirement for MLD. This is typically the case for nodes. For such subnets, nodes can act as Level 2L hosts, hence avoiding the unnecessary complexity of IGMP/MLD and the radio energy it would cost.

IP multicast router considerations Nodes that are IP multicast routers typically do not use IGMP/MLD to indicate the multicast groups or channels that they need to receive from a subnet. Nor could they in many cases. IGMP/MLD snooping cannot constrain IP multicast traffic to any port with such an IP multicast router connected to it because of this. This is true even in the simplest subnet setup with only IP multicast hosts and just one IP multicast router acting as the IGMP/MLD querier. That gateway needs to see all IP multicast traffic sent by any host onto the subnet - to determine which of that traffic to forward to receivers on other subnets. However, IP multicast routers may also use the IP multicast host stack specified in this document. Consider the case where an IP multicast router sends and/or receives IP multicast packets not because of its IP multicast forwarding function as an IP multicast router, but because these IP multicast packets are sent or received by an application on the gateway, including but not limited to IGMP/MLD protocol packets or IP multicast routing protocol packets such as IP multicast protocol packets. Without further gateway considerations, these packets are logically subject to the host stack requirements of this document. For example, an IP multicast router running IGMPv3 would need to indicate to its own IP host stack the desire to receive packets for 224.0.0.22, resulting in it also sending IGMP membership reports for that address. However, as explained before, even in the presence of IGMP/MLD snooping switches, IP multicast routers need to receive any IP multicast packet on a subnet without themselves sending IGMP/MLD messages to join the traffic. And IGMP/MLD snooping switches support this by manual or automatic detection of ports connected to IP multicast routers. Hence an IP multicast router can safely forego sending IGMP/MLD membership messages for any IP multicast addresses it is joined to as a host: It will receive the traffic anyhow, even in the presence of IGMP/MLD snooping switches, and it will anyhow use its non-IGMP/MLD multicast routing protocol to ensure traffic from other subnets gets forwarded to the subnet. In summary: For hosts (or gateways) that are also IP multicast routers the Level 2 host stack may skip sending IGMP/MLD membership reports to receive IP multicast packets when this is deemed specifically beneficial. This can simply be justified as a case where the behavior of an IP multicast router (which is outside of scope of this document) supersedes the requirements of the host stack as specified here, even if the host stack of the gateway is deviates from the specification of this document. Note that this document gives no recommendations to do this, this appendix purely explains how this could work and be justified when needed - without violating this specification's requirements. Given how most IP multicast routers are just optionally configurable as IP gateways, they would need to conform to the full Level 2 host stack requirements whenever they do not act as an IP multicast gateway, hence optimizing the host stack purely to reduce the amount of code is not an option in those cases.

Application Socket Security Considerations The following section addresses socket security issues beyond the scope of this document. While they are in general independent of the transport protocol used, they most often happen for UDP because of the prevalence of using IP multicast with UDP and because even if other applications for IP multicast exist on hosts (such as ), in most hosts, only UDP can be used for IP multicast by unprivileged and hence more likely malicious applications. The following considerations are not covered by or resolved through the requirements specified by RFCs. Even with correct IP multicast group address management (), or when using SSM: with just the methods specified in this document for the host stack, application sockets may still receive unexpected IP multicast traffic destined to other IP multicast addresses than they joined to. This problem can exist because like , this memo only specifies the host stack up to the IP layer and hence does not include the specification that ASM group membership (or SSM channel membership) has to be per (transport layer) application socket. As a result, early host stacks for IPv4 multicast did indeed have the problem that two UDP sockets each joining to a different IPv4 multicast address but the same UDP port would receive traffic destined to either IPv4 multicast address. This could accordingly cause application malfunctions or other security issues. Such port re-use can easily happen when applications define the use of a well-known UDP port number and just expect (as they should) that different application instances can just use different IP multicast addresses.

IGMPv3/MLDv2 In current host stacks for Level 2 hosts, this problem is usually eliminated when implementations correctly implement the following sentence present in IGMP/MLD specifications since /. After a multicast packet has been accepted from an interface by the IP layer, its subsequent delivery to the application or process that listens on a particular socket depends on the multicast listening state of that socket...

Level 2L Level 2L implementations would equally have to implement their host stack using such per-socket membership even in the absence of IGMP to support equivalent demultiplexing replication and filtering on a per socket basis for received IP multicast packets. Otherwise this filtering would be left up to the application, not only violating reasonable per-socket expectations but also incurring unnecessary overhead: Unnecessary replication and process-level processing of such unnecessary packet copies.

Application socket issues The following issues relate to the current behavior of known (transport layer) application sockets across various operating systems. These behaviors evolved by simply not improving the behavior of BSD sockets for IP multicast from a security perspective and proliferation of that socket model across other operating systems and the POSIX standard. Host stacks by default do not allow multiple application sockets to bind() to the same transport layer port (TCP, UDP or other). This is highly desirable in IP unicast because it guarantees the application with the socket that no other application can be a responder/"server" for that port on the same host/IP-address(es). Likewise, any responder/"client" application can (implicitly or explicitly) bind() to a dynamic, unused port due to the nature of IP unicast initiator/responder protocol exchanges. In IP multicast the default for socket operations is the same, but the impact on IP multicast applications is different. In , or any other IP multicast capable transport protocols using the notion of Source Port and Destination Port, the port that a socket binds to is, as for IP unicast traffic, the Source Port for packets sent and the Destination Port for packets received. When an IP multicast receiver application binds to a port, by default no other application on the same host can receive the same IP multicast traffic. This is not only undesirable when multiple receiver applications for the IP multicast application instance are desired to run on the same host simultaneously, but a malicious attacker application started before a legitimate receiver application can perform a DoS attack against these IP multicast receiver ("client") applications by binding to the known transport layer port that the sender(s) sends to. The comparable attack is not possible in IP (unicast) because, as mentioned above, the client application (unicast initiator) can bind to any free port and then negotiate with the sender that it sends to that Destination Port. In IP multicast the sender of course cannot negotiate with every receiver a separate receiver Destination Port. It must send IP multicast to one port common for all receivers, which then makes that port subject to the attack. Enabling re-binding to the same UDP port on sockets used to receive IP multicast traffic (SO_REUSEADDR/SO_REUSEPORT) allows benevolent applications on the same host to receive the same IP multicast traffic, but known host stacks have no option to force this option on all (receiver) IP multicast sockets to prohibit the aforementioned attack. This is because there is no concept of an IP multicast receiver only socket, and forcing re-use of ports would in most cases be wrong for other types of sockets. For an IP multicast sender application, the attack is different. A malicious application binding to a socket cannot prevent a legitimate sender application from sending to the same port, as it could in IP (unicast). However, an IP multicast sender binding to a port cannot rely on there being no malicious application on the same host sending to the same IP multicast group and Destination Port because the bind only guarantees exclusive use of the Source Port, which is irrelevant in most IP multicast application stacks, for example when using . Arguably, the IP multicast problem is bigger because an IP server application will know at bind() time when it cannot exclusively use the relevant port because of the prior presence of a malicious application on the same host, whereas in IP multicast, the server cannot prevent a later-started malicious application on the same host from impersonating packets with the same Source IP address, IP multicast address and Destination Port number as the legitimate server application. IP multicast applications could recognize the attacking application based on its Source Port instead of only its Source IP address, but that is not common in IP multicast applications / specifications today, such as when using . Even worse, the legitimate sender application itself may not even be able to recognize packets from the malicious sender on the same host if the socket interface allows prohibiting the looping back of IP multicast packets from one socket to any other socket on the local host (IP_MULTICAST_LOOP), which is a commonly supported option in today's socket APIs. In summary, malicious local applications do pose different and potentially more severe risks to IP multicast sender and receiver applications than malicious IP multicast applications running on other hosts with today's application socket semantics.

Discussion and Explanations (TO BE REMOVED) [RFC-editor: Please remove this Appendix after observing the following section addressed to you] Please refer to for the non-process discussion of the goals of this document.

RFC-Editor notes The kramdown tooling did not allow to have references for both STD5 and RFC1112, those fail because the STD5 reference creates an "RFC1112" anchor. Thus there is no separate reference for RFC1112 in this version of the document. This needs to be fixed in XML by adding a full reference to RFC1112 and removing the RFC1112 anchor from the STD5 reference.

Goals and evolution of this document The initial goal of this document was to allow for IETF to declare the IGMPv1 protocol historic which today is a Full Internet Standard due to it being defined in RFC1112. This should be achieved without changing the Full Internet Standard status of the IP Host Extensions for IP multicast and ASM IP service interface specified in RFC1112 because those specification are as fundamental to the definition of IP multicast as RFC791 is for IP (unicast). The best way to achieve this seemed to be an update to RFC1112 which removes all of IGMPv1, but maintains the rest of the document. None of these removal of IGMPv1 changes changed the applicability or requirements to existing IP multicast (plus its protocols) implementations or other specifications. The next refinement was to rectify the situation that there is no specification explaining the same details as RFC1112 for IPv6 multicast even though RFC8200 (full internet standard) even explicitly includes IPv6 multicast, and a range of other RFC define necessary code-points (such as for ethernet mapping) for IPv6 multicast. Most of the text of this specification can hence can simply talk about "IP" which in this specification implies both IPv4 and IPv6, and only in places where IPv6 differs, does the document now include new explicit text, most often pointing to pre-existing RFCs specifying the necessary details for IPv6. Again, none of these changes impact other specs or deployments. The third step of refinement was add the necessary verbiage to explain the differences between SSM and the specifications in this document. None of these text enhancements incur any functional changes of long-term established practices. Instead, they are only resulting in references to SSM RFCs, introduction of the term ASM (which was previously only defined in SSM RFCs), and the limitation of applicability of terms in this document (such as host group) to their use with ASM. The last round of changes added and refined details to be in-line with long-term established practices and removing any possible contradictions between the original RFC1112 text and newer standards track specification such as IGMPv2/MLDv3 or long term established implementation practices. This includes the limitation of scope of ASM to controlled networks and the definition of the IPv4 Link-Local address range, which so far had only been defined through BCP RFC, unlike in IPv6, where it's part of the architecture, as well as permitting (but not recommending) non-use of IGMP for them. In summary, all changes in the document will make this document a replacement of rfc1112 which much more reflects the full internet standard nature of the technology than rfc1112 did as of recent.

Update to RFC791 This version of the text proposes that this spec is declared to be an update to RFC791. The argument made in to support this classification may not be persuasive enough (because the according rfc791 text may be read as a perfectly good extension point specification), in which case the update status and related text should be deleted. However, If anyone where to come up with a re-use of 224.0.0.0/4 for any non-IP multicast purposes, havoc might ensure with devices that do assume IP multicast semantics, so it may simply be prudent to include this declaration. It would also make the relationship between IPv4 and IPv4 multicast be more aligned with IPv6, where IPv6 multicast is included in RFC8200.

Downref considerations This document includes downrefs to , and . These are all Proposed Standards, and they are not in the downref registry (https://datatracker.ietf.org/doc/downref/). They need to be understood to correctly implement the technology of this document, hence they need to be normative references. is already a normative reference of (Internet Standard), and may not be in the downref registry only because updates . is also a normative reference of , so maybe the downref registry is not meant to track downrefs from Internet Standards. This document also introduces a downref to (Draft Standard), which already is in the downref registry.

Changelog This document is hosted at https://github.com/toerless/rfc1112bis. Please submit issues with this text as issues to that github and report them on pim@ietf.org.

draft-ietf-pim-rfc1112bis-10 Moved Steve Deering into Contributor section to be consistent in dealing with prior version authors with RFC9776 and RFC9777. With help of claude.ai: Now using existing bibxml references for IANA registries, removed self-made. Section 11 now also uses bibxml references instead of inline registry URLs. English/grammar nits fixed throughout new text, not detailling. No changes to text inherited from RFC1112. Fixes for technical nits found during English review: Section 4: Fixed pointer to host group address appendix (was "Appendix I" from RFC1112 numbering). Moved sentence about RFC5771 link-local allocation guidelines from IPv6 to IPv4 paragraph (RFC5771 only covers IPv4), added section 4 pointer. Separate references for IANA "IPv4 Multicast Address Space" and "IPv6 Multicast Address Space" registries, each cited in its paragraph. Section 6.2, Section 8: "MUST never" changed to "MUST NOT" (BCP14 keyword). Section 9.3: Update to RFC791: Marked pointer to Appendix B.3 for removal by RFC-editor, as Appendix B is to be removed. Section 10.7: RFC1122 and Level 2L: Second paragraph refers to RFC1112 (not RFC1122) not specifying Level 2L. Section 10.11: Permanent membership for Link-Local all-nodes groups: Fixed quote from RFC1112 to use its original term "all-hosts address". Section 7.2: Pointer for MAY not sending IGMP/MLD for Link-Local groups now refers to 10.12 (was 10.7). Section 11: IANA Considerations: Removed 11.7, which duplicated the request of 11.3 for the same registry entry. 11.4: Replaced unclear "The Section 4 text stays unchanged." with reference to THIS-RFC, Section 4. Section 12.5.2: mDNS address in example fixed to 224.0.0.251 (was 239.0.0.251). References: Fixed UDP (RFC768, was RFC786) and mDNS (RFC6762, was RFC6763). Title: "Any Source Multicasting" changed to "Any Source Multicast", consistent with text and RFC8815. Section 4: Added paragraph explaining the term all-nodes group for 224.0.0.1 vs. all-hosts (RFC1112) and all-systems (IGMPv2/v3, IANA). Section 8: Pointer to IP Service Interface now refers to 6 and 7.1 (was 5, host model). Appendix B: Added Downref considerations.

draft-ietf-pim-rfc1112bis-09 Added IANA registry name fixes as requested by Amanda Barber. Added fixed from review Michael Tuexen. Added note about RFC9685 (thanks Pascal Thubert).

draft-ietf-pim-rfc1112bis-08 Revision including fixes for nits uncovered by directorate reviews. Eric Nordmark (INTDIR), Brian Weis feedback (SECDIR), Sandy Zhang (RTGDIR), Pascal Thubert (INTDIR) Several textual nits fixed, not detailling. Section 6.4: Extensions to Ethernet module Reordered expand last two paragraphs. Added reference to very recent relevant RFC9542 IANA registry for MAC addresses (from Pascal). Section 9.2: Compatibility with IGMPv1 Added definition for "backward compatibility" (with IGMPv1) and refined wording. Section 10: changes over RFC1112: 10.8 removed second paragraph, just pointing to A.3 10.14: Added sub section 10.14 to more comprehensively discuss the correct terms "host group" / "host group address" vs "SSM destination address" vs (ambiguous "SSM multicast address"). RFCs applying equally to ASM/SSM can just use "IP multicast address". RFCs applying to only ASM should use "IP host group address" - etc. pp. 11.7 (IANA asks) added request to replace rfc1112 with thisRFC for the new RFC9542 registry for MAC addresses. 12.3 security considerations clarified/refined/expanded sender control text (Eric, Brian). A.2 appendix for discussion about transient IP multicast addresses moved existing text from Steve Deering (mostly never realized ideas) to historic subsection, added subsection for best decade-long solution SAP/SDP and paragraph about new evolving solution GAAP. Various textual nits. Added text/reference for recent new IANA Multicast / 802x address registries Added explanation for ND in Figure 1. Other: Changed TO_BE_REMOVED_SECTION to indicate keeping it also for IETF/IESG review as it seems usefulto help such further broader reviewers.

draft-ietf-pim-rfc1112bis-07 Revision for early reviews from directorates. Added to-be-removed contextual explanations for those reviews.

draft-ietf-pim-rfc1112bis-06 Added To-Be-Removed note for reviewers to compare with rfc1112 to find pre-existing sections. Removed erroneous reference to UDP in 7.1 (socket calls in referenced docs are not specific to UDP). Changed order of authors. Included fixes from Stig Veenas' review: Variety of typos. Expanded "protocol field in IP header" to be explicit about the complex IPv6 options. Clarified that "IP multicast address" covers host group and SSM channel destination addresses and fixed text that applies to both ASM and SSM touse "IP multicast address" instead of host group (address). removed IGMPv3lite term Added 6 pages of Security Considerations and two pages of Appendix for application socket security considerations.

draft-ietf-pim-rfc1112bis-05 Brian pointing to the requirement to support link-local IPv6 multicast in RFC4291, section 2.8, accordingly changed the requirement to MUST for Level 2L and explanation about that.

draft-ietf-pim-rfc1112bis-04 Some textual nit improvements - introduced "all-nodes also for IPv6 (but be careful to only call it Link-Local, as there are scope relative ones too), adding references to RFC8504, referring to "host-side" impleemntation of IGMP/MLD. Shoveling sentence in 4. to make reading more logical. "Levels of Conformance": Made support for IP multicast (Level 2 = sending/receiving) RECOMMENDED for all IPv4 / IPv6 host stack. For the past 36 years, there was only the RFC1122 requirement (see below) for IPv4. For IPv6 there was no requirement to support IPv6 multicast at all. Instead, there was only a dependency to support it when implementing widespread IPv6 protocols (SLAAC, ND). Section 3.4: Introduction of conformance Level 2L to describe IPv4 multicast with link-local only sending/receiving. Primarily because RFC1122 specified it, but also because there are sufficiently many devices that do implement this at their core - e.g.: router operating systems in suport of OSPF etc (most have been updated to also support IGMP. Section 7.2: (re-)introduced permanent joining of all-groups as a SHOULD requirement. Section 9.4 and header: Defining this doc as update to RFC1122 to override the 36 year long recommendation of only implementing IP multicast without IGMP. New sections 10.7 to explain RFC1122 and Level 2L New section 10.8 to explain/justify recommendation to SHOULD support IP multicast on all hosts. Rewrote Section 10.10 for permanently join all-nodes group.

draft-ietf-pim-rfc1112bis-03 Changed document text to make the term "ASM" apply only to the IP service interface (extensions) specified by the document (and shown and explained in existing text), instead of the whole host extensions specified in this document (as it was written up to up to -02). This is the only correct semantic, given how all the host exensions specified in this document are shared by SSM, only the IP service interface is changed/amended by SSM. Subdivided section 2 (INTRODUCTION) into sections 2.1 (Summary), which contains new text from this spec, and 2.2 (Overview), which is unchanged RFC1112 text. Newly written section 2.1 to summarize the key content of this document. This was so far only explained in the much later changes from rfc1112 section. Includes IPv4/IPv6 applicability, ASM/SSM naming and maintaining most of RFC1112 text as a goal. Introduced text to define and explain link local IPv4 host group addresses 224.0.0.0 - 224.0.0.255. This was triggered by trying to fix the rfc1112 text sections that Brian Haberman was concerned about, which did cover behavior for 224.0.0.1. As it turns out, the behavior for 224.0.0.1 was quickly adopted by other protocols getting 224.0.0.0/24 addresses and there has been no functional specification to explain the non-forwarding behavior for these link-local addresses. Instead, only IANA allocation guideline RFCs where introducing them. This is now rectified with new explanatory text in this spec. and a new MAY requirement to permit non-use of IGMP for those groups. See . Changed references to IGMPv3 and MLDv2 to the -bis drafts currently in RFC-editor queue. Also triggered by Brian Haberman mentioning them. Improved wording in "(Normative) Status Change" section 9. 5.1 Removed "Update to rfc791" as an open issue and instead claimed it as fact in section 9.3. Added discussion about this point to the discussion appendix that is to be removed by RFC-editor. 5.1 Also added subsection to declare that this document replaces RFC1112 in STD5. Enhanced/New text in section 10., "changes from RFC1112" Especially explaining the changes in the normative section explained above and below, triggered by Brian's review. Applying changes proposed by Brian Haberman during WGLC. 7.1 Changed meaning of IP from "IPv4" to "IPv4 and IPv6", accordingly updated all text. Makes a lot of sense given the goal of showing how most of the IP multicast host stack operates the same for IPv4 and IPv6. 7.2 Re-added requirement for routers not to forward link-local multicast 7.3 adding MAY requirement to allow non-signaling of Link-Local scope IPv4 multicast and IPv6 all-nodes group, and explanations how this is better than the prior definitions from rfc1112. Also includes new (length) Appendix A.3 to justify this for IPv4. 7.4 text nits (thanks, Brian).

draft-ietf-pim-rfc1112bis-02 Removed unused references, fefresh - waiting for more reviews. Added IANA section for updates from RFC1112 to RFC1112bis. Added references to RFC5771 and RFC6034 because they actually are the references for the IANA 224.0.0.0/4 registrations, which seems a bit undocumented given how RFC1112 did introduce the definition (before IANA).

draft-ietf-pim-rfc1112bis-01 Fix up reference for IGMPv3. Refined candidate open issues. Removed author discussion.

draft-eckert-pim-rfc1112bis-02 Changed core references from numbered style to name style . Changed copyright clause to pre5378Trust200902, which is the same as used for RFC8200 due to the presence of text with similar early status. To resolve Dino's concerns at IETF116 with -01: Added hopefully extensive explanation wrt. to how to treat IGMPv1 based on Dino's feedback from IETF117: This document does not ask for any removal of IGMPv1 in any IETF specs which include it for backward compatibility reasons, it only effectively causes it to become historic once RFC1112 would be declared historic. To resolve Alvaros concerns at IETF1116 with -01: Added normative language (MUST/SHOULD). Seems as if this is quite easy given how "must" was written appropriately in the original text. The logic of applying MUST/MUST-NOT was based on understanding by the author how none of the MUST would actually put existing working implementations out of compliance. Added explicit text to move rfc1112 to historic status. Moved explanation of changes from rfc1112 from appendix to main text as this seem to the common practice for document updates. Added claim for this document to be an update to rfc791. See open issues section though.

draft-ietf-pim-rfc1112bis-00 Just changed title, added github pointer.

draft-eckert-pim-rfc1112bis-01 Changed all use of IPv4 back to IP. Seems standard in IETF specs. Only IPv6 has in IETF specs the distinction of including the version. Changed Steve Deerings address to a pseudo-email address at IETF. See prior section. Converted document into kramdownrfc2629 format for easier editing. Claims that rfc2119 language is not desired/used (to maintain maximum original text without changes). Rewrote section for updates to rfc1112 to hopefully better motivate/explain the reason for this document and detail what its changes are.

draft-eckert-pim-rfc1112bis-00 Initial version based on text version, edited.