RFC 1112
Host extensions for IP multicasting
📜 RFC 1112: Host Extensions for IP Multicasting 🎀
Okay bestie, this one is by S. Deering at Stanford University, dated August 1989, from the Network Working Group. It obsoletes RFCs 988 and 1054, so those are officially retired 🙈 The header has no Updates line and doesn't list a category, but section 1 calls it the recommended standard for IP multicasting. Let's get into it ✨
1. STATUS OF THIS MEMO ✨
So this memo spells out the extensions that a host's IP implementation is REQUIRED to have if it wants to do multicasting 💖 It's the recommended standard for IP multicasting on the Internet, and distribution is unlimited, so share it with everyone 🌸
2. INTRODUCTION 🦋
IP multicasting means sending one IP datagram to a "host group," which is a set of zero or more hosts that all share one IP destination address. A multicast datagram reaches every member of its host group with the same "best-efforts" reliability you'd get from a regular unicast datagram. Translation: it is NOT guaranteed to show up intact at every member, or to arrive in the same order relative to other datagrams, so the vibes are a little chaotic 💀
Group membership is super dynamic. Hosts MAY join and leave groups whenever they want 🧚 There's no limit on where members are or how many there are, and one host MAY be in more than one group at a time. A host doesn't have to be a member of a group to send datagrams to it, which is honestly so iconic 👑
A host group can be permanent or transient. A permanent group has a well-known IP address that an administrator assigns. The address is what's permanent, not the membership, so a permanent group MAY have any number of members, even zero 🌈 Any multicast addresses NOT reserved for permanent groups are open for dynamic assignment to transient groups, which only exist as long as they have members 🍓
Forwarding multicast datagrams between networks is handled by "multicast routers," which MAY sit alongside internet gateways or be separate from them 💅 A host sends an IP multicast datagram as a local network multicast, and that reaches all of its immediate neighbours in the group. If the datagram's IP time-to-live is greater than 1, the multicast router(s) on the local network take responsibility for forwarding it to every other network with group members. On those other member networks that are reachable within the time-to-live, a multicast router finishes delivery by sending the datagram as a local multicast 🫶
This memo covers the extensions a host IP implementation REQUIRES to support IP multicasting, where a "host" is any internet host or gateway other than one acting as a multicast router 🎀 The algorithms and protocols used inside and between multicast routers are invisible to hosts, and they'll get their own documents. This memo also doesn't cover how local network multicasting works for every type of network. It does define the required service interface to an arbitrary local network, and it uses Ethernet as an example. Specs for other network types will come in future memos 🔥
3. LEVELS OF CONFORMANCE 🌸
There are three levels of conformance to this specification, and I'm going to break them down for you 💜
Level 0: no support for IP multicasting.
Right now there's no requirement that every IP implementation supports multicasting. Level 0 hosts are generally unaffected by multicast activity 😭 The one exception is certain types of local network, where level 1 or 2 hosts can cause multicast IP datagrams to be misdelivered to level 0 hosts. You can spot those datagrams easily because their destination address field has a class D IP address in it, and hosts that don't support multicasting SHOULD quietly discard them 🙈 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 join in on some multicast-based services, like resource location or status reporting, but it does NOT let the host join any host groups 🦋 An IP implementation MAY be upgraded from level 0 to level 1 very easily and with very little new code ✨ Only sections 4, 5, and 6 of this memo apply to level 1 implementations.
Level 2: full support for IP multicasting.
Level 2 is the whole package: a host can join and leave host groups and send IP datagrams to host groups 👑 It requires implementing the Internet Group Management Protocol (IGMP) and extending the IP and local network service interfaces inside the host. Every section of this memo applies to level 2 implementations 💖
4. HOST GROUP ADDRESSES 🧚
Host groups are identified by class D IP addresses, which are the ones with 1110 as their high-order four bits 💅 Class E IP addresses, the ones with 1111 as their high-order four bits, are reserved for future addressing modes 🌈
In standard dotted decimal notation, host group addresses run from 224.0.0.0 to 239.255.255.255 🍓 The address 224.0.0.0 is guaranteed never to be assigned to any group. The address 224.0.0.1 belongs to the permanent group of all IP hosts (gateways included), and it's used to reach all multicast hosts on the directly connected network 🫶 There's no multicast address, or any other IP address, for all hosts on the entire Internet. Addresses for other well-known permanent groups are going to be published in "Assigned Numbers" 🎀
Appendix II has some background discussion on several issues related to host group addresses 🔥
5. MODEL OF A HOST IP IMPLEMENTATION 💜
The multicast extensions to a host IP implementation are described using the layered model below 🦋 In this model, ICMP and (for level 2 hosts) IGMP are considered to live inside the IP module, and mapping IP addresses to local network addresses is the job of the local network modules. This model is just for explaining things, and it SHOULD NOT be read as limiting 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 provide level 1 multicasting, a host IP implementation MUST support sending multicast IP datagrams 🌸 To provide level 2 multicasting, a host MUST also support receiving multicast IP datagrams. Each of these two new services gets its own section below ✨ For each one, the spec covers 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 get a brief mention but aren't specified in detail 🧚
6. SENDING MULTICAST IP DATAGRAMS 🎀
6.1. Extensions to the IP Service Interface 💖
Multicast IP datagrams go out through the same "Send IP" operation used for unicast datagrams 🦋 The only difference is that the upper-layer protocol module gives a host group address as the destination, instead of an individual IP address. Some extensions MAY still be necessary or desirable, though 👑
First, the service interface SHOULD give the upper-layer protocol a way to set the IP time-to-live of an outgoing multicast datagram, if that capability doesn't already exist 🌈 If the upper-layer protocol doesn't set a time-to-live, it SHOULD default to 1 for all multicast IP datagrams. That way, you have to make an explicit choice to multicast beyond a single network 🔥
Second, for hosts attached to more than one network, the service interface SHOULD give the upper-layer protocol a way to name which network interface is used for the multicast transmission 🍓 Only one interface is used for the initial transmission, and multicast routers handle forwarding to any other networks if needed 🫶 If the upper-layer protocol doesn't name an outgoing interface, a default interface SHOULD be used, preferably one controlled by system management 💅
Third (level 2 implementations only), if the host is itself a member of the group a datagram is being sent to, the service interface SHOULD give the upper-layer protocol a way to stop local delivery of that datagram. By default, a copy of the datagram gets looped back 🧚 This is a performance optimization for upper-layer protocols that limit a group to one process per host (like a routing protocol), or that handle loopback of group communication at a higher layer (like a multicast transport protocol) 🎀
6.2. Extensions to the IP Module ✨
To support sending multicast IP datagrams, the IP module MUST be extended to recognize IP host group addresses when routing outgoing datagrams 💜 Most IP implementations already have this 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 change 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 the sender inhibits it. (Level 2 implementations only.) 🦋
The IP source address of the outgoing datagram MUST be one of the individual addresses that match the outgoing interface 💖
A host group address MUST never be placed in the source address field, or anywhere in a source route or record route 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 sending multicast IP datagrams 😭 The IP module just gives a host group destination, instead of an individual IP destination, when it calls the existing "Send Local" operation. Easy, no drama 💅
6.4. Extensions to an Ethernet Local Network Module 🐝
okay so Ethernet is literally already set up for this 🫶 it lets multicast addresses sit right in the destination field of its packets. All you need to get multicast IP datagrams going is a procedure that maps IP host group addresses onto Ethernet multicast addresses. ✨
Here's the trick 🪄 An IP host group address gets mapped to an Ethernet multicast address by copying its low-order 23 bits into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Since an IP host group address has 28 significant bits, more than one host group address MAY 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 IEEE 802.2, MAY be handled the same way as Ethernet when it comes to sending multicast IP datagrams. 🧚
For a network that does broadcast but not multicast, like the Experimental Ethernet, all IP host group addresses MAY be mapped to a single local broadcast address. Just know this costs extra overhead on every local host 😭
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 that kind of network would take 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 here's the catch: before any datagrams destined to a particular group can be received, an upper-layer protocol MUST ask the IP module to join that group. So the IP service interface MUST be extended to provide 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 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 that case, the request applies 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. 🙈
7.2. Extensions to the IP Module ⚙️
To support receiving 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 the host does not belong to are discarded without any error report or log entry. On hosts with more than one network interface, if a datagram arrives via one interface but is destined for a group the host belongs to only on a different interface, the datagram is quietly discarded. (These cases SHOULD occur only as a result of inadequate multicast address filtering in a local network module.) 🫣
An incoming datagram is not rejected for having an 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 with an IP host group address in its source address field is quietly discarded. 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 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). 🌈
The IP module MUST also be extended to implement the IGMP protocol, specified in Appendix I. IGMP keeps neighboring multicast routers informed of 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 remain 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. Thus, 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 necessary only 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 are delivered to the IP module using the same "Receive Local" operation as local network unicast packets. To let the IP module 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 )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 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 is highly desirable to take advantage of any address filtering capabilities the Ethernet hardware interface may have, so 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 the hardware can be configured to recognize. Nevertheless, an implementation MUST be capable of listening on an arbitrary number of Ethernet multicast addresses. This 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, 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 bestie, IGMP (Internet Group Management Protocol) is how IP hosts tell their immediately-neighboring multicast routers which host groups they belong to 🫶. it's asymmetric, so this part is written from the host's point of view, not the router's 💅. (IGMP can also be used between multicast routers, symmetrically or asymmetrically, but that's not specified here 🙈)
ok so IGMP is basically an integral part of IP, like ICMP ✨. it's 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 matters to hosts 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 is specified in RFC-988 and is now obsolete 🥀
Type
there are two types of IGMP message that concern hosts 💌
1 = Host Membership Query
2 = Host Membership ReportUnused
it's unused, so you zero it when you send and just ignore it when you receive 🫧
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, you zero out the checksum field first. main character energy for the math 💅
Group Address
in a Host Membership Query, the group address field gets zeroed when sent and ignored when received 🙃
in a Host Membership Report, 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 (hereinafter called Queries) to figure out which host groups have members on their attached local networks 👀. Queries go to the all-hosts group (address 224.0.0.1) and carry an IP time-to-live of 1 🌸
hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), one for each host group they're in, on the network interface the Query came in on 💜. to avoid an "implosion" of concurrent Reports and to cut down on the total number of Reports sent, there are two techniques going on 😭
- 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 interface the Query arrived on. each timer gets a different, randomly-chosen value between zero and D seconds. when a timer goes off, a Report is generated for that host group. so the Reports are spread out over a D second interval instead of all happening at once 🦋
- a Report gets 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 per group on the network, by whichever member's delay timer expires first 🏆. also, the multicast routers receive all IP multicast datagrams, so they don't need to be addressed explicitly 🧚. and routers don't need to know which hosts are in a group, just that at least one host is in a group on a particular network 💖
there are two exceptions to all that. first, if a report delay timer is already running for a group membership when a Query arrives, 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 addresses should be used as part of the seed, so multiple hosts are less likely to end up with the same sequence of delays 🎲
a host should check that a received Report has the same IP host group address in its IP destination field and its IGMP group address field. that way its own Report can't get cancelled by a wrong Report someone else sent 🛡️. and a host should quietly discard any IGMP message that isn't a Host Membership Query or Host Membership Report 🤫
multicast routers send Queries periodically to refresh what they know about memberships on a network 🔁. if no Reports come in for a 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 first starts up, it may send several closely-spaced Queries to build up its knowledge of local memberships quickly 🚀
when a host joins a new group, it should immediately send a Report for that group instead of waiting for a Query, in case it's the first member of that group on the network 🙌. to cover the chance that the initial Report gets lost or damaged, it's recommended to repeat it 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, and set the group's random report delay timer. the state transition diagram below shows this approach 🗺️)
fun fact (well, it's in the spec): 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 can 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 doesn't 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" happens when the host decides to join the group on the interface. it can only happen in the Non-Member state.
- "leave group" happens when the host decides to leave the group on the interface. it can only happen in the Delaying Member and Idle Member states.
- "query received" happens when the host receives a valid IGMP Host Membership Query message. to be valid, the Query message must be at least 8 octets long, have a correct IGMP checksum, and have an IP destination address of
224.0.0.1. a single Query applies to all memberships on the interface it came in on. it gets ignored for memberships in the Non-Member or Delaying Member state. - "report received" happens 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 only applies to the membership in the group it identifies, on the interface it came in on. it gets ignored for memberships in the Non-Member or Idle Member state.
- "timer expired" happens when the report delay timer for the group on the interface runs out. it can only happen in the Delaying Member state.
all other events, like receiving invalid IGMP messages or IGMP messages other than Query or Report, get ignored in all states 🙅♀️
there are three possible actions that can happen in response to the events above 🎬:
- "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 diagram below, 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 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 isn't part of the IP multicasting specification, but it gives background discussion on several issues related to IP host group addresses 📚
Group Address Binding
Okay so, binding IP host group addresses to physical hosts is basically a glow-up of how unicast addresses get bound 💅✨. A unicast address is statically bound to one local network interface on one IP network, super locked in. A host group address is dynamically bound to a set of local network interfaces across a set of IP networks 🦋.
Bestie, this is the important part 🫶: an IP host group address is NOT bound to a set of IP unicast addresses. Multicast routers don't have to keep a list of every single member of each host group 🙈. For example, a multicast router attached to an Ethernet only needs to associate one Ethernet multicast address with each host group that has local members. It doesn't need a list of each member's IP or Ethernet addresses. Minimal, iconic, no notes 💜.
Allocation of Transient Host Group Addresses
This memo does not specify how transient group addresses get allocated 🧚. Different chunks of the IP transient host group address space are expected to be allocated using different techniques, which is giving variety 🌈. For example, there could be a bunch of servers you can contact to grab a fresh transient group address 💖. Some higher-level protocols (like VMTP, specified in RFC-1045) might generate higher-level transient "process group" or "entity group" addresses, and those then get algorithmically mapped onto a subset of the IP transient host group addresses. It's the same vibe as how IP host group addresses get mapped to Ethernet multicast addresses 🎀. A portion of the IP group address space may also be set aside for random allocation by applications that can handle the occasional collision with other multicast users. Those apps might just keep generating new addresses until they find a suitably "quiet" one 🤫🌸.
Now the serious bit 💀. In general, a host cannot assume that datagrams sent to any host group address will reach only the intended hosts. It also can't assume that datagrams received as a member of a transient host group are meant for it 😭. Misdelivery has to be detected at a level above IP, using higher-level identifiers or authentication tokens 🔥. If the sender is worried about unwanted listeners, information sent to a host group address should be encrypted or governed by administrative routing controls 🔐. Not me having to say this twice.
Author's Address
Steve Deering
Stanford University
Computer Science Department
Stanford, CA 94305-2140
Phone: (415) 723-9427
EMail: deering@PESCADERO.STANFORD.EDU📦 where this page comes from
- ietf: rfc1112 1989-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms