RFC 1054:Host Extensions for IP Multicasting
RFC-Ref

9. 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.

9.1. Group Address Binding

   The binding of IP host group addresses to physical hosts may be
   considered a generalization of the binding of IP unicast addresses.
   An IP unicast address is statically bound to a single local network
   interface on a single IP network.  An IP host group address is
   dynamically bound to a set of local network interfaces on a set of IP
   networks.

   It is important to understand that an IP host group address is NOT
   bound to a set of IP unicast addresses.  The multicast routers do not
   need to maintain a list of individual members of each host group.
   For example, a multicast router attached to an Ethernet need
   associate only a single Ethernet multicast address with each host
   group having local members, rather than a list of the members'
   individual IP or Ethernet addresses.

9.2. 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 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 in the IP destination address field.  However, it is
   recommended that datagrams with a group source address, or a group
   address as part of a source routing option, be accepted without
   complaint, thereby allowing other implementations to experiment with
   logical addressing applications of host group addresses.

9.3. Allocation of Transient Host Group Addresses

   This memo does not specify how transient group address are allocated.
   It is anticipated that different portions of the IP transient host
   group address space will be allocated using different techniques.
   For example, there may be a number of servers that can be contacted
   to acquire a new transient group address.  Some higher-level
   protocols (such as VMTP, specified in RFC-1045exp) may generate higher-
   level transient "process group" or "entity group" addresses which are
   then algorithmically mapped to a subset of the IP transient host
   group addresses, similarly to the way that IP host group addresses
   are mapped to Ethernet multicast addresses.  A portion of the IP
   group address space may be set aside for random allocation by
   applications that can tolerate occasional collisions with other
   multicast users, perhaps generating new addresses until a suitably
   "quiet" one is found.

   In general, a host cannot assume that datagrams sent to any host
   group address will reach only the intended hosts, or that datagrams
   received as a member of a transient host group are intended for the
   recipient.  Misdelivery must be detected at a level above IP, using
   higher-level identifiers or authentication tokens.  Information
   transmitted to a host group address should be encrypted or governed
   by administrative routing controls if the sender is concerned about
   unwanted listeners.

Google
Web
RFC-Ref