As per Relevance of the word multicast, we have this rfc below:
Network Working Group S. E.
Request for Comments: 988 Stanford
July 1986
Host Extensions for IP
1. STATUS OF THIS
This memo specifies the extensions required of a host
of the Internet Protocol (IP) to support internetwork multicasting
This specification supersedes that given in RFC-966, and
a proposed protocol standard for IP multicasting in
ARPA-Internet. The reader is directed to RFC-966 for a discussion
the motivation and rationale behind the multicasting
specified here. Distribution of this memo is unlimited
2.
IP multicasting is defined as the transmission of an IP datagram to
"host group", a set of zero or more hosts identified by a single
destination address. A multicast datagram is delivered to
members of its destination host group with the same "best-efforts
reliability as regular unicast IP datagrams, i.e. the datagram is
guaranteed to arrive at all members of the destination group or
the same order relative to other datagrams
The membership of a host group is dynamic; that is, hosts may
and leave groups at any time. There is no restriction on
location or number of members in a host group, but membership in
group may be restricted to only those hosts possessing a
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
well-known, administratively assigned IP address. It is the address
not the membership of the group, that is permanent; at any time
permanent group may have any number of members, even zero.
transient group, on the other hand, is assigned an
dynamically when the group is created, at the request of a host.
transient group ceases to exist, and its address becomes eligible
reassignment, when its membership drops to zero
The creation of transient groups and the maintenance of
membership information is the responsibility of "multicast agents",
entities that reside in internet gateways or other special-
hosts. There is at least one multicast agent directly attached
every IP network or subnetwork that supports IP multicasting. A
requests the creation of new groups, and joins or leaves
groups, by exchanging messages with a neighboring agent
Deering [Page 1]
RFC 988 July 1986
Host Extensions for IP
Multicast agents are also responsible for internetwork delivery
multicast IP datagrams. When sending a multicast IP datagram, a
transmits it to a local network multicast address which
all neighboring members of the destination host group. If the
has members on other networks, a multicast agent becomes
additional recipient of the local multicast and relays the
to agents on each of those other networks, via the internet
system. Finally, the agents on the other networks each transmit
datagram as a local multicast to their own neighboring members of
destination group
This memo specifies the extensions required of a host
implementation to support IP multicasting, where a "host" is
internet host or gateway other than those serving as
agents. The algorithms and protocols used within and
multicast agents are transparent to non-agent hosts and will
specified in a separate document. This memo also does not
how local network multicasting is accomplished for all types
network, although it does specify the required service interface
an arbitrary local network and gives an Ethernet specification as
example. Specifications for other types of network will be
subject of future memos
3. LEVELS OF
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
support IP multicasting. Level 0 hosts will, in general,
unaffected by multicast activity. The only exception arises
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
a class D IP address in their destination address field;
should be quietly discarded by hosts that do not support
multicasting. Class D addresses are defined in section 4 of
memo
Deering [Page 2]
RFC 988 July 1986
Host Extensions for IP
Level 1: support for sending but not receiving multicast
datagrams
Level 1 allows a host to partake of some multicast-based services
such as resource location or status reporting, but it does
allow a host to create or join any host groups. An
implementation may be upgraded from level 0 to level 1 very
and with little new code. Only sections 4, 5, and 6 of this
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,
well as send IP datagrams to host groups. It
implementation of the Internet Group Management Protocol (IGMP
and extension of the IP and local network service
within the host. All of the following sections of this memo
applicable to level 2 implementations
4. HOST GROUP
Host groups are identified by class D IP addresses, i.e. those
"1110" as their high-order four bits. The remaining 28 bits
unstructured as far as hosts are concerned. The addresses
well-known, permanent groups are to be published in "
Numbers". Class E IP addresses, i.e. those with "1111" as
high-order four bits, are reserved for future addressing modes
Appendix II contains some background discussion of several
related to host group addresses
Deering [Page 3]
RFC 988 July 1986
Host Extensions for IP
5. MODEL OF A HOST IP
The multicast extensions to a host IP implementation are specified
terms of the layered model illustrated below. In this model,
and (for level 2 hosts) IGMP are considered to be implemented
the IP module, and the mapping of IP addresses to local
addresses is considered to be the responsibility of local
modules. This model is for expository purposes only, and should
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
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
these services is described in a separate section, below. For
service, extensions are specified for the IP service interface,
IP module, the local network service interface, and an Ethernet
network module. Extensions to local network modules other
Ethernet are mentioned briefly, but are not specified in detail
Deering [Page 4]
RFC 988 July 1986
Host Extensions for IP
6. SENDING MULTICAST IP
6.1. Extensions to the IP Service
No change to the IP service interface is required to support
sending of multicast IP datagrams. An upper-layer protocol
merely specifies an IP host group destination, rather than
individual IP destination, when it invokes the existing "Send IP
operation
6.2. Extensions to the IP
To support the sending of multicast IP datagrams, the IP
must be extended to recognize IP host group addresses when
outgoing datagrams. Most IP implementations include the
logic
if IP-destination is on the same local network
send datagram locally to IP-
send datagram locally to GatewayTo(IP-destination
To allow multicast transmissions, the routing logic must
changed to
if IP-destination is on the same local
or IP-destination is a host group
send datagram locally to IP-
send datagram locally to GatewayTo(IP-destination
If the sending host is itself a member of the destination group,
copy of the outgoing datagram must be looped-back for
delivery if and only if loopback was requested when the
joined the group (see section 8.1). (This issue does not arise
level 1 implementations.)
On hosts attached to more than one network, each multicast
datagram must be transmitted via one network interface only
leaving it to the multicast agents to effect delivery to any
required networks
A host group address should not be placed in the source
field of an outgoing IP datagram. A host group address may
used in a source routing option as the last element only
It should be noted that a small IP time-to-live (TTL) value
Deering [Page 5]
RFC 988 July 1986
Host Extensions for IP
prevent delivery to some members of a destination group. Thus,
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-
local area networks, the TTL field acts as a hop limit; thus,
can perform expanding-ring searches by starting with a TTL of 1
and incrementing on each retransmission, up to some limit
by the diameter of the cluster
6.3. Extensions to the Local Network Service
No change to the local network service interface is required
support the sending of multicast IP datagrams. The IP
merely specifies an IP host group destination, rather than
individual IP destination, when it invokes the existing "
Local" operation
6.4. Extensions to an Ethernet Local Network
The Ethernet directly supports the sending of local
packets by allowing multicast addresses in the destination
of Ethernet packets. All that is needed to support the sending
multicast IP datagrams is a procedure for mapping IP host
addresses to Ethernet multicast addresses
An IP host group address is mapped to an Ethernet
address by placing the low-order 28-bits of the IP address
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
published in "Assigned Numbers".
[At time of publication of this memo, a block of
multicast addresses with 28 unspecified bits had not yet
obtained from the allocating authority. If such a block
addresses cannot be obtained, an alternative mapping scheme
be specified.]
6.5. Extensions to Local Network Modules other than
Other networks that directly support multicasting, such as
or buses conforming to the IEEE 802.2 standard, can be handled
same way as Ethernet for the purpose of sending multicast
datagrams. For a network that supports broadcast but
multicast, such as the Experimental Ethernet, all IP host
addresses can be mapped to a single local broadcast address (
the cost of increased overhead on all local hosts). For
point-to-point networks like the ARPANET or a public data
Deering [Page 6]
RFC 988 July 1986
Host Extensions for IP
(X.25), all IP host group addresses might be mapped to
well-known local address of an IP multicast agent; an agent
such a network would take responsibility for completing
delivery within the network as well as among networks
7. RECEIVING MULTICAST IP
7.1. Extensions to the IP Service
No change to the IP service interface is required to support
reception of multicast IP datagrams. Incoming multicast
datagrams are delivered to upper-layer protocol modules using
same "Receive IP" operation as normal, unicast datagrams
7.2. Extensions to the IP
To support the reception of multicast IP datagrams, the IP
must be extended to recognize the addresses of IP host groups
which the host currently belongs, in addition to the host'
individual IP address(es). An incoming datagram destined to
of those group addresses is processed exactly the same way
datagrams destined to one of the host's individual addresses
Incoming datagrams destined to groups to which the host does
belong are discarded without generating any error report
On hosts attached to more than one network, if a datagram
via one network interface, destined for a group to which the
belongs only on a different interface, the datagram is
discarded. (This should occur only as a result of
multicast address filtering in the local network module.)
An incoming datagram is not rejected for having an IP host
address in its source address field or anywhere in a
routing option
An ICMP error message (Destination Unreachable, Time Exceeded
Parameter Problem, Source Quench, or Redirect) is never
in response to a datagram destined to an IP host group
7.3. Extensions to the Local Network Service
No change to the local network service interface is required
support the reception of multicast IP datagrams. Incoming
network packets, whether multicast or unicast, are delivered
the IP module using the same "Receive Local" operation
Deering [Page 7]
RFC 988 July 1986
Host Extensions for IP
7.4. Extensions to an Ethernet Local Network
To support the reception of multicast IP datagrams, an
module must be able to receive packets addressed to the
multicast addresses that correspond to the host's IP host
addresses. It is highly desirable to take advantage of
address filtering capabilities that the Ethernet
interface may have, so that the host only receives packets
are destined to it
Unfortunately, many current Ethernet interfaces have a small
on the number of addresses that the hardware can be configured
recognize. However, an implementation must be capable
listening on an arbitrary number of Ethernet multicast addresses
which may mean "opening up" the address filter to accept
multicast packets during those periods when the number
addresses exceeds the limit of the filter
For interfaces with inadequate hardware address filtering, it
be desirable (for performance reasons) to perform Ethernet
filtering within the software of the Ethernet module. This is
mandatory, however, because the IP module performs its
filtering based on IP destination addresses
7.5. Extensions to Local Network Modules other than
Other multicast networks, such as IEEE 802.2 networks, can
handled the same way as Ethernet for the purpose of
multicast IP datagrams. For pure broadcast networks, such as
Experimental Ethernet, all incoming broadcast packets can
accepted and passed to the IP module for IP-level filtering. On
point-to-point network, multicast IP datagrams will arrive
local network unicasts, so no change to the local network
should be necessary
Deering [Page 8]
RFC 988 July 1986
Host Extensions for IP
8. MANAGING GROUP
8.1. Extensions to the IP Service
To allow upper-layer protocol modules to request that their
create, join, or leave a host group, the IP service interface
be extended to offer the following three new operations
CreateGroup ( private, loopback )
--> outcome, group-address, access-
The CreateGroup operation requests the creation of a new
transient host group, with this host as its only member.
"private" argument specifies if the group is to be private
public. The "loopback" argument specifies whether or
datagrams sent from this host to the group should be
locally as well as to other member hosts. The "outcome"
indicates whether the request is granted or denied. If it
granted, a new 32-bit IP host group address is returned,
with a 64-bit access key which is zero for public groups
non-zero for private groups. The request may be denied due
lack of response from a multicast agent, or lack of resources
JoinGroup ( group-address, access-key, loopback ) -->
The JoinGroup operation requests that this host become a member
the host group identified by "group-address", with the
access key. The "loopback" argument specifies whether or
datagrams sent from this host to the group should be
locally as well as to other member hosts. The "outcome"
indicates whether the request is granted or denied. The
may be denied due to lack of response from a multicast agent,
of resources, an invalid group address, an incorrect access key
or already being a member
LeaveGroup ( group-address, access-key ) -->
The LeaveGroup operation requests that this host give up
membership in the host group identified by "group-address",
the specified access key. The "outcome" result indicates
the request is granted or denied. The request may be denied
to an invalid group address, an incorrect access key, or
currently being a member
Each of these operations may take up to a minute or more
complete, depending on the number of IGMP
Deering [Page 9]
RFC 988 July 1986
Host Extensions for IP
performed within the IP module, and time required for a
agent to generate a reply. However, typical delays should be
the order of a few seconds
Besides the LeaveGroup operation, a host loses its membership in
group whenever the host or its IP module crashes, or, in
circumstances, when a multicast agent revokes its membership.
IP service interface should provide some means of informing
upper-layer module when its membership has been revoked
Membership may be revoked due to lack of resources,
of the group address, or the discovery of another host group
the same group address with a different access key. (See
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
multiple processes to invoke JoinGroup operations for the
group as a way of achieving delivery to more than process. The
module delivers each incoming datagram, whether multicast
unicast, to the single upper-layer protocol module identified
the protocol field in the datagram's IP header; it is
upper-layer issue whether or not to deliver incoming datagrams
more than one process, perhaps using the concept of "
groups" or "shared ports".
8.2. Extensions to the IP
Within the IP module, the membership management operations
supported by the Internet Group Management Protocol (IGMP),
specified in Appendix I. As well as having messages
to each of the operations specified above, IGMP also specifies
"deadman timer" procedure whereby hosts periodically confirm
memberships with the multicast agents
The IP module must maintain a data structure listing the
addresses of all host groups to which the host currently belongs
along with each group's loopback policy, access key, and
variables. This data structure is used by the IP
transmission service to know which outgoing datagrams to
back, and by the reception service to know which
datagrams to accept. The purpose of IGMP and the
interface operations is to maintain this data structure
On hosts attached to more than one network, each membership
associated with a particular network interface. On such a
the management interface operations above may each require
additional parameter specifying to which interface the create
Deering [Page 10]
RFC 988 July 1986
Host Extensions for IP
join, or leave request applies. The group membership
structure must also be extended to associate an interface
each membership. If a host joins the same host group on more
one network interface, it can expect to receive multiple copies
each datagram sent to that group
8.3. Extensions to the Local Network Service
To allow an IP module to control what packets should be
by the local network module, it is necessary to extend the
network service interface with the following two new operations
AcceptAddress ( group-address )
RejectAddress ( group-address )
where "group-address" is an IP host group address.
AcceptAddress operation requests the local network module
accept and deliver up subsequently arriving packets destined
the local network address corresponding to "group-address".
RejectAddress operation requests the local network module to
delivering up packets destined to the local network
corresponding to "group-address".
Any local network module is free to ignore RejectAddress requests
and may deliver up packets destined to more addresses than
those specified in AcceptAddress requests, if it is unable
filter incoming packets adequately
8.4. Extensions to an Ethernet Local Network
An Ethernet module responds to AcceptAddress operations by
the corresponding Ethernet multicast address to its
filter for incoming packets. A RejectAddress operation causes
corresponding Ethernet address to be dropped from the filter.
Ethernet interfaces with a limit on the number of addresses
can be added to the filter, the Ethernet software module
detect when that threshold is exceeded and open up the filter
accept all multicast packets. It should also detect when
number of addresses drops below the threshold and revert
individual address filtering
8.5. Extensions to Local Network Modules other than
Other multicast networks, such as IEEE 802.2 networks, can
handled the same way as Ethernet for the purpose of
address filtering. For a pure broadcast network or
Deering [Page 11]
RFC 988 July 1986
Host Extensions for IP
point-to-point network, the AcceptAddress and
operations may have no effect; all incoming packets could
passed to the IP module for IP-level filtering
Deering [Page 12]
RFC 988 July 1986
Host Extensions for IP
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP
The Internet Group Management Protocol (IGMP) is used between
hosts and their immediate neighbor multicast agents to support
creation of transient groups, the addition and deletion of members
a group, and the periodic confirmation of group membership. IGMP
an asymmetric protocol and is specified here from the point of
of a host, rather than a multicast agent
Like ICMP, IGMP is a integral part of IP. It is required to
implemented in full by all hosts conforming to level 2 of the
multicasting specification. IGMP messages are encapsulated in
datagrams, with an IP protocol number of 2. All IGMP messages
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are eight types of IGMP message
1 = Create Group
2 = Create Group
3 = Join Group
4 = Join Group
5 = Leave Group
6 = Leave Group
7 = Confirm Group
8 = Confirm Group
Deering [Page 13]
RFC 988 July 1986
Host Extensions for IP
In a Create Group Request message, the code field indicates if
new host group is to be public or private
0 =
1 =
In all other Request messages, the code field contains zero
In a Reply message, the Code field specifies the outcome of
request
0 = request
1 = request denied, no
2 = request denied, invalid
3 = request denied, invalid group
4 = request denied, invalid access
5 - 255 = request pending, retry in this many
The checksum is the 16-bit one's complement of the one'
complement sum of the IGMP message starting with the IGMP Type
For computing the checksum, the checksum field should be zero
In a Confirm Group Request message, the identifier field
zero
In all other Request messages, the identifier field contains
value to distinguish the request from other requests by the
host
In a Reply message, the identifier field contains the same
as in the corresponding Request message
Deering [Page 14]
RFC 988 July 1986
Host Extensions for IP
Group
In a Create Group Request message, the group address
contains zero
In all other Request messages, the group address field contains
host group address
In a Create Group Reply message, the group address field
either a newly allocated host group address (if the request
granted) or zero (if denied).
In all other Reply messages, the group address field contains
same host group address as in the corresponding Request message
Access
In a Create Group Request message, the access key field
zero
In all other Request messages, the access key field contains
access key assigned to the host group identified in the
Address field (zero for public groups).
In a Create Group Reply message, the access key field
either a non-zero 64-bit number (if the request for a
group is granted) or zero
In all other Reply messages, the access key field contains
same access key as in the corresponding Request
Deering [Page 15]
RFC 988 July 1986
Host Extensions for IP
Protocol
Request messages are sent only by hosts. Reply messages are
only by multicast agents. If a host receives an IGMP message of
type other than the four Reply types specified above, the
is discarded
A Request message is sent with its IP destination field
the well-known address of the Multicast Agent Group. The
time-to-live field is initialized by the sender to 1, in order
limit the scope of the request to immediate neighbor
agents only. The IP source address field contains the
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
of the host that sent the corresponding Request. (A Confirm
Reply may also be sent to the host group address specified in
corresponding Confirm Group Request.) The IP source address
contains the individual IP address of the replying
agent
When a host sends a new Create Group, Join Group, or Leave
Request message, it supplies an arbitrary identifier that it
not used within the last T0 seconds. (It is usually
just to increment the identifier for each new request.) The
initializes a timer to T1 seconds and a retransmission counter
zero. If a Reply message with a matching identifier is
received before the timer expires, it is reset to T1 seconds
the retransmission counter is incremented. If the counter is
than N1, the host retransmits the Request message with the
identifier. If the counter equals N1, the host gives up; if
request was to create or join a group, it is deemed to
failed; if the request was to leave a group, it is deemed to
succeeded
If a "request pending" code is received in a matching reply to
Create Group, Join Group, or Leave Group Request, the timer
reset to the number of seconds specified by the code and
retransmission counter is reset to zero. The new timer
applies to one timeout interval only -- if the timer expires,
is reset to T1 seconds, the counter is incremented, and
request is retransmitted
The first matching Reply to a Create Group, Join Group, or
Group Request containing a "request granted" or "request denied
code determines the outcome of the request. Any subsequent
Deering [Page 16]
RFC 988 July 1986
Host Extensions for IP
non-matching Replies are discarded by the host. However, if
host receives an affirmative Create Group Reply or Join
Reply that neither matches an outstanding Request nor contains
address of a group to which the host belongs, the host
immediately send a Leave Group Request for the unexpected
address
A "request granted" reply to a Create Group Request implies that
as well as the group being created, the requesting host is
membership in the group, i.e. there is no need to send a
Join Group Request
Confirm Group Request messages must be sent periodically by
to inform the neighboring multicast agent(s) of the hosts
continuing membership in the specified groups. If an agent
not receive a Confirm Group Request message for a particular
within an agent-defined interval, it stops delivering
destined to that group
For each group to which it belongs, a host maintains
confirmation timer and a variable t. The variable t
initialized to T2 seconds. Whenever the host's request to
or join a group is granted, and whenever the host either sends
Confirm Group Request or receives a Confirm Group Reply with
"request granted" code for the group, the host sets the group'
timer to a random number uniformly distributed between t and t +
T3 seconds. If the host receives a a Confirm Group Reply with
"request pending" code, t is changed to the value of the code
the timer is reset to a random number between the new t and t +
T3. The variable t retains its value until another "
pending" code is received. Whenever the timer expires, the
sends a Confirm Group Request
Even if a host fails to receive Confirm Group Replies to
Requests, it continues to consider itself a member of the group
because it may still be able to receive multicast datagrams
other hosts on the same local network. Only if a host receives
"request denied" code in a Confirm Group Reply does it
sending Confirm Group Requests and consider its membership to
revoked
Multicast agents respond to Confirm Group Request messages
sending Confirm Group Reply messages either to the
sender of the Request or to the host group address specified
the Request. By sending back a Confirm Group Reply to
neighboring members of a group, a multicast agent is able to
every member's timer with a single packet. The randomization
Deering [Page 17]
RFC 988 July 1986
Host Extensions for IP
the timers is intended to cause only the one member whose
expires first to send a Confirm Group Request, stimulating a
to reset all the timers. The use of the "request pending"
allows the multicast agent to control the rate at which
receives Confirm Group Requests
Protocol Timing
The following timing constants are specified for IGMP. They
subject to change as a result of operational experience
T0 = 300 seconds minimum recycle time for
T1 = 2 seconds retrans. interval for Create/Join/Leave
N1 = 5 tries retrans. limit for Create/Join/Leave
T2 = 15 seconds initial value for Confirm Request variable
T3 = 15 seconds random range for Confirm Request variable
Deering [Page 18]
RFC 988 July 1986
Host Extensions for IP
APPENDIX II. HOST GROUP ADDRESS
This appendix is not part of the IP multicasting specification,
provides background discussion of several issues related to IP
group addresses
Group Address
The binding of IP host group addresses to physical hosts may
considered a generalization of the binding of IP
addresses. An IP unicast address is statically bound to a
local network interface on a single IP network. An IP host
address is dynamically bound to a set of local network
on a set of IP networks
It is important to understand that an IP host group address is
bound to a set of IP unicast addresses. The multicast agents
not need to maintain a list of individual members of each
group. For example, a multicast agent attached to an
need associate only a single Ethernet multicast address with
host group having local members, rather than a list of
members' individual IP or Ethernet addresses
Group Addresses as Logical
Host group addresses have been defined specifically for use in
destination address field of multicast IP datagrams. However,
fact that group addresses are location-independent (they are
statically bound to a single network interface) suggests
uses as more general "logical addresses", both in the source
well as the destination address field of datagrams. For example
a mobile IP host might have a host group address as its
identity, used as the source of datagrams it sends. Whenever
mobile host moved from one network to another, it would join
own group on the new network and depart from the group on the
network. Other hosts communicating with the mobile one would
only with the group address and would be unaware of,
unaffected by, the changing network location of the mobile host
Host group addresses cannot, however, be used to solve
problems of internetwork logical addressing, such as delivery
the "nearest" or the "least loaded" network interface of
multi-homed host. Furthermore, there are hazards in using
addresses in the source address field of datagrams when the
actually contains more than one host. For instance, the
datagram reassembly algorithm relies on every host using
different source address. Also, errors in a datagram sent with
Deering [Page 19]
RFC 988 July 1986
Host Extensions for IP
group source address may result in error reports being returned
all members of the group, not just the sender. In view of
hazards, this memo specifies the use of host group addresses
as destinations of datagrams, either in the destination
field or as the last element of a source routing option. However
it is recommended that datagrams with a group source address
accepted without complaint, thereby allowing other
to experiment with logical addressing applications of host
addresses
Recycling of Transient Host Group
Since host group addresses are of fixed, relatively small size
transient group addresses must be recycled to satisfy
requests for creation of new groups. The multicast agents make
effort to ensure that a group has no members anywhere in
internet before allocating its address to a new group. However
under certain conditions of internetwork partitioning
membership migration, it is impossible to guarantee
allocation of an address without seriously compromising
availability and robustness of host groups. Furthermore,
that are unaware that a particular group has ceased to exist
send datagrams to it long after its address has been assigned to
new group. Therefore, hosts should be prepared for
possibility of misdelivery of multicast IP datagrams to
hosts, even in private groups. Such misdelivery can only
detected at a level above IP, using higher-level identifiers
authentication tokens. (The access key of a private group
be used in some applications as such an identifier.) Of course
there are other threats to privacy of communication in
internet, besides group address collision, such as
gateways or unsecured networks. End-to-end encryption is
effective defense against such threats
Deering [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
