RFC 1054
Host extensions for IP multicasting
RFC 1054: Host Extensions for IP Multicasting 🎀
- Network Working Group 🌸
- Author: S. Deering, Stanford University 💖
- Date: May 1988 🦋
- Status: proposed as a standard (see Section 1) 👑
- Obsoletes: RFC 988 🧚
1. STATUS OF THIS MEMO ✨
okay so this memo spells out the extensions a host IP implementation needs to support IP multicasting 🎀. It's proposed as a standard for IP multicasting on the Internet. It's a major revision of RFC-988, and the changes from RFC-988 are listed in an Appendix 💅. Distribution of this memo is unlimited 🌈.
2. INTRODUCTION 🦋
so IP multicasting is when you send an IP datagram to a "host group" 🫶. That's a set of zero or more hosts, all identified by one single IP destination address. A multicast datagram gets delivered to every member of its destination host group with the same "best-efforts" vibe as regular unicast IP datagrams. Translation: it is not guaranteed to arrive intact at all the members, or in the same order relative to other datagrams 😭.
Group membership is totally dynamic 💃. Hosts MAY join and leave groups at any time. There's no restriction on where members are or how many there are. A host MAY be a member of more than one group at a time, and it doesn't need to be a member of a group to send datagrams to it 🧚.
Groups can be permanent or transient 👑. A host group MAY be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It's the address that's permanent, not the membership. At any time a permanent group MAY have any number of members, even zero. Multicast IP addresses that aren't reserved for permanent groups are available for dynamic assignment to transient groups, which only exist as long as they have members 🍓.
Forwarding is handled by "multicast routers" 💅. These MAY be co-resident with internet gateways, or separate from them. A host sends an IP multicast datagram as a local network multicast, which reaches all the immediately-neighboring members of the destination host group. If the datagram's IP time-to-live is greater than 1, the multicast router(s) attached to the local network take responsibility for forwarding it toward all other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router finishes delivery by transmitting the datagram as a local multicast 🚀.
Here's the scope. This memo defines 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 they'll be specified in separate documents 🌸. This memo doesn't specify how local network multicasting is accomplished for all types of network. It does specify the REQUIRED service interface to an arbitrary local network, and it gives an Ethernet specification as an example. Specs for other network types will be the subject of future memos 🔮.
3. LEVELS OF CONFORMANCE 💜
There are three levels of conformance to this specification:
- Level 0: no support for IP multicasting.
There is, at this time, no requirement that all IP implementations support 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, and they SHOULD be quietly discarded by hosts that do not support IP multicasting. Class D addresses are described in section 4 of this memo. 🙈
- Level 1: support for sending but not receiving multicast IP datagrams.
Level 1 lets a host partake of some multicast-based services, such as resource location or status reporting, but it does not let a host 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 lets a host join and leave host groups, as well as send IP datagrams to host groups. It requires implementation of the Internet Group Management Protocol (IGMP) and extension of the IP and local network service interfaces within the host. All of the following sections of this memo are applicable to level 2 implementations 👑.
4. HOST GROUP ADDRESSES 🍓
Host groups are identified by class D IP addresses, i.e., those with "1110" as their high-order four bits. Class E IP addresses, i.e., those with "1111" as their high-order four bits, are reserved for future addressing modes 🔮.
In Internet standard "dotted decimal" notation, host group addresses range from 224.0.0.0 to 239.255.255.255. The 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 IP hosts. That one is used to address all multicast hosts 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 other well-known, permanent groups are to be published in "Assigned Numbers".
Appendix II contains some background discussion of several issues related to host group addresses 📚.
5. 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 this model, ICMP and (for level 2 hosts) IGMP 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 it SHOULD NOT be construed as constraining an actual implementation 🎀.
| |
| Upper-Layer Protocol Modules |
|__________________________________________________________|
--------------------- IP Service Interface -----------------------
__________________________________________________________
| | | |
| | ICMP | IGMP |
| IP |______________|______________|
| Module |
| |
|__________________________________________________________|
---------------- Local Network Service Interface -----------------
__________________________________________________________
| | |
| Local | IP-to-local address mapping |
| Network | (e.g., ARP) |
| Modules |_____________________________|
| (e.g., Ethernet) |
| |To support level 1 multicasting, a host IP implementation MUST support the transmission of multicast IP datagrams. To support level 2 IP 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 they aren't specified in detail 💅.
6. SENDING MULTICAST IP DATAGRAMS 🌸
6.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 just 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 IP time-to-live 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, it SHOULD default to 1 for all multicast IP datagrams. That way 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 implementations only), for the case in which the host is itself a member of a group that a datagram is being sent to, 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) 👑.
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:
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, a copy of the outgoing datagram MUST be looped-back for local delivery, unless inhibited by the sender. (Level 2 implementations only.) 🔁
A host group address SHOULD NOT be placed in the source address field, or anywhere in a source routing option, of an outgoing IP datagram 🙅♀️.
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 ✨
okay so Ethernet already supports sending local multicast packets 🫶 because you're allowed to put multicast addresses in the destination field of Ethernet packets. all you actually need for multicast IP datagrams is a procedure for mapping IP host group addresses to Ethernet multicast addresses 💅. the way it works: you take the low-order 23 bits of the IP address and drop them into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex) 💜. ngl, an IP host group address has 28 significant bits, so more than one host group address can map to the same Ethernet multicast address 🙈
6.5. Extensions to Local Network Modules other than Ethernet 🌈
other networks that directly support multicasting, like rings or buses that follow the IEEE 802.2 standard, can be handled the same way as Ethernet when it comes to sending multicast IP datagrams 🦋. for a network that supports broadcast but not multicast, like 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 🎀. and 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. that router takes responsibility for completing multicast delivery within the network as well as among networks 👑
7. RECEIVING MULTICAST IP DATAGRAMS 📬
7.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 📥. picking the destination upper-layer protocol is based on the protocol field in the IP header, regardless of the destination IP address. BUT before any datagrams for a particular group can be received, an upper-layer protocol must ask the IP module to join that group 🙋♀️. so the IP service interface needs to be extended with two new operations:
JoinHostGroup ( group-address, interface )
LeaveHostGroup ( group-address, interface )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 left out on hosts that can only be attached to one network. for hosts that can be attached to more than one network, the upper-layer protocol may choose to leave the interface unspecified, and then the request applies to the default interface for sending multicast datagrams (see section 6.1) 🧚
it's totally allowed to join the same group on more than one interface, but then you might get duplicate multicast datagrams 👯. it's also fine for more than one upper-layer protocol to ask for 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 because of an invalid group address or interface identifier. JoinHostGroup may also fail due to lack of local resources. LeaveHostGroup may fail because the host doesn't belong to the given group on the given interface. and LeaveHostGroup may succeed but the membership persists if more than one upper-layer protocol has requested membership in the same group 🫠
7.2. Extensions to the IP Module 🧠
to support receiving multicast IP datagrams, the IP module needs to maintain a list of host group memberships associated with each network interface. an incoming datagram destined to one of those groups gets processed exactly the same way as datagrams destined to one of the host's individual addresses 💜
incoming datagrams destined to groups the host doesn't belong to are discarded without generating any error report 🤐. on hosts attached to more than one network, if a datagram arrives via one network interface but is destined for a group the host belongs to only on a different interface, the datagram is quietly discarded too. (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 IP time-to-live of 1 (i.e., the time-to-live should not automatically be decremented on arriving datagrams that are not being forwarded) ⏱️. an incoming datagram is also not rejected for having an IP host group address in its source address field or anywhere in a source routing option 🫶. and an ICMP 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 🚫
the list of host group memberships gets updated when upper-layer protocols send JoinHostGroup and LeaveHostGroup requests 📝. each membership should have an associated reference count or similar mechanism so multiple requests to join and leave the same group get handled properly 🔢. 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 gets notified, so it can update its multicast reception filter (see section 7.3) 🔔
the IP module also needs to be extended to implement the IGMP protocol, specified in Appendix I 🌐. IGMP is used to keep neighboring multicast routers informed about the host group memberships present on a particular local network. to support IGMP, every level 2 host must join the "all-hosts" group (address 224.0.0.1) on each network interface at initialization time, and must stay a member for as long as the host is active 🥹
(datagrams addressed to the all-hosts group are recognized as a special case by the multicast routers and are never forwarded beyond a single network, regardless of their time-to-live. so the all-hosts address may not be used as an internet-wide broadcast address 🚧. for the purpose of IGMP, membership in the all-hosts group is really only necessary while the host belongs to at least one other group.)
however, it is specified that the host shall remain a member of the all-hosts group at all times, because (1) it is simpler, (2) the frequency of reception of unnecessary IGMP queries should be low enough that overhead is negligible, and (3) the all-hosts address may serve other routing-oriented purposes, such as advertising the presence of gateways or resolving local addresses. 🧚♀️💅
7.3. Extensions to the Local Network Service Interface 🎧
incoming local network multicast packets get delivered to the IP module using the same "Receive Local" operation as local network unicast packets. so that the IP module can tell the local network module which multicast packets to accept, the local network service interface is extended with two new operations 🎯:
JoinLocalGroup ( group-address )
LeaveLocalGroup ( group-address )where "group-address" is an IP host group address 💫. the JoinLocalGroup operation requests that the local network module accept and deliver up subsequently arriving packets destined to the given IP host group address. the LeaveLocalGroup operation requests that the local network module stop delivering up packets destined to the given IP host group address 🛑. the local network module is expected to map 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 it may deliver up packets destined to more addresses than just the ones specified in JoinLocalGroup requests, if it's 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 receiving 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's highly desirable to take advantage of any address filtering capabilities the Ethernet hardware interface may have, so the host only receives packets destined to it 🎀
ugh, the bad news: many current Ethernet interfaces have a small limit on how many addresses the hardware can be configured to recognize 😩. even so, an implementation must be capable of listening on an arbitrary number of Ethernet multicast addresses. that may mean "opening up" the address filter to accept all multicast packets during the 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 do Ethernet address filtering within the software of the Ethernet module. this is not mandatory, though, because the IP module does its own filtering based on IP destination addresses 💁♀️
7.5. Extensions to Local Network Modules other than Ethernet 💜
other multicast networks, like IEEE 802.2 networks, can be handled the same way as Ethernet for the purpose of receiving multicast IP datagrams 🌷. for pure broadcast networks, like 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 🥰
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP) 🦋
okay so the Internet Group Management Protocol (IGMP) is how IP hosts tell their immediately-neighboring multicast routers which host groups they belong to 💌 IGMP is asymmetric, which means it's written from the host's point of view, not the router's 👀 (IGMP MAY also be used, symmetrically or asymmetrically, between multicast routers. That's not specified here, so don't go looking for it in this doc 🙈)
Like ICMP, IGMP is an integral part of IP 🌈 It is REQUIRED to be implemented by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages ride inside IP datagrams with an IP protocol number of 2. Every IGMP message that hosts care about looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version 🎀
This memo specifies version 1 of IGMP. Version 0 was specified in RFC-988 and is now obsolete, so bye bye 👋
Type 💜
There are two types of IGMP message that hosts care about:
1 = Host Membership Query2 = Host Membership Report
Unused 🫶
It's an unused field: it gets zeroed when sent and ignored when received.
Checksum 🧮
The checksum is the 16-bit one's complement of the one's complement sum of the 8-octet IGMP message. When you're computing it, the checksum field itself gets zeroed first 🔥
Group Address 🍓
In a Host Membership Query message, the group address field is zeroed when sent and ignored when received.
In a Host Membership Report message, the group address field holds the IP host group address of the group being reported.
Informal Protocol Description ✨
Multicast routers send Host Membership Query messages (we'll just call them Queries from here on) to find out which host groups have members on their attached local networks 🔍 Queries go to the all-hosts group (address 224.0.0.1), and they carry an IP time-to-live of 1.
Hosts answer a Query by sending Host Membership Reports (Reports for short), telling the router about each host group they belong to on the network interface where the Query came in. To avoid an "implosion" of a bunch of Reports all at once, and to cut down on the total number of Reports sent, two techniques are used 🤯
- When a host gets a Query, it doesn't send Reports right away. Instead, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomly-chosen value between zero and D seconds. When a timer expires, a Report gets generated for the matching host group. So the Reports get spread out over a D second interval instead of all happening at once 🦋
- A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so other members of the same group on the same network can overhear it 👂 If a host hears a Report for a group it belongs to on that network, it stops its own timer for that group and doesn't generate a Report for it. So in the normal case, only one Report gets generated for each group on the network, by whichever member host's delay timer expires first 🏆 Also, the multicast routers receive all IP multicast datagrams, so they don't need to be addressed explicitly. And the routers don't need to know which hosts belong to a group, just that at least one host belongs to a group on a particular network 💅
There are two exceptions to what I just described. First, if a report delay timer is already running for a group membership when a Query comes in, that timer doesn't get reset to a new random value. It just keeps running with its current value 🙅♀️ Second, a report delay timer is never set for a host's membership in the all-hosts group (224.0.0.1), and that membership is never reported.
If a host uses a pseudo-random number generator to compute the reporting delays, one of the host's own individual IP address should be used as part of the seed for the generator. That helps lower the chance of multiple hosts generating the same sequence of delays 🌸
A host SHOULD confirm that a received Report has the same IP host group address in its IP destination field and its IGMP group address field. That way the host's own Report can't get cancelled by an erroneous received Report 🛡️ A host SHOULD quietly discard any IGMP message that isn't a Host Membership Query or a Host Membership Report.
Multicast routers send Queries periodically to keep their knowledge of memberships on a particular network fresh 🔄 If no Reports come in for a particular group after some number of Queries, the routers assume that group has no local members, so they don't need to forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently (no more than once a minute) so the IGMP overhead on hosts and networks stays super low 🌿 But when a multicast router starts up, it MAY issue several closely-spaced Queries in order to quickly build up its knowledge of local memberships ⚡
When a host joins a new group, it SHOULD immediately transmit a Report for that group, instead of waiting around for a Query. That covers the case where it's the first member of that group on the network 🚀 To cover the possibility of that first Report getting lost or damaged, it is RECOMMENDED that it be repeated once or twice after short delays. (A simple way to do this is to act as if a Query had been received for that group only, which sets the group's random report delay timer. The state transition diagram below shows this approach 🧚)
Note that on a network with no multicast routers present, the only IGMP traffic is the one or more Reports sent whenever a host joins a new group 💖
State Transition Diagram 🌸
IGMP behavior is more formally specified by the state transition diagram below. A host may be in one of three possible states, with respect to any single IP host group on any single network interface:
- Non-Member state, when the host does not belong to the group on the interface. This is the initial state for all memberships on all network interfaces, and it requires no storage in the host 🫧
- Delaying Member state, when the host belongs to the group on the interface and has a report delay timer running for that membership ⏳
- Idle Member state, when the host belongs to the group on the interface and does not have a report delay timer running for that membership 😌
There are five significant events that can cause IGMP state transitions:
- "join group" occurs when the host decides to join the group on the interface. It may occur only in the Non-Member state.
- "leave group" occurs when the host decides to leave the group on the interface. It may occur only in the Delaying Member and Idle Member states.
- "query received" occurs when the host receives a valid IGMP Host Membership Query message. To be valid, the Query message MUST be at least 8 octets long and have a correct IGMP checksum. A single Query applies to all memberships on the interface from which the Query is received. It is ignored for memberships in the Non-Member or Delaying Member state.
- "report received" occurs when the host receives a valid IGMP Host Membership Report message. To be valid, the Report message MUST be at least 8 octets long, have a correct IGMP checksum, and contain the same IP host group address in its IP destination field and its IGMP group address field. A Report applies only to the membership in the group identified by the Report, on the interface from which the Report is received. It is ignored for memberships in the Non-Member or Idle Member state.
- "timer expired" occurs when the report delay timer for the group on the interface expires. It may occur only in the Delaying Member state.
All other events, like receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states 🙃
There are three possible actions that may be taken in response to the above events:
- "send report" for the group on the interface.
- "start timer" for the group on the interface, using a random delay value between 0 and D seconds.
- "stop timer" for the group on the interface.
In the following diagram, each state transition arc is labelled with the event that causes the transition and, in parentheses, any actions taken during the transition 🗺️
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave group
| (stop timer) |(send report, |
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
| |------------------->| |
| | report received | |
| | (stop timer) | |
|_________________|------------------->|_________________|
timer expired
(send report)The all-hosts group (address 224.0.0.1) is handled as a special case 👑 The host starts in Idle Member state for that group on every interface, never transitions to another state, and never sends a report for that group.
Protocol Parameters 👑
The maximum report delay, D, is 10 seconds ⏰
APPENDIX II. HOST GROUP ADDRESS ISSUES 💅
This appendix is not part of the IP multicasting specification, but it gives some background discussion of several issues related to IP host group addresses 🧠
Group Address Binding ✨
okay so binding IP host group addresses to physical hosts is kind of a glow-up of binding regular IP unicast addresses 🎀. A unicast address is statically bound to a single local network interface on a single IP network, so it's very much a one-of-one situation 💅. A host group address is dynamically bound to a set of local network interfaces across a set of IP networks. Main character energy, honestly 🦋
It's super important to get this part: an IP host group address is NOT bound to a set of IP unicast addresses 🫶. Multicast routers don't need to keep a list of every individual member of each host group 🍓. For example, a multicast router attached to an Ethernet only needs to associate a single Ethernet multicast address with each host group that has local members, instead of keeping a list of each member's individual IP or Ethernet addresses. So much less bookkeeping, I'm obsessed 😭
Group Addresses as Logical Addresses
Host group addresses were defined specifically for the destination address field of multicast IP datagrams 💜. BUT the fact that group addresses are location-independent (they aren't statically bound to a single network interface) makes them kinda iconic for more general "logical addresses," in both the source and destination address fields of datagrams 🧚. For example, a mobile IP host could use a host group address as its only identity, and use it as the source of the datagrams it sends. Whenever the mobile host moved from one network to another, it would join its own group on the new network and leave the group on the old network. Other hosts talking to the mobile one would only deal with the group address and wouldn't even notice, or be affected by, the mobile host changing networks 🌈
Now, host group addresses can't solve every internetwork logical addressing problem 💀. Things like delivering to the "nearest" or the "least loaded" network interface of a multi-homed host are not something they can handle. There are also hazards when you use group addresses in the source address field of datagrams, especially when the group actually contains more than one host 🙈. For instance, the IP datagram reassembly algorithm relies on every host using a different source address. Also, errors in a datagram sent with a group source address may result in error reports being returned to all members of the group, not just the sender 😬. Because of these hazards, this memo specifies the use of host group addresses only in the IP destination address field. That said, it is recommended that datagrams with a group source address, or a group address as part of a source routing option, be accepted without complaint, so other implementations can experiment with logical addressing applications of host group addresses ✨
Allocation of Transient Host Group Addresses
This memo does not specify how transient group addresses are allocated 🔮. It's 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 RFC-1045) 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. This is similar 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 by generating new addresses until a suitably "quiet" one is found 🦋
Here's the tea 🍵: 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 has to be detected at a level above IP, using higher-level identifiers or authentication tokens 🔐. Information sent to a host group address should be encrypted or governed by administrative routing controls if the sender is concerned about unwanted listeners 👀
APPENDIX III. CHANGES FROM RFC-988 💖
The IP multicast extensions in this memo are significantly different from the ones in RFC-988 🫶. Most of the changes come from a shift of responsibility away from the multicast routers (called "multicast agents" in RFC-988) and onto the hosts 🧚. This new split of responsibility fits the lightweight, soft-state gateway architecture of the Internet, and it lets the IP multicast services (just like the IP unicast services) be used among hosts on a single network when no router is up or present on that network 🌸. So current single-network IP broadcast applications can move over to IP multicast before multicast routers are widely available, which is so smart 😭. The following changes are a consequence of this shift of responsibility:
- Private host groups and access keys have been eliminated. The multicast routers are no longer considered trustworthy controllers of group membership 🙅♀️. It's now up to hosts and their administrators to provide their own mechanisms to prevent unwanted eavesdropping on group communication, perhaps by using end-to-end encryption or by imposing restrictions on the flow of IP multicast datagrams into and out of particular administrative domains 🔒
- The CreateHostGroup operation has been eliminated. The responsibility for allocating transient host groups has moved from multicast routers to the hosts 🎀. See Appendix II for a brief discussion of some ways hosts might do their own transient group allocation 💅
- The JoinHostGroup and LeaveHostGroup operations have become non-blocking, because it's no longer necessary to await approval from a multicast router when changing membership 🦋. It's also no longer possible for a host to have its membership revoked by a multicast router 🙌
- The IGMP protocol is substantially different from the one in RFC-988, reflecting the changed roles of hosts and multicast routers 🍓
- The new IGMP requires that there be an "all-hosts" group. There's no longer a need for an "all-multicast-agents" group 🌈
Other changes that are not related to the shift of responsibility are:
- The decision whether or not to loop back a multicast datagram sent from a member of the destination group is now made at the time the datagram is sent, rather than at the time the group is joined. This gives the sender another degree of scope control, beyond the IP time-to-live ⭐
- The handling of IP time-to-live, and of multiple network interfaces, has been more precisely specified 💜
- Hosts are no longer allowed to place an IP host group address in a source routing option 🙅♀️
- The AcceptAddress and RejectAddress operations at the local network service interface have been renamed JoinLocalGroup and LeaveLocalGroup, to emphasize their semantic similarity to the JoinHostGroup and LeaveHostGroup operations at the IP service interface 🫶
- A new mapping algorithm for Ethernet multicast addresses has been specified 🧚
- The organization of the memo has been changed somewhat, and a state transition diagram has been added to the IGMP specification 🎀
📦 where this page comes from
- ietf: rfc1054 1988-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms