PIM                                                        S. E. DeeringInternet-Draft                                                   RetiredObsoletes: 1112 (if approved)                             T. Eckert, Ed.Updates: 791, 1122 (if approved)              Futurewei Technologies USAIntended status: Standards Track                            19 June 2025Expires: 21 December 2025Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM)                               IP service                      draft-ietf-pim-rfc1112bis-04Abstract   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 RFC1112 for everything but its specification   of the IGMP version 1 protocol.Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions of BCP 78 and BCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is at https://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on 21 December 2025.Copyright Notice   Copyright (c) 2025 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents (https://trustee.ietf.org/   license-info) in effect on the date of publication of this document.Deering & Eckert        Expires 21 December 2025                [Page 1]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.  Code Components   extracted from this document must include Revised BSD License text as   described in Section 4.e of the Trust Legal Provisions and are   provided without warranty as described in the Revised BSD License.   This document may contain material from IETF Documents or IETF   Contributions published or made publicly available before November   10, 2008.  The person(s) controlling the copyright in some of this   material may not have granted the IETF Trust the right to allow   modifications of such material outside the IETF Standards Process.   Without obtaining an adequate license from the person(s) controlling   the copyright in such materials, this document may not be modified   outside the IETF Standards Process, and derivative works of it may   not be created outside the IETF Standards Process, except to format   it for publication as an RFC or to translate it into languages other   than English.Table of Contents   1.  STATUS OF THIS MEMO . . . . . . . . . . . . . . . . . . . . .   4     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4   2.  INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .   4     2.1.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   4     2.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5   3.  LEVELS OF CONFORMANCE . . . . . . . . . . . . . . . . . . . .   6     3.1.  Level 0: no support for IP multicasting.  . . . . . . . .   6     3.2.  Level 1: support for sending but not receiving multicast IP           datagrams.  . . . . . . . . . . . . . . . . . . . . . . .   7     3.3.  Level 2: full support for IP multicasting.  . . . . . . .   7     3.4.  Level 2L: support for only local IP multicasting. . . . .   7   4.  HOST GROUP ADDRESSES  . . . . . . . . . . . . . . . . . . . .   8   5.  MODEL OF A HOST IP IMPLEMENTATION . . . . . . . . . . . . . .   9   6.  SENDING MULTICAST IP DATAGRAMS  . . . . . . . . . . . . . . .  10     6.1.  Extensions to the IP Service Interface  . . . . . . . . .  10     6.2.  Extensions to the IP Module . . . . . . . . . . . . . . .  10     6.3.  Extensions to the Local Network Service Interface . . . .  11     6.4.  Extensions to an Ethernet Local Network Module  . . . . .  11     6.5.  Extensions to Local Network Modules other than           Ethernet  . . . . . . . . . . . . . . . . . . . . . . . .  12   7.  RECEIVING MULTICAST IP DATAGRAMS  . . . . . . . . . . . . . .  12     7.1.  Extensions to the IP Service Interface  . . . . . . . . .  12     7.2.  Extensions to the IP Module . . . . . . . . . . . . . . .  13     7.3.  Extensions to the Local Network Service Interface . . . .  14     7.4.  Extensions to an Ethernet Local Network Module  . . . . .  15     7.5.  Extensions to Local Network Modules other than           Ethernet  . . . . . . . . . . . . . . . . . . . . . . . .  15   8.  ROUTING MULTICAST IP DATAGRAMS  . . . . . . . . . . . . . . .  16Deering & Eckert        Expires 21 December 2025                [Page 2]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   9.  Status changes  . . . . . . . . . . . . . . . . . . . . . . .  16     9.1.  Moving RFC1112 and IGMPv1 to historic status  . . . . . .  16     9.2.  Backward compatibility with IGMPv1  . . . . . . . . . . .  16     9.3.  Update to RFC 791 . . . . . . . . . . . . . . . . . . . .  17     9.4.  Update to RFC 1122  . . . . . . . . . . . . . . . . . . .  17     9.5.  Update to STD 5 . . . . . . . . . . . . . . . . . . . . .  17   10. Changes from RFC1112  . . . . . . . . . . . . . . . . . . . .  17     10.1.  Normative language . . . . . . . . . . . . . . . . . . .  17     10.2.  References to IGMPv1 . . . . . . . . . . . . . . . . . .  17     10.3.  New summary  . . . . . . . . . . . . . . . . . . . . . .  18     10.4.  Any-Source Multicast (ASM) . . . . . . . . . . . . . . .  18     10.5.  SSM  . . . . . . . . . . . . . . . . . . . . . . . . . .  18     10.6.  Applicability to both IPv4 and IPv6  . . . . . . . . . .  18     10.7.  RFC1122 and Level 2L . . . . . . . . . . . . . . . . . .  19     10.8.  IP multicast support . . . . . . . . . . . . . . . . . .  19     10.9.  IPv4 Local Network Control Block . . . . . . . . . . . .  20     10.10. Permanent membership for Link-Local all-hosts groups . .  20     10.11. IGMP/MLD messages for Link-Local IPv4 host group             addresses . . . . . . . . . . . . . . . . . . . . . . .  21     10.12. Standard for IP multicasting in controlled networks  . .  21   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22     11.1.  Protocol Numbers registry  . . . . . . . . . . . . . . .  22     11.2.  Internet Group Management Protocol (IGMP) Type Numbers            Registry . . . . . . . . . . . . . . . . . . . . . . . .  22     11.3.  Multicast 48-bit MAC Addresses registry  . . . . . . . .  23     11.4.  IPv4 Address range registries  . . . . . . . . . . . . .  23     11.5.  IPv4 Multicast Address Space registry  . . . . . . . . .  23     11.6.  IP Flow Information Export registry  . . . . . . . . . .  23   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23     12.1.  Normative References . . . . . . . . . . . . . . . . . .  23     12.2.  Informative References . . . . . . . . . . . . . . . . .  25   Appendix A.  HOST GROUP ADDRESS ISSUES  . . . . . . . . . . . . .  27     A.1.  Group Address Binding . . . . . . . . . . . . . . . . . .  27     A.2.  Allocation of Transient Host Group Addresses  . . . . . .  28     A.3.  Link-local IP multicast and IGMP/MLD  . . . . . . . . . .  28   Appendix B.  Discussion and Explanations (TO BE REMOVED)  . . . .  30     B.1.  RFC-Editor notes  . . . . . . . . . . . . . . . . . . . .  30     B.2.  Goals and evolution of this document  . . . . . . . . . .  30     B.3.  Update to RFC791  . . . . . . . . . . . . . . . . . . . .  31     B.4.  Changelog . . . . . . . . . . . . . . . . . . . . . . . .  32       B.4.1.  draft-ietf-pim-rfc1112bis-03  . . . . . . . . . . . .  32       B.4.2.  draft-ietf-pim-rfc1112bis-03  . . . . . . . . . . . .  33       B.4.3.  draft-ietf-pim-rfc1112bis-02  . . . . . . . . . . . .  34       B.4.4.  draft-ietf-pim-rfc1112bis-01  . . . . . . . . . . . .  34       B.4.5.  draft-eckert-pim-rfc1112bis-02  . . . . . . . . . . .  34       B.4.6.  draft-ietf-pim-rfc1112bis-00  . . . . . . . . . . . .  35       B.4.7.  draft-eckert-pim-rfc1112bis-01  . . . . . . . . . . .  35       B.4.8.  draft-eckert-pim-rfc1112bis-00  . . . . . . . . . . .  35Deering & Eckert        Expires 21 December 2025                [Page 3]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  351.  STATUS OF THIS MEMO   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 RFC1112 for everything except for its   specification of the IGMP version 1 protocol.1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.2.  INTRODUCTION2.1.  Summary   This memo specifies the extensions required of a host implementation   of the Internet Protocol (IP) to support IP multicast.  It replaces   [RFC791] for everything except for the specification of the protocol   IGMP version 1 in Appendix I. of RFC1112.  This document declares   RFC1112 including IGMP version 1 historic.   RFC1112 specified IP multicast for version 4 of the IP protocol   (IPv4, [RFC791]), and refers to that version as IP.  This document   applies both to version 4 of the IP protocol and version 6 of the IP   protocol (IPv6, [RFC8200]).  The term IP is used in this document to   refer to both versions.  Where specifications in support of IP   multicast for version 6 of the IP protocol where 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 versions of IP.Deering & Eckert        Expires 21 December 2025                [Page 4]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   "Source Specific Multicast", (SSM, [SSM]) introduced a complementary   extension to the IP service from the one specified here.  It is   relying on components specified here, such as {#ethernet}, and   extending or superseding others.  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 RFC1112.   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 options: this specification for ASM plus [SSM]).  When   the term IP multicast is used to refer to the IP multicast service   without further qualification, then ASM is to be implied.   This specification aims to maintain all the original text of RFC1112   where technically appropriate.  This incurs the use of some historic   language, such as "(internet) gateway" to refer to IP routers, and   capitalization of chapter headings.   See Section 9 and Section 10 for a detailed list of changes from   RFC1112.2.2.  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.Deering & Eckert        Expires 21 December 2025                [Page 5]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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 will be 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.3.  LEVELS OF CONFORMANCE   There are three levels of conformance to this specification.  They   apply indepently 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 can not conform   to Level 2 for it are RECOMMENDED to conform to Level 2L.3.1.  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 a class D IP 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 section 4 of this memo, IPv6 addresses for IP   multicasting are described in [RFC4291] and [RFC7371].Deering & Eckert        Expires 21 December 2025                [Page 6]Internet-Draft    IP Multicast Host Extensions and ASM         June 20253.2.  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.3.3.  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 ([RFC4861], as used on most link   types, see [RFC8504], 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 [IGMPv3] and [MLDv2] or lightweight versions of   either protocol [IGMPv3lite].   All of the following sections of this memo are applicable to level 2   implementations.3.4.  Level 2L: support for only 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 to their local   network.   Level 2L hosts SHOULD only join/leave Link-Local host groups (see   Section 4) and send IP datagrams to Link-Local host groups.   Level 2L is only applicable to IPv4.Deering & Eckert        Expires 21 December 2025                [Page 7]Internet-Draft    IP Multicast Host Extensions and ASM         June 20254.  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 addresses 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).  It is   called the all-hosts group.  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.   The addresses of well-known, permanent IPv4 multicast groups are to   be published in "Assigned Numbers", see [RFC3232], currently through   the IANA "IPv4 Multicast Address Space Registry".  [RFC5771] and   [RFC6034] refine more detailed allocation and uses of different sub-   blocks of 224.0.0.0/4.   Allocation guidelines for Link-Local IPv6 multicast group addresses   are specified in [RFC5771].  The IPv6 Link-Local all-hosts group   address is FF02::1.  IPv6 Host groups are identified by IPv6   addresses as defined in [RFC4291] section 2.7 and updated by   [RFC7346], [RFC7371].  The addresses of other groups are currently   published via the IANA "IPv6 Multicast Address Space Registry".   IP addresses as specified in [SSM] are not used for ASM IP multicast   and are not considered IP host groups by [SSM].  They are instead   only the destination address part G of Source Specific Multicast   (SSM) IP multicast (S,G) channels.   Appendix I contains some background discussion of several issues   related to host group addresses.Deering & Eckert        Expires 21 December 2025                [Page 8]Internet-Draft    IP Multicast Host Extensions and ASM         June 20255.  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 Figure 1.  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.      |                                                          |      |              Upper-Layer Protocol Modules                |      |__________________________________________________________|   --------------------- IP Service Interface -----------------------       __________________________________________________________      |                            |              |              |      |                            | IPv4:        | IPv6:        |      |                            | ICMP+IGMP    | ICMPv6+MLD   |      |    IP [IPv4 and/or IPv6]   |______________|______________|      |           Module(s)                                      |      |                                                          |      |__________________________________________________________|   ---------------- Local Network Service Interface -----------------       __________________________________________________________      |                            |                             |      |           Local            | IP-to-local address mapping |      |          Network           |         (e.g., ARP/ND)      |      |          Modules           |_____________________________|      |      (e.g., Ethernet)                                    |      |                                                          |         Figure 1: multicast extensions to a host IP implementation   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.Deering & Eckert        Expires 21 December 2025                [Page 9]Internet-Draft    IP Multicast Host Extensions and ASM         June 20256.  SENDING MULTICAST IP DATAGRAMS6.1.  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 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 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   [RFC3493], section 5.2.6.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:Deering & Eckert        Expires 21 December 2025               [Page 10]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025       if IP-destination is on the same local network,          send datagram locally to IP-destination       else          send datagram locally to GatewayTo( IP-destination )   To allow multicast transmissions, the routing logic MUST be changed   to:       if IP-destination is on the same local network       or IP-destination is a host group,          send datagram locally to IP-destination       else          send datagram locally to GatewayTo( IP-destination )   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 implementations only.)   The IP source address of the outgoing datagram MUST be one of the   individual addresses corresponding to the outgoing interface.   A host group address or IP address from an SSM range MUST never 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.6.3.  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.6.4.  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.Deering & Eckert        Expires 21 December 2025               [Page 11]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   Mapping of IPv6 host group addresses to Ethernet is defined in   [RFC2464] and [RFC6085].   The address mappings for IP addresses do apply not only to IP host   group addresses, but also to destination IP addresses used for SSM.6.5.  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.7.  RECEIVING MULTICAST IP DATAGRAMS7.1.  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 IP header, 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:       JoinHostGroup  ( group-address, interface )       LeaveHostGroup ( group-address, interface )Deering & Eckert        Expires 21 December 2025               [Page 12]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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   [RFC3493], section 5.2.  [RFC3678] specifies socket options for these   functions for ASM and also includes socket options in support of SSM.   Note that these are UDP socket extensions but not IP socket   extensions due to the absence of widely adopted/required IP level   socket APIs.7.2.  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.)Deering & Eckert        Expires 21 December 2025               [Page 13]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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 host group 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 does also apply for the IPv6 Link-Local all-hosts   group FF02::1, but not to other Link-Local IPv6 host groups.  See   {#level2l} and Appendix A.3.   Level 2/2L hosts and gateways SHOULD permanently join to the Link-   Local all-hosts group for the version of IP they implement.  See   Section 10.10.7.3.  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:       JoinLocalGroup  ( group-address )       LeaveLocalGroup ( group-address )Deering & Eckert        Expires 21 December 2025               [Page 14]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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.7.4.  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 host group   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.7.5.  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 localDeering & Eckert        Expires 21 December 2025               [Page 15]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   network unicasts, so no change to the local network module should be   necessary.8.  ROUTING MULTICAST IP DATAGRAMS   IPv4 datagrams with a Link-Local destination address MUST never be   forwarded to a different link by multicast routers, regardless of   their time-to-live.  See Section 10.9 for explanations.   The equivalent requirement are specified for IPv6 in [RFC4291],   section 2.5.6.   Rules for forwarding of non Link-Local IP multicast packets are   outside the scope of this document.9.  Status changes9.1.  Moving RFC1112 and IGMPv1 to historic status   This document moves RFC1112 to historic status which also moves the   IGMP version 1 protocol as specified in Appendix 1 of RFC1112 to   historic status, as it is not included into this document anymore.   All other aspects of RFC1112 beside IGMPv1 are kept and updated by   this document and maintain their current Internet Standard   designation from RFC1112 through the normative status of this   document.9.2.  Backward compatibility with IGMPv1   Current or future versions of IGMP or other protocols/mechanisms   including but not necessary limited to [IGMPv2], [IGMPv3] or   [IGMPv3lite] do or may include backward compatibility with IGMPv1,   such as in [IGMPsnooping], which requires them to refer to the   RFC1112 specification of IGMPv1.   This document does not ask for any change to any specifications or   implementations that includes any form of support for IGMPv1 for   backward compatibility reasons as long as it also includes   compatibility with a newer version of IGMP starting with [IGMPv2].   Any new or updated specification that wants to maintain such backward   compatibility with IGMPv1 need to continue to reference RFC1112 as   the specification of IGMPv1.   Any future reference for new or updated work to any other definition   from RFC1112 (host extensions for IP multicast and/or Any Source   Multicast service) need to refer to this document instead of RFC1112.Deering & Eckert        Expires 21 December 2025               [Page 16]Internet-Draft    IP Multicast Host Extensions and ASM         June 20259.3.  Update to RFC 791   This document is an update to [RFC791] 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 [RFC791].   Instead, IP multicast is carving out parts of the IP address space to   trigger completely new forwarding for completely new entities: host   groups in ASM, channels in SSM).  See Appendix B.3 for further   discussions.9.4.  Update to RFC 1122   This document updates [RFC1122] section 3.2.3 by making support for   Level 2 conformance and hence support for IGMP recommended instead of   optional as required by [RFC1122].  See Section 3.9.5.  Update to STD 5   This document replaces RFC1112 in [STD5] which defines IPv4   ([RFC791]) including its core extensions.   Note: As there is no precedent for STD86 (IPv6) to include any   specifications for extension of IPv6, this document is not asked to   become part of STD86.10.  Changes from RFC1112   Beyond the status changes described in Section 9, this document   introduces the following changes over RFC1112.   All requirements changes are intended to make this specification   aligned with long-term, most widely implemented, deployed and   standardised 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 RFC1112 (without IGMPv1) was to be implemented   today.10.1.  Normative language   This document introduces the use of normative language through   capitalization.  RFC1112 preceded [RFC2119] and hence did not include   this language.10.2.  References to IGMPv1   References to IGMPv1 in RFC1112 are replaced with references to   [IGMPv3] in this text.Deering & Eckert        Expires 21 December 2025               [Page 17]Internet-Draft    IP Multicast Host Extensions and ASM         June 202510.3.  New summary   The new Section 2.1 summarizes the scope of this document and the   core new changes over RFC1112.10.4.  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 RFC1112) as explained in Section 2.1.10.5.  SSM   Section 2.1 explains the relationship of this document to SSM   ([SSM]).   Section 4 adds the specification that the term host groups specified   in this document does not apply to destination addresses used for   SSM.   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.10.6.  Applicability to both IPv4 and IPv6   This document is written to apply to both IPv4 and IPv6 by adding   detail for IPv6 where RFC1112 only covered IPv4.  This includes   addressing and protocols in support of the service - Multicast   Listener Discovery [MLDv2] for IPv6 versus IGMP for IPv4.   IPv6 documents such as [RFC1883] and all its updates (e.g.:   [RFC8200]) are defining the necessary wire encoding aspects of IP   multicast in the assumption of the service of RFC1112 for IPv6, but   without being able to refer to RFC1112, 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.Deering & Eckert        Expires 21 December 2025               [Page 18]Internet-Draft    IP Multicast Host Extensions and ASM         June 202510.7.  RFC1122 and Level 2L   [RFC1122] did not require support for IPv4 multicasting ("there is at   this time no requirement that all IP implementations support IP   multicasting").  Instead, [RFC1122] recommends support for IPv4   multicast (according to RFC1112), but support for IGMP to be   optional, specifying that sending/receiving IPv4 multicast from/to   the local networks works without IGMP and that that is the   recommended form to support IPv4 multicasting.  See also   Appendix A.3.   With [RFC1122] 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.  Introduction of this text does also not change long-term   deployment practices but only formalizes them.   Level 2L is specified in this document as not applying to IPv6   multicast because MLD (unlike IGMP) choose to mandate the sending of   MLD messages even for Link-Local host groups.  This was done   specifically to ensure that MLD snooping switches could constrain   also Link-Local host groups, considering also the potential for local   networks with IPv6 to potentially have many more hosts on them than   with IPv4 because of the larger IPv6 addressing space.  With no   widespread industry use of MLD without messages for Link-Local host   groups, this benefit of mandating use of MLD for Link-Local groups   would be invalidated through the introduction of a Level 2L option.10.8.  IP multicast support   With [IGMPv3] 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 [RFC1122]   from optional to recommended.  See Section 9.4).   Unlike [RFC1122], [RFC8504] does not directly raise a requirement   against support for MLD for every node supporting IPv6.  Instead, it   explains the dependencies against IPv6 multicast and hence MLD for   core IPv6 protocols used on most link types (ND, SLAAC).   With [MLDv2] now being Internet standard, and over two decades of   experience with IPv6 multicast availability and use on almost all   IPv6 implementations, this documents now also recommends support for   Level 2 conformance for IPv6 multicast, see Section 3.  Note that   this is not declared as an update to [RFC8504], because it is outside   that BCP documents scope.Deering & Eckert        Expires 21 December 2025               [Page 19]Internet-Draft    IP Multicast Host Extensions and ASM         June 202510.9.  IPv4 Local Network Control Block   RFC1112 defines the requirement for IPv4 datagrams to the all-hosts   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.  [RFC2365] and   [RFC5771], section 4 are the BCPs covering this requirement.   This document formalizes this BCP behavior as a standard requirement   in Section 8, superseding and encompassing the more specific   requirement for just 224.0.0.1 from RFC1112, and mirroring the same   standardized behavior for IPv6 Link-Local addresses.  Because this is   actually a requirement against IP multicast routers and not hosts,   this is now also accordingly described in a separate section.   This requirement does not incur changes over how IP multicast is   implemented or deployed.10.10.  Permanent membership for Link-Local all-hosts groups   RFC1112, section 7.2 introduced the requirements for hosts to   permanently join 224.0.0.1.  Its explains this requirement to be in   support of IGMP (version 1).   [IGMPv2], section 6. and [IGMPv3], section 5. inherits this   requirement, and [MLDv1], section 6. and [MLDv2] section 6. also   define the same requirement for the IPv6 Link-Local all-hosts address   FF02::1.   RFC1112 explains this choice by being "(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-hosts group.  Like any other group, reception of packets could   enabled through the JoinHostGroup()/LeaveHostGroup(), as described in   Section 7.1.  However, all known host implementations that support IP   multicast since RFC1112 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 to the Link-Local all-hosts group.  This is for   example common in support of ICMP/ICMPv6 echo: "ping 224.0.0.1" toDeering & Eckert        Expires 21 December 2025               [Page 20]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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 to update this specification.   Note that [IGMPv3lite] omits this requirement.10.11.  IGMP/MLD messages for Link-Local IPv4 host group addresses   RFC1112, Appendix I.  (IGMPv1), [IGMPv2], [IGMPv3], [MLDv1], [MLDv2]   require hosts to not send IGMP/MLD messages for the all-hosts group.   This would be in conflict of the general rules of RFC1112 (outside of   its IGMPv1 specific definitions) and equally this specification if it   was not enhanced.  This specification therefore contains new text   that makes it compatible with existing IGMP/MLD specification, and   with long tern established and deployed implementation practices.   New text in Appendix A.3 explains how after RFC1112, it became a   common place 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 [IGMPsnooping] mandates to explicit support it IGMP snooping   implementations.   Referring to that explanation, a new MAY requirement in Section 7.2   allowing (but not recommending) this behavior makes existing   specifications and deployments compatible with this documents   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.10.12.  Standard for IP multicasting in controlled networks   This document removes the claim in the abstract of RFC1112, that   these host extensions are "... the recommended standard for IP   multicasting in the Internet."Deering & Eckert        Expires 21 December 2025               [Page 21]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   The reason for this is that [RFC8815] deprecated the ASM service   across the Internet because there is no Internet Standard solution   for protocols to support interdomain ASM except for [RFC3956], which   is only applicable to IPv6, and even that solution does not resolve   the challenges to source access control in interdomain deployments.   In 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", [SSM], which inherits all aspects of ASM   specified in this document, especially the sending (Section 6,   Section 6.2) of IP multicast packets as well as the mapping to   ethernet (Section 6.4).  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.11.  IANA Considerations11.1.  Protocol Numbers registry   IANA is asked to replace the Reference field for the IGMP protocol in   the Protocol Numbers registry (https://www.iana.org/assignments/   protocol-numbers/protocol-numbers.xhtml) from RFC1112 to [THIS-RFC].   Explanation: This protocol number is used by all versions of IGMP,   including [IGMPv2] and [IGMPv3] and is unaffected by making IGMP   version 1 historic.11.2.  Internet Group Management Protocol (IGMP) Type Numbers Registry   IANA is asked to replace the Reference to RFC1112 for the 0x11 /   "IGMP Membership Query" entry in the "Internet Group Management   Protocol (IGMP) Type Numbers Registry"   (https://www.iana.org/assignments/igmp-type-numbers/igmp-type-   numbers.xhtml) with "RFC1112, [RFC2236], [RFC3376]".   Explanation: This type code messages where introduced by RFC1112 but   modified versions thereof where also introduced by [RFC2236] and   [RFC3376], so that it is clearer if all three RFCs are indicated.   All other references to RFC1112 in this registry are specifically   referring to that RFC in it's role of defining IGMP version 1 and   thus need to continue to refer to RFC1112 and not [THIS-RFC.Deering & Eckert        Expires 21 December 2025               [Page 22]Internet-Draft    IP Multicast Host Extensions and ASM         June 202511.3.  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"   (https://www.iana.org/assignments/ethernet-numbers) from RFC1112 to   [THIS-RFC].11.4.  IPv4 Address range registries   IANA is asked to replace the Reference field for the 240.0.0.0/4   entry in the "IANA IPv4 Special-Purpose Address Registry"   (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-   ipv4-special-registry.xhtml) from RFC1112 to [THIS-RFC].  The   Section 4 text stays unchanged.   IANA is asked to replace the Reference to RFC1112 in the "IANA IPv4   Address Space Registry" (https://www.iana.org/assignments/ipv4-   address-space/ipv4-address-space.xhtml) with [THIS-RFC].11.5.  IPv4 Multicast Address Space registry   IANA is asked to replace the three references to RFC1112 in the "IPv4   Multicast Address Space Registry" (https://www.iana.org/assignments/   multicast-addresses/multicast-addresses.xhtml) with [THIS-RFC].11.6.  IP Flow Information Export registry   IANA is asked to replace the two references to RFC1112 in the "IPFIX   Information Elements" registry   (https://www.iana.org/assignments/ipfix/ipfix.xhtml) with [THIS-RFC].12.  References12.1.  Normative References   [IGMPv2]   Fenner, W., "Internet Group Management Protocol, Version              2", RFC 2236, DOI 10.17487/RFC2236, November 1997,              <https://www.rfc-editor.org/rfc/rfc2236>.   [IGMPv3]   Haberman, B., Ed., "Internet Group Management Protocol,              Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March              2025, <https://www.rfc-editor.org/rfc/rfc9776>.   [MLDv2]    Haberman, B., Ed., "Multicast Listener Discovery Version 2              (MLDv2) for IPv6", STD 101, RFC 9777,              DOI 10.17487/RFC9777, March 2025,              <https://www.rfc-editor.org/rfc/rfc9777>.Deering & Eckert        Expires 21 December 2025               [Page 23]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -              Communication Layers", STD 3, RFC 1122,              DOI 10.17487/RFC1122, October 1989,              <https://www.rfc-editor.org/rfc/rfc1122>.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/rfc/rfc2119>.   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,              <https://www.rfc-editor.org/rfc/rfc2464>.   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing              Architecture", RFC 4291, DOI 10.17487/RFC4291, February              2006, <https://www.rfc-editor.org/rfc/rfc4291>.   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,              DOI 10.17487/RFC0791, September 1981,              <https://www.rfc-editor.org/rfc/rfc791>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6              (IPv6) Specification", STD 86, RFC 8200,              DOI 10.17487/RFC8200, July 2017,              <https://www.rfc-editor.org/rfc/rfc8200>.   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,              January 2019, <https://www.rfc-editor.org/rfc/rfc8504>.   [SSM]      Holbrook, H. and B. Cain, "Source-Specific Multicast for              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,              <https://www.rfc-editor.org/rfc/rfc4607>.   [STD5]     Internet Standard 5,              <https://www.rfc-editor.org/info/std5>.              At the time of writing, this STD comprises the following:              Postel, J., "Internet Protocol", STD 5, RFC 791,              DOI 10.17487/RFC0791, September 1981,              <https://www.rfc-editor.org/info/rfc791>.Deering & Eckert        Expires 21 December 2025               [Page 24]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025              Postel, J., "Internet Control Message Protocol", STD 5,              RFC 792, DOI 10.17487/RFC0792, September 1981,              <https://www.rfc-editor.org/info/rfc792>.              Mogul, J., "Broadcasting Internet Datagrams", STD 5,              RFC 919, DOI 10.17487/RFC0919, October 1984,              <https://www.rfc-editor.org/info/rfc919>.              Mogul, J., "Broadcasting Internet datagrams in the              presence of subnets", STD 5, RFC 922,              DOI 10.17487/RFC0922, October 1984,              <https://www.rfc-editor.org/info/rfc922>.              Mogul, J. and J. Postel, "Internet Standard Subnetting              Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August              1985, <https://www.rfc-editor.org/info/rfc950>.              Deering, S., "Host extensions for IP multicasting", STD 5,              RFC 1112, DOI 10.17487/RFC1112, August 1989,              <https://www.rfc-editor.org/info/rfc1112>.12.2.  Informative References   [IGMPsnooping]              Christensen, M., Kimball, K., and F. Solensky,              "Considerations for Internet Group Management Protocol              (IGMP) and Multicast Listener Discovery (MLD) Snooping              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,              <https://www.rfc-editor.org/rfc/rfc4541>.   [IGMPv3lite]              Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet              Group Management Protocol Version 3 (IGMPv3) and Multicast              Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,              DOI 10.17487/RFC5790, February 2010,              <https://www.rfc-editor.org/rfc/rfc5790>.   [MLDv1]    Deering, S., Fenner, W., and B. Haberman, "Multicast              Listener Discovery (MLD) for IPv6", RFC 2710,              DOI 10.17487/RFC2710, October 1999,              <https://www.rfc-editor.org/rfc/rfc2710>.   [RFC1045]  Cheriton, D., "VMTP: Versatile Message Transaction              Protocol: Protocol specification", RFC 1045,              DOI 10.17487/RFC1045, February 1988,              <https://www.rfc-editor.org/rfc/rfc1045>.Deering & Eckert        Expires 21 December 2025               [Page 25]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   [RFC1723]  Malkin, G., "RIP Version 2 - Carrying Additional              Information", RFC 1723, DOI 10.17487/RFC1723, November              1994, <https://www.rfc-editor.org/rfc/rfc1723>.   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6              (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,              December 1995, <https://www.rfc-editor.org/rfc/rfc1883>.   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,              DOI 10.17487/RFC2328, April 1998,              <https://www.rfc-editor.org/rfc/rfc2328>.   [RFC2365]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,              RFC 2365, DOI 10.17487/RFC2365, July 1998,              <https://www.rfc-editor.org/rfc/rfc2365>.   [RFC3232]  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced              by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,              January 2002, <https://www.rfc-editor.org/rfc/rfc3232>.   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.              Stevens, "Basic Socket Interface Extensions for IPv6",              RFC 3493, DOI 10.17487/RFC3493, February 2003,              <https://www.rfc-editor.org/rfc/rfc3493>.   [RFC3678]  Thaler, D., Fenner, B., and B. Quinn, "Socket Interface              Extensions for Multicast Source Filters", RFC 3678,              DOI 10.17487/RFC3678, January 2004,              <https://www.rfc-editor.org/rfc/rfc3678>.   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous              Point (RP) Address in an IPv6 Multicast Address",              RFC 3956, DOI 10.17487/RFC3956, November 2004,              <https://www.rfc-editor.org/rfc/rfc3956>.   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,              DOI 10.17487/RFC4861, September 2007,              <https://www.rfc-editor.org/rfc/rfc4861>.   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,              DOI 10.17487/RFC5771, March 2010,              <https://www.rfc-editor.org/rfc/rfc5771>.   [RFC6034]  Thaler, D., "Unicast-Prefix-Based IPv4 Multicast              Addresses", RFC 6034, DOI 10.17487/RFC6034, October 2010,              <https://www.rfc-editor.org/rfc/rfc6034>.Deering & Eckert        Expires 21 December 2025               [Page 26]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   [RFC6085]  Gundavelli, S., Townsley, M., Troan, O., and W. Dec,              "Address Mapping of IPv6 Multicast Packets on Ethernet",              RFC 6085, DOI 10.17487/RFC6085, January 2011,              <https://www.rfc-editor.org/rfc/rfc6085>.   [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,              DOI 10.17487/RFC7346, August 2014,              <https://www.rfc-editor.org/rfc/rfc7346>.   [RFC7371]  Boucadair, M. and S. Venaas, "Updates to the IPv6              Multicast Addressing Architecture", RFC 7371,              DOI 10.17487/RFC7371, September 2014,              <https://www.rfc-editor.org/rfc/rfc7371>.   [RFC8815]  Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert,              "Deprecating Any-Source Multicast (ASM) for Interdomain              Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815,              August 2020, <https://www.rfc-editor.org/rfc/rfc8815>.Appendix A.  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.A.1.  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.Deering & Eckert        Expires 21 December 2025               [Page 27]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025A.2.  Allocation of Transient Host Group Addresses   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 [RFC1045]) 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.A.3.  Link-local IP multicast and IGMP/MLD   On networks, where IP multicast packets are broadcast, such as (non-   switched) ethernet, IP multicast packets will reach all level 2 IP   multicast receivers without the need to use IGMP or MLD.  This   signaling is only necessary for IP multicast receivers when the   sender is in a different LAN so that IP multicast routers can forward   the IP multicast traffic from the sender network to the receiver   network.   IP multicast packet to a Link-Local IP multicast destination address   do therefore technically never need any IGMP or MLD signaling on such   (non-switched broadcast) networks, because they are never forwarded   between networks (Section 8).Deering & Eckert        Expires 21 December 2025               [Page 28]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   During the early years of IPv4 multicast, this understanding resulted   in the requirements of [RFC1122] and explained in Section 10.7 and   hence implementations for protocols that receive Link-Local IPv4   multicast packet without implementing IGMP.  Examples of such   protocols include RIPv2 ([RFC1723]) or OSPF ([RFC2328]) and several   other protocols, often running on IPv4 routers which had no IPv4   multicast routing implementation at the time and no IPv4 multicast   applications for which they needed to be IPv4 multicast receiver for   non Link-Local IPv4 multicast addresses.   When these implementations later received implementations of level 2   IPv4 multicast support, those implementations excluded Link-Local   host groups, so that those protocols would continue to run without   IGMP as they had in before.   Contributing to these implementation choices was also the fact that   IGMP in the versions specified so far does not allow to keep track of   ongoing receiver membership status in the absence of an IGMP router   side implementation, called an IGMP querier.  With the target (Link-   Local IPv4 multicast only) protocols being deployed in the absence of   any such IGMP querier, the use of IGMP could also serve arguably no   purpose except for compliance with RFC1112.   This situation changed towards the end of the 1990th with the   introduction of ethernet switches that snoop IGMP messages to   constrain forwarding of IPv4 multicast packets for a particular IPv4   multicast group to only those ports with hosts joined to the group.   This behavior was later documented in [IGMPsnooping] but was widely   deployed even earlier due to the co-existence of ports with the   different speeds 10Mbps, 100Mbps and 1Gbps, and the resulting need to   protect the slower speed ports from potentially large rates of IPv4   multicast traffic between faster hosts.   In result, IGMP snooping switches had to flood traffic to Link-Local   IPv4 multicast groups due to the common absence of IGMP support for   them, and this is accordingly also recommended by [IGMPsnooping].   Due to this long-term practice, this document is thus permitting this   non-use of IGMP for Link-Local host groups by introducing a MAY for   it in Section 7.2.   Note that IP multicast routers do not and can not typically report IP   multicast groups via IGMP or MLD, because they are not joined to them   as an IP multicast host, but simply need to receive them as an IP   multicast router to forward them.  Even when an IP multicast router   is joined to specific IP multicast group as an IP multicast host,   reporting them via IGMP may sound futile because as an IP multicast   router it would still need to receive the IP multicast traffic in theDeering & Eckert        Expires 21 December 2025               [Page 29]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   absence of such IGMP reporting, because it might need to forward it.   However, this logic does not apply to Link-Local groups, because they   are never forwarded and could thus be filtered by IGMP or MLD   snooping switches if those switches could trust routers to report   them correctly.  Which they can not do for IPv4 due to its history.   In recognition of this situation, [MLDv1] for IPv6 did emphasize the   need to report also Link-Local IPv6 group memberships to avoid these   issues.  Therefore this document also has no equivalent MAY statement   for IPv6.   Note that IGMP/MLD reporting for non Link-Local IP multicast groups   from an IP multicast router joining it as a host is also not just a   superficial specification requirement because of the assumption that   routers need to receive all non Link-Local IP multicast packets.   Switches that do support snooping of IP multicast routing protocols   such as PIM may also be able to determine which traffic needs to be   forwarded to an IP multicast router but those can may not include the   groups that the IP multicast router has only joined to only as a host   and is not reporting via IGMP/MLD.Appendix B.  Discussion and Explanations (TO BE REMOVED)   [RFC-editor: Please remove this Appendix after observing the   following section addressed to you]   Please refer to Section 10 for the non-process discussion of the   goals of this document.B.1.  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.B.2.  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).Deering & Eckert        Expires 21 December 2025               [Page 30]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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.B.3.  Update to RFC791   This version of the text proposes that this spec is declared to be an   update to RFC791.Deering & Eckert        Expires 21 December 2025               [Page 31]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   The argument made in Section 9.3 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.B.4.  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.B.4.1.  draft-ietf-pim-rfc1112bis-03   1.  Some textual nit improvements - introduced "all-hosts" 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.   2.  "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).   3.  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.   4.  Section 7.2: (re-)introduced permanent joining of all-groups as a       SHOULD requirement.   5.  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.Deering & Eckert        Expires 21 December 2025               [Page 32]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   6.  New sections 10.7 to explain RFC1122 and Level 2L   7.  New section 10.8 to explain/justify recommendation to SHOULD       support IP multicast on all hosts.   8.  Rewrote Section 10.10 for permanently join all-hosts group.B.4.2.  draft-ietf-pim-rfc1112bis-03   1.  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.   2.  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.   3.  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 Section 7.2.   1.  Changed references to IGMPv3 and MLDv2 to the -bis drafts       currently in RFC-editor queue.  Also triggered by Brian Haberman       mentioning them.   2.  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.Deering & Eckert        Expires 21 December 2025               [Page 33]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   5.1 Also added subsection to declare that this document replaces   RFC1112 in STD5.   1.  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.   1.  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-hosts 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).B.4.3.  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).B.4.4.  draft-ietf-pim-rfc1112bis-01   Fix up reference for IGMPv3.  Refined candidate open issues.  Removed   author discussion.B.4.5.  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.Deering & Eckert        Expires 21 December 2025               [Page 34]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   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.B.4.6.  draft-ietf-pim-rfc1112bis-00   Just changed title, added github pointer.B.4.7.  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.B.4.8.  draft-eckert-pim-rfc1112bis-00   Initial version based on RFC1112 text version, edited.Authors' AddressesDeering & Eckert        Expires 21 December 2025               [Page 35]Internet-Draft    IP Multicast Host Extensions and ASM         June 2025   Stephen E. Deering   Retired   Vancouver, British Columbia   Canada   Email: deering@noreply.ietf.org   Toerless Eckert (editor)   Futurewei Technologies USA   United States of America   Email: tte@cs.fau.deDeering & Eckert        Expires 21 December 2025               [Page 36]