Host extensions for IP multicasting
RFC 988
| Document | Type |
RFC - Unknown
(July 1986; No errata)
Obsoletes RFC 966
|
|
|---|---|---|---|
| Authors | |||
| Last updated | 2013-03-02 | ||
| Stream | Legacy stream | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | Legacy state | (None) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | RFC 988 (Unknown) | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group S. E. Deering
Request for Comments: 988 Stanford University
July 1986
Host Extensions for IP Multicasting
1. STATUS OF THIS MEMO
This memo specifies the extensions required of a host implementation
of the Internet Protocol (IP) to support internetwork multicasting.
This specification supersedes that given in RFC-966, and constitutes
a proposed protocol standard for IP multicasting in the
ARPA-Internet. The reader is directed to RFC-966 for a discussion of
the motivation and rationale behind the multicasting extension
specified here. Distribution of this memo is unlimited.
2. INTRODUCTION
IP multicasting is defined as 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 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, but membership in a
group may be restricted to only those hosts possessing a private
access key. 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. A
transient group, on the other hand, is assigned an address
dynamically when the group is created, at the request of a host. A
transient group ceases to exist, and its address becomes eligible for
reassignment, when its membership drops to zero.
The creation of transient groups and the maintenance of group
membership information is the responsibility of "multicast agents",
entities that reside in internet gateways or other special-purpose
hosts. There is at least one multicast agent directly attached to
every IP network or subnetwork that supports IP multicasting. A host
requests the creation of new groups, and joins or leaves existing
groups, by exchanging messages with a neighboring agent.
Deering [Page 1]
RFC 988 July 1986
Host Extensions for IP Multicasting
Multicast agents are also responsible for internetwork delivery of
multicast IP datagrams. When sending a multicast IP datagram, a host
transmits it to a local network multicast address which identifies
all neighboring members of the destination host group. If the group
has members on other networks, a multicast agent becomes an
additional recipient of the local multicast and relays the datagram
to agents on each of those other networks, via the internet gateway
system. Finally, the agents on the other networks each transmit the
datagram as a local multicast to their own neighboring members of the
destination group.
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 serving as multicast
agents. The algorithms and protocols used within and between
multicast agents are transparent to non-agent hosts and will be
specified in a separate document. 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:
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; they
should be quietly discarded by hosts that do not support IP
multicasting. Class D addresses are defined in section 4 of this
memo.
Deering [Page 2]
RFC 988 July 1986
Host Extensions for IP Multicasting
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 create or join any host groups. An IP
implementation may be upgraded from level 0 to level 1 very easily
and with little new code. Only sections 4, 5, and 6 of this memo
are applicable to level 1 implementations.
Level 2: full support for IP multicasting.
Level 2 allows a host to create, 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. The remaining 28 bits are
unstructured as far as hosts are concerned. The addresses of
well-known, permanent groups are to be published in "Assigned
Numbers". Class E IP addresses, i.e. those with "1111" as their
high-order four bits, are reserved for future addressing modes.
Appendix II contains some background discussion of several issues
related to host group addresses.
Deering [Page 3]
RFC 988 July 1986
Host Extensions for IP Multicasting
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 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 2 IP multicasting, a host IP implementation must
provide three new services: (1) sending multicast IP datagrams, (2)
receiving multicast IP datagrams, and (3) managing group membership.
Only the first service need be provided in level 1 hosts. Each of
these 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 [Page 4]
RFC 988 July 1986
Host Extensions for IP Multicasting
6. SENDING MULTICAST IP DATAGRAMS
6.1. Extensions to the IP Service Interface
No change to the IP service interface is required to support the
sending of multicast IP datagrams. An upper-layer protocol module
merely specifies an IP host group destination, rather than an
individual IP destination, when it invokes the existing "Send IP"
operation.
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 if and only if loopback was requested when the host
joined the group (see section 8.1). (This issue does not arise in
level 1 implementations.)
On hosts attached to more than one network, each multicast IP
datagram must be transmitted via one network interface only,
leaving it to the multicast agents to effect delivery to any other
required networks.
A host group address should not be placed in the source address
field of an outgoing IP datagram. A host group address may be
used in a source routing option as the last element only.
It should be noted that a small IP time-to-live (TTL) value can
Deering [Page 5]
RFC 988 July 1986
Host Extensions for IP Multicasting
prevent delivery to some members of a destination group. Thus, a
large TTL value should be used to reach all members. Conversely,
a small TTL value can be used to advantage to reach only "nearby"
members of a widely-dispersed group. In clusters of low-delay
local area networks, the TTL field acts as a hop limit; thus, one
can perform expanding-ring searches by starting with a TTL of 1
and incrementing on each retransmission, up to some limit defined
by the diameter of the cluster.
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 IP host group address is mapped to an Ethernet multicast
address by placing the low-order 28-bits of the IP address into
the low-order 28 bits of an Ethernet address. The high-order 20
bits of the Ethernet address are set to a well-known value, to be
published in "Assigned Numbers".
[At time of publication of this memo, a block of Ethernet
multicast addresses with 28 unspecified bits had not yet been
obtained from the allocating authority. If such a block of
addresses cannot be obtained, an alternative mapping scheme will
be specified.]
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, can 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 can be mapped to a single local broadcast address (at
the cost of increased overhead on all local hosts). For a
point-to-point networks like the ARPANET or a public data network
Deering [Page 6]
RFC 988 July 1986
Host Extensions for IP Multicasting
(X.25), all IP host group addresses might be mapped to the
well-known local address of an IP multicast agent; an agent on
such a 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
No change to the IP service interface is required to support the
reception of multicast IP datagrams. Incoming multicast IP
datagrams are delivered to upper-layer protocol modules using the
same "Receive IP" operation as normal, unicast datagrams.
7.2. Extensions to the IP Module
To support the reception of multicast IP datagrams, the IP module
must be extended to recognize the addresses of IP host groups to
which the host currently belongs, in addition to the host's
individual IP address(es). An incoming datagram destined to one
of those group addresses 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.
On hosts attached to more than one network, if a datagram arrives
via one network interface, destined for a group to which the host
belongs only on a different interface, the datagram is quietly
discarded. (This should occur only as a result of inadequate
multicast address filtering in the local network module.)
An incoming datagram is not rejected for having an IP host group
address in its source address field or anywhere in a source
routing option.
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.
7.3. Extensions to the Local Network Service Interface
No change to the local network service interface is required to
support the reception of multicast IP datagrams. Incoming local
network packets, whether multicast or unicast, are delivered to
the IP module using the same "Receive Local" operation.
Deering [Page 7]
RFC 988 July 1986
Host Extensions for IP Multicasting
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 only receives 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. However, 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 a
point-to-point network, multicast IP datagrams will arrive as
local network unicasts, so no change to the local network module
should be necessary.
Deering [Page 8]
RFC 988 July 1986
Host Extensions for IP Multicasting
8. MANAGING GROUP MEMBERSHIP
8.1. Extensions to the IP Service Interface
To allow upper-layer protocol modules to request that their host
create, join, or leave a host group, the IP service interface must
be extended to offer the following three new operations:
CreateGroup ( private, loopback )
--> outcome, group-address, access-key
The CreateGroup operation requests the creation of a new,
transient host group, with this host as its only member. The
"private" argument specifies if the group is to be private or
public. The "loopback" argument specifies whether or not
datagrams sent from this host to the group should be delivered
locally as well as to other member hosts. The "outcome" result
indicates whether the request is granted or denied. If it is
granted, a new 32-bit IP host group address is returned, along
with a 64-bit access key which is zero for public groups and
non-zero for private groups. The request may be denied due to
lack of response from a multicast agent, or lack of resources.
JoinGroup ( group-address, access-key, loopback ) --> outcome
The JoinGroup operation requests that this host become a member of
the host group identified by "group-address", with the specified
access key. The "loopback" argument specifies whether or not
datagrams sent from this host to the group should be delivered
locally as well as to other member hosts. The "outcome" result
indicates whether the request is granted or denied. The request
may be denied due to lack of response from a multicast agent, lack
of resources, an invalid group address, an incorrect access key,
or already being a member.
LeaveGroup ( group-address, access-key ) --> outcome
The LeaveGroup operation requests that this host give up its
membership in the host group identified by "group-address", with
the specified access key. The "outcome" result indicates whether
the request is granted or denied. The request may be denied due
to an invalid group address, an incorrect access key, or not
currently being a member.
Each of these operations may take up to a minute or more to
complete, depending on the number of IGMP retransmissions
Deering [Page 9]
RFC 988 July 1986
Host Extensions for IP Multicasting
performed within the IP module, and time required for a multicast
agent to generate a reply. However, typical delays should be on
the order of a few seconds.
Besides the LeaveGroup operation, a host loses its membership in a
group whenever the host or its IP module crashes, or, in rare
circumstances, when a multicast agent revokes its membership. The
IP service interface should provide some means of informing an
upper-layer module when its membership has been revoked.
Membership may be revoked due to lack of resources, deallocation
of the group address, or the discovery of another host group using
the same group address with a different access key. (See Appendix
II for discussion of address recycling issues.)
It is important to observe that IP group membership is per-host,
rather than per-process. An IP service interface should not allow
multiple processes to invoke JoinGroup operations for the same
group as a way of achieving delivery to more than process. The IP
module delivers each incoming datagram, whether multicast or
unicast, to the single upper-layer protocol module identified by
the protocol field in the datagram's IP header; it is an
upper-layer issue whether or not to deliver incoming datagrams to
more than one process, perhaps using the concept of "process
groups" or "shared ports".
8.2. Extensions to the IP Module
Within the IP module, the membership management operations are
supported by the Internet Group Management Protocol (IGMP),
specified in Appendix I. As well as having messages corresponding
to each of the operations specified above, IGMP also specifies a
"deadman timer" procedure whereby hosts periodically confirm their
memberships with the multicast agents.
The IP module must maintain a data structure listing the IP
addresses of all host groups to which the host currently belongs,
along with each group's loopback policy, access key, and timer
variables. This data structure is used by the IP multicast
transmission service to know which outgoing datagrams to loop
back, and by the reception service to know which incoming
datagrams to accept. The purpose of IGMP and the management
interface operations is to maintain this data structure.
On hosts attached to more than one network, each membership is
associated with a particular network interface. On such a host
the management interface operations above may each require an
additional parameter specifying to which interface the create,
Deering [Page 10]
RFC 988 July 1986
Host Extensions for IP Multicasting
join, or leave request applies. The group membership data
structure must also be extended to associate an interface with
each membership. If a host joins the same host group on more than
one network interface, it can expect to receive multiple copies of
each datagram sent to that group.
8.3. Extensions to the Local Network Service Interface
To allow an IP module to control what packets should be accepted
by the local network module, it is necessary to extend the local
network service interface with the following two new operations:
AcceptAddress ( group-address )
RejectAddress ( group-address )
where "group-address" is an IP host group address. The
AcceptAddress operation requests the local network module to
accept and deliver up subsequently arriving packets destined to
the local network address corresponding to "group-address". The
RejectAddress operation requests the local network module to stop
delivering up packets destined to the local network address
corresponding to "group-address".
Any local network module is free to ignore RejectAddress requests,
and may deliver up packets destined to more addresses than just
those specified in AcceptAddress requests, if it is unable to
filter incoming packets adequately.
8.4. Extensions to an Ethernet Local Network Module
An Ethernet module responds to AcceptAddress operations by adding
the corresponding Ethernet multicast address to its acceptance
filter for incoming packets. A RejectAddress operation causes the
corresponding Ethernet address to be dropped from the filter. For
Ethernet interfaces with a limit on the number of addresses that
can be added to the filter, the Ethernet software module must
detect when that threshold is exceeded and open up the filter to
accept all multicast packets. It should also detect when the
number of addresses drops below the threshold and revert to
individual address filtering.
8.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 controlling
address filtering. For a pure broadcast network or a
Deering [Page 11]
RFC 988 July 1986
Host Extensions for IP Multicasting
point-to-point network, the AcceptAddress and RejectAddress
operations may have no effect; all incoming packets could be
passed to the IP module for IP-level filtering.
Deering [Page 12]
RFC 988 July 1986
Host Extensions for IP Multicasting
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
The Internet Group Management Protocol (IGMP) is used between IP
hosts and their immediate neighbor multicast agents to support the
creation of transient groups, the addition and deletion of members of
a group, and the periodic confirmation of group membership. IGMP is
an asymmetric protocol and is specified here from the point of view
of a host, rather than a multicast agent.
Like ICMP, IGMP is a integral part of IP. It is required to be
implemented in full by all hosts conforming to level 2 of the IP
multicasting specification. IGMP messages are encapsulated in IP
datagrams, with an IP protocol number of 2. All IGMP messages have
the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
There are eight types of IGMP message:
1 = Create Group Request
2 = Create Group Reply
3 = Join Group Request
4 = Join Group Reply
5 = Leave Group Request
6 = Leave Group Reply
7 = Confirm Group Request
8 = Confirm Group Reply
Deering [Page 13]
RFC 988 July 1986
Host Extensions for IP Multicasting
Code
In a Create Group Request message, the code field indicates if the
new host group is to be public or private:
0 = public
1 = private
In all other Request messages, the code field contains zero.
In a Reply message, the Code field specifies the outcome of the
request:
0 = request granted
1 = request denied, no resources
2 = request denied, invalid code
3 = request denied, invalid group address
4 = request denied, invalid access key
5 - 255 = request pending, retry in this many seconds
Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the IGMP message starting with the IGMP Type.
For computing the checksum, the checksum field should be zero.
Identifier
In a Confirm Group Request message, the identifier field contains
zero.
In all other Request messages, the identifier field contains a
value to distinguish the request from other requests by the same
host.
In a Reply message, the identifier field contains the same value
as in the corresponding Request message.
Deering [Page 14]
RFC 988 July 1986
Host Extensions for IP Multicasting
Group Address
In a Create Group Request message, the group address field
contains zero.
In all other Request messages, the group address field contains a
host group address.
In a Create Group Reply message, the group address field contains
either a newly allocated host group address (if the request is
granted) or zero (if denied).
In all other Reply messages, the group address field contains the
same host group address as in the corresponding Request message.
Access Key
In a Create Group Request message, the access key field contains
zero.
In all other Request messages, the access key field contains the
access key assigned to the host group identified in the Group
Address field (zero for public groups).
In a Create Group Reply message, the access key field contains
either a non-zero 64-bit number (if the request for a private
group is granted) or zero.
In all other Reply messages, the access key field contains the
same access key as in the corresponding Request.
Deering [Page 15]
RFC 988 July 1986
Host Extensions for IP Multicasting
Protocol Rules
Request messages are sent only by hosts. Reply messages are sent
only by multicast agents. If a host receives an IGMP message of a
type other than the four Reply types specified above, the message
is discarded.
A Request message is sent with its IP destination field containing
the well-known address of the Multicast Agent Group. The IP
time-to-live field is initialized by the sender to 1, in order to
limit the scope of the request to immediate neighbor multicast
agents only. The IP source address field contains the individual
IP address of the sending host.
A Reply message is sent only in response to a Request message.
Its IP destination address field contains the individual address
of the host that sent the corresponding Request. (A Confirm Group
Reply may also be sent to the host group address specified in its
corresponding Confirm Group Request.) The IP source address field
contains the individual IP address of the replying multicast
agent.
When a host sends a new Create Group, Join Group, or Leave Group
Request message, it supplies an arbitrary identifier that it has
not used within the last T0 seconds. (It is usually sufficient
just to increment the identifier for each new request.) The host
initializes a timer to T1 seconds and a retransmission counter to
zero. If a Reply message with a matching identifier is not
received before the timer expires, it is reset to T1 seconds and
the retransmission counter is incremented. If the counter is less
than N1, the host retransmits the Request message with the same
identifier. If the counter equals N1, the host gives up; if the
request was to create or join a group, it is deemed to have
failed; if the request was to leave a group, it is deemed to have
succeeded.
If a "request pending" code is received in a matching reply to a
Create Group, Join Group, or Leave Group Request, the timer is
reset to the number of seconds specified by the code and the
retransmission counter is reset to zero. The new timer value
applies to one timeout interval only -- if the timer expires, it
is reset to T1 seconds, the counter is incremented, and the
request is retransmitted.
The first matching Reply to a Create Group, Join Group, or Leave
Group Request containing a "request granted" or "request denied"
code determines the outcome of the request. Any subsequent or
Deering [Page 16]
RFC 988 July 1986
Host Extensions for IP Multicasting
non-matching Replies are discarded by the host. However, if a
host receives an affirmative Create Group Reply or Join Group
Reply that neither matches an outstanding Request nor contains the
address of a group to which the host belongs, the host should
immediately send a Leave Group Request for the unexpected group
address.
A "request granted" reply to a Create Group Request implies that,
as well as the group being created, the requesting host is granted
membership in the group, i.e. there is no need to send a separate
Join Group Request.
Confirm Group Request messages must be sent periodically by hosts
to inform the neighboring multicast agent(s) of the hosts'
continuing membership in the specified groups. If an agent does
not receive a Confirm Group Request message for a particular group
within an agent-defined interval, it stops delivering datagrams
destined to that group.
For each group to which it belongs, a host maintains a
confirmation timer and a variable t. The variable t is
initialized to T2 seconds. Whenever the host's request to create
or join a group is granted, and whenever the host either sends a
Confirm Group Request or receives a Confirm Group Reply with a
"request granted" code for the group, the host sets the group's
timer to a random number uniformly distributed between t and t +
T3 seconds. If the host receives a a Confirm Group Reply with a
"request pending" code, t is changed to the value of the code and
the timer is reset to a random number between the new t and t +
T3. The variable t retains its value until another "request
pending" code is received. Whenever the timer expires, the host
sends a Confirm Group Request.
Even if a host fails to receive Confirm Group Replies to its
Requests, it continues to consider itself a member of the group,
because it may still be able to receive multicast datagrams from
other hosts on the same local network. Only if a host receives a
"request denied" code in a Confirm Group Reply does it stop
sending Confirm Group Requests and consider its membership to be
revoked.
Multicast agents respond to Confirm Group Request messages by
sending Confirm Group Reply messages either to the individual
sender of the Request or to the host group address specified in
the Request. By sending back a Confirm Group Reply to all
neighboring members of a group, a multicast agent is able to reset
every member's timer with a single packet. The randomization of
Deering [Page 17]
RFC 988 July 1986
Host Extensions for IP Multicasting
the timers is intended to cause only the one member whose timer
expires first to send a Confirm Group Request, stimulating a Reply
to reset all the timers. The use of the "request pending" codes
allows the multicast agent to control the rate at which it
receives Confirm Group Requests.
Protocol Timing Constants
The following timing constants are specified for IGMP. They are
subject to change as a result of operational experience.
T0 = 300 seconds minimum recycle time for identifiers
T1 = 2 seconds retrans. interval for Create/Join/Leave Requests
N1 = 5 tries retrans. limit for Create/Join/Leave Requests
T2 = 15 seconds initial value for Confirm Request variable t
T3 = 15 seconds random range for Confirm Request variable t
Deering [Page 18]
RFC 988 July 1986
Host Extensions for IP Multicasting
APPENDIX II. HOST GROUP ADDRESS ISSUES
This appendix is not part of the IP multicasting specification, but
provides background discussion of several issues related to IP host
group addresses.
Group Address Binding
The binding of IP host group addresses to physical hosts may be
considered a generalization of the binding of IP unicast
addresses. An IP unicast address is statically bound to a single
local network interface on a single IP network. An IP host group
address is dynamically bound to a set of local network interfaces
on a set of IP networks.
It is important to understand that an IP host group address is NOT
bound to a set of IP unicast addresses. The multicast agents do
not need to maintain a list of individual members of each host
group. For example, a multicast agent 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.
Group Addresses as Logical Addresses
Host group addresses have been defined specifically for use in the
destination address field of multicast IP datagrams. However, the
fact that group addresses are location-independent (they are not
statically bound to a single network interface) suggests possible
uses as more general "logical addresses", both in the source as
well as the destination address field of datagrams. For example,
a mobile IP host might have a host group address as its only
identity, used as the source of datagrams it sends. Whenever the
mobile host moved from one network to another, it would join its
own group on the new network and depart from the group on the old
network. Other hosts communicating with the mobile one would deal
only with the group address and would be unaware of, and
unaffected by, the changing network location of the mobile host.
Host group addresses cannot, however, be used to solve all
problems of internetwork logical addressing, such as delivery to
the "nearest" or the "least loaded" network interface of a
multi-homed host. Furthermore, there are hazards in using group
addresses in the source address field of datagrams 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
Deering [Page 19]
RFC 988 July 1986
Host Extensions for IP Multicasting
group source address may result in error reports being returned to
all members of the group, not just the sender. In view of these
hazards, this memo specifies the use of host group addresses only
as destinations of datagrams, either in the destination address
field or as the last element of a source routing option. However,
it is recommended that datagrams with a group source address be
accepted without complaint, thereby allowing other implementations
to experiment with logical addressing applications of host group
addresses.
Recycling of Transient Host Group Addresses
Since host group addresses are of fixed, relatively small size,
transient group addresses must be recycled to satisfy continuing
requests for creation of new groups. The multicast agents make an
effort to ensure that a group has no members anywhere in the
internet before allocating its address to a new group. However,
under certain conditions of internetwork partitioning and
membership migration, it is impossible to guarantee unique
allocation of an address without seriously compromising the
availability and robustness of host groups. Furthermore, hosts
that are unaware that a particular group has ceased to exist may
send datagrams to it long after its address has been assigned to a
new group. Therefore, hosts should be prepared for the
possibility of misdelivery of multicast IP datagrams to unintended
hosts, even in private groups. Such misdelivery can only be
detected at a level above IP, using higher-level identifiers or
authentication tokens. (The access key of a private group might
be used in some applications as such an identifier.) Of course,
there are other threats to privacy of communication in the
internet, besides group address collision, such as untrustworthy
gateways or unsecured networks. End-to-end encryption is an
effective defense against such threats.
Deering [Page 20]