Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: 15222775 @ 61. (15222775 @ 61. Hbzzx2001@yahoo.com.cn)
Translation time: 2002-3-27
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
Network Working Group S. E. Deering
Request for Comments: 988 Stanford University
July 1986
IP multi-point broadcast host extension
⒈ memo status
This memorand shows the extension required to support interconnect network multipoint broadcasts.
This specification replaces the IP multipoint broadcasts in the ARPA Internet of RFC - 966, which makes it a proposed protocol standard. RFC - 966 details the basic principles and motivations of multipoint broadcast extensions described herein. The distribution of this memorandum is not limited.
⒉ ⒉ ⒉
IP multi-point broadcast is defined as a transmission of IP datagrams to "Host Group", "Host Group" composed of zero or more hosts, is identified by a single IP destination address. A multi-played datagram is delivered to all members of the target host group, with the same "" Try "security, which means that the data is not guaranteed to meet the destination group. All members or non-additional datagrams have the same order.
The number of members of the host group is dynamic; that is, the host can participate and leave the group at any time. There is no limit to the number or location of members in the host group, but members are limited to hosts with dedicated access keys. A host may be a member of multiple groups at the same time.
A host does not have to be a member of a group to send it a datagram.
The host group may be permanently or temporarily. The permanent group has a well known, government-assigned IP address. It is address, non-group members, that is, permanent; any time, a permanent community may have many members, and may even have zero members. On the other hand, a temporary group is dynamically assigned an address when creating a host's request. When its members fell to zero, the temporary group is to disband, its address can be reassigned.
The creation of group membership temporary groups and maintenance of the identity information of the group employees is the responsibility of "Multi-Dream Agent" (existing in the Internet gateway or other dedicated entity). At least one multi-player agent is directly connected to each IP network or subnet that supports IP multipoint broadcasts. The host requests new group groups to participate in or leave the existing group.
Multi-playback proxy also undertakes the interconnect network transportation of multi-playback IP datagram. When sending a multi-point broadcast IP datagram, the host transmits it to a local area multiparty address there, which addresses identifies all neighboring machines of the destination master group. If the group has a member of other networks, a multi-point broadcast agent becomes a local multipoint auxiliary receiver and relays the data to other networks through the Internet access system relay. Finally, another network agent puts the datagram as a local multi-point broadcast to the neighbor member of the destination group.
This memo description has an extension required for host IP implementations to IP multipoint broadcast support, and "Host" here is any Internet host or gateway instead of a machine that acts as a multi-player agent. The algorithms and protocols used between multipoint broadcast proxy and protocols are transparent to non-proxy hosts, and in detail in a separate document. This memorando has not specified how the LAN's multi-point broadcast is completed, although it specifies the service interface necessary for an arbitrary local area network and Ethernet and the specification as an example. The specifications of other types of networks may be a topic for future memo.
⒊ consistent level
There are three-level consistency of this specification: 0 level: IP multi-point broadcast is not supported.
There is no IP implementation that supports IP multi-point broadcast at this time. The 0-level host is usually not affected by multi-playback efficiency. The only exception happens on some types of local area networks, where the level 1 or level 2 host may cause multicast IP data to report to the 0-level host host. Such a dataset can easily recognize the D class IP address in their destination address fields; hosts that do not support IP multi-point broadcasts should drop them. The D address is defined in the 4-section of this memo.
Level 1: Supports sending and does not support accepting multi-point broadcast IP datagrams.
Level 1 allows hosts to participate in some multi-point broadcast services, such as resource positioning or status reports, but not a host created or participated in any host group. IP implementations may easily upgrade from the 0-level host to level 1 and only a small amount of new code. The 4, 5th, 6 sections of this memo can be applied to level 1 implementation.
Level 2: Full support for IP multi-point broadcasting.
Level 2 allows a host to create, participate, and leave the host group, and send IP datagrams to the host group. It requires IGMP in the host to extend IGMP and extend IP and LAN service interfaces. All parts of this memo can be applied to implementation level 2.
⒋ host group address
The high four-bit byte of the host group can be recognized by the D IP address, that is, the D class IP address is "1110" as its high four-bit byte. The remaining 28 unlaminated until the host cares about them. The address of the famous permanent group will be published in the Assignment Number. The E class IP address is to use "1111" as the IP address of their high four-bit bytes for future addressing methods.
Appendix II contains certain background knowledge, detailing several dispute points related to the host group address.
IP multi-point broadcast host extension
5. Model implemented by a host IP
Multi-playback implementation of the extended host IP as shown below: In this model, the Internet Bill Report Control Protocol and (for Level 2 Host) IGMP are considered to be implemented inside the IP module, and IP address to the local network address The mapping is considered to be the responsibility of the local area network module. This model is for illustrative purposes only, but it should not be regarded as 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 multipoint broadcasts, host IP implementation must provide three new services: (1) Send multi-playback IP datagram, (2) receive multi-playback IP datagram, and (3) management team membership.
Level 1 host only needs to provide the first service. Each service is described below with a separate partial description. Each service has specified some extensions for IP service interfaces, IP modules, local area network service interfaces, and Ethernet local area network modules. For the LAN module instead of the expansion part of the Ethernet LAN Module, it is not shown in detail.
⒍ Send multi-playback IP datagram
6.1. For the expansion part of the IP service interface
A modification is required for sending IP service interfaces that support multi-play IP datagram. When it enables the existing "Send IP" operation, the upper protocol module only specifies an IP host group destination, not a personal IP destination,.
6.2. For the expansion part of the IP module
To support the transmission of multi-play IP datagrams, the IP module must be extended to distinguish the IP host group address when the route output data is reported. Most IP implementations include the following:
If the IP destination is on the same LAN, send data to local IP - destinations, other send data to local GatewayTo (IP destination)
To accommodate multiple access, the path selection logic must become:
The IP destination is a host group on the same LAN or the IP destination. Send data to the local IP - destination, otherwise send data to the local GatewayTo (IP destination)
If the sending host is a member of the destination itself, the backup of the output datagram must be loop back to local transport, and when the host is sent (see section 8.1). (This problem did not appear in Level 1 implementation.)
On the host connected to more than one network, each multi-playback IP datagram must be transmitted only by a network interface, leaving it to multi-point broadcast proxy until you deliver to any other network.
The host group address should not be in a source address field that outputs an IP datagram. Host group addresses may be used for source routing options.
People noted a small IP survival time (TTL) value
Prevent some members of the delivery to a destination group. Therefore, a huge TTL value should be used to reach all members. Conversely, a small TTL value can be used to reach the "vicinity" member that is widely distributed. The TTL domain is limited in the small delayed local area network cluster; therefore, the extended ring survey can be completed: TTL begins to 1 and additional additional 1 until the limit is defined by the cluster.
6.3. For the expansion part of the local area network service interface
To support the sending LAN service interface of multi-play IP datagram, no modification is required. When it enables the existing "Send Local" operation, the IP module only specifies an IP host group destination, not a personal IP destination,.
6.4. For the expansion part of the Ethernet LAN Module
The Ethernet can directly support the transmission of local multi-point broadcast packages by allowing the destination area of the Ethernet packet. To support the transmission of multi-play IP datagrams, a way to map the IP host group address to the Ethernet multipoint broadcast address.
The IP host group address is mapped to an Ethernet multipoint broadcast address by placing the low 28 bits of an IP address. The high 20 digits of the Ethernet address are set to a famous value published in the "Assigned Numbers").
When publishing this memo, the Ethernet multipoint broadcast address block with 28 unspecified bit has not been obtained from the allocation power mechanism. If such an address block cannot be obtained, a replacement map may be specified.
6.5. For the LAN module instead of an extension of Ethernet
In order to send multi-playback IP datagram, other networks that directly support multi-point broadcasts, such as ring or bus type networks that meet the IEEE 802.2 standard, can be handled as equally. For networks supporting broadcast rather than multi-player networks, such as experimental Ethernet, all IP host group addresses can be mapped to a single local broadcast address (at the expense of all local host overhead). Point-to-point network like ARPANET or public data network
(X.25), all IP host group addresses may be mapped to a local address of one of the IP multi-playback proxy; a proxy on such a network is responsible for completing multi-play delivery between the network and between networks.
⒎ Receive a multi-point broadcast IP datagram
7.1. For the expansion of the IP service interface
Receiving an IP service interface for supporting multi-play IP datagrams does not need to make changes. With the same operation as the normal "Receive IP" (single transfer datagram), the incoming multipoint broadcast IP datagram is delivered to the upper layer protocol module.
7.2. Extension of IP module
In order to support the reception of multi-playback IP datagram, the IP module must be extended to make it except that the host's dedicated IP address can recognize the address of the IP host group to which the host belongs to the host will be used to go to one of those group addresses. In-hours data reports and the data newspapers that handle one of the private addresses in the host.
The incoming datagram to the group to which the host belongs to the host is discarded, and no report on the error is generated.
Regarding the host connected to more than one network, if a datagon arrives at a network interface, the group to which the host belongs to the host is on a different interface, which is silently discarded. (This will only happen only if the local area network module lacks a multi-player address filtering.)
Where its source address field or where the IP host group address has an IP host group address is not rejected.
ICMP error packets (destination are not arrival, time beyond, parameter issues, source off or redirection) never caused by a datagram to IP host groups.
7.3. For the expansion part of the local area network service interface
Receiving a multi-player network service interface does not need to make a modification. In the Office of the LAN, no matter the multi-play or single transmission, it is delivered to the IP module with "Receive Local".
IP multi-point broadcast host extension
7.4. Extension of the Ethernet LAN Module
In order to support the reception of multi-play IP datagram, an Ethernet module must be able to receive a package issued to the Ethernet multipoint broadcast address, which corresponds to the host's IP host group address. Any address filter capability (Ethernet hardware interface may have) is very hoped, so the host only receives those packages to it.
Unfortunately, there are only one small restriction on the number of addresses that the Ethernet interface to hardware can identify. However, an implementation must be able to listen to any number of Ethernet multipoint broadcast addresses, which may mean that all accept multi-play package open address filters during the number of addresses of the address.
The lack of those interfaces of the machine address filter may wish to complete the Ethernet address filtering within the software of the Ethernet module. However, this is not mandatory because the IP module performs its own filtering according to the IP destination address.
7.5. For the LAN module instead of an extension of Ethernet
In order to receive multicast IP datagram, other networks that directly support multi-point broadcasts are, for example, in line with the IEEE 802.2 network, to receive multi-playback IP datagrams can be handled with Ethernet. For pure broadcast, such as experimental Ethernet, all incoming broadcast packets are accepted and then transmitted to the IP module for IP level filtration. On a point-to-point network, multi-playback IP datagrans may be transferred as a local area network, so there is no need to change the local area network module.
⒏ Management teamwork identity
8.1.78.1. Extensions for IP service interfaces
In order to let the upper protocol module require their host to create, participate, or leave a host group, IP service interface must be extended to provide the following three new operations:
CreateGroup (Private, LoopBack)
-> Outcome, Group-Address, Access-Key
The CreateGroup operation requests a new, temporary host group, only this host as its member. This "Private" parameter specifies that the group will be private or public. The "Loopback" parameter specifies whether or not the datagram that is from this group to the group should be partially other members. Communicate to the "OUTCOME" means that the request is allowed or rejected. If it is allowed, return a new 32-bit IP host group address, and a 64-bit reel keyword, zero is a public group and non-zero as private group. The request may be rejected, due to the lack of resources from a multi-point broadcast agent, or lack of resources.
JOINGROUP (Group-Address, Access-Key, Loopback) -> Outcome
The JOINGROUP operation requires this host to become a member of the host group through "Group Address", has a prescribed access key. The "Loopback" parameter specifies whether or not the datagram that is from this group to the group should be partially other members. Communicate to the "OUTCOME" means that the request is allowed or rejected. Due to lack of a multi-player response, a lack of resources, an illegal group address, an error access keyword or is a member, which may be rejected.
Leavegroup (Group-address, access-key) -> OUTCOME
The LeaveGroup operation requires this host to abandon the eligibility of the host group to identify a member of the "group address", with a prescribed access key. "OUTCOME" means that the request is allowed or rejected. Due to lack of a multi-player response, a lack of resources, an illegal group address, an error access keyword or the current is not a member, which may be rejected.
Each of these operations may occupy more than a minute, depending on the number of IGMP retransmission
Execute inside the IP module, multi-playback proxy generates a time for answering needs. However, the standard delay should be around a few seconds.
In addition to LeaveGroup operation, whenever a host or its IP module crashes, or in a rare scene - When a multi-player agent withdraws its member, the host loses its qualification in a group. When its membership has been withdrawn, the IP service interface will provide some methods to notify the upper module.
Membership may be withdrawn due to lack of resource, group address storage unit allocation, or discovery that another host group has the same group address with a different access key. (See Appendix II, the address recovery problem is detailed.)
Note that IP group members are PER-Host (per host) instead of Per - processs, it is important. An IP service interface should not make multiple processes to enable JOINGROUP operations for the same group as a method IP module that is delivered to multi-process, passing each entry datagram, regardless of multi-play or single transmission, give an upper protocol module, The upper protocol module is recognized by the protocol domain in the IP header of the datagram; whether it passes the incoming data report to multiple processes, it is an upper problem, perhaps you should use "Process Groups" concept or "Shared Ports (Shared entry) "concept.
8.2. Extension of IP module
Interior of the IP module, member qualification Management operations are supported by Internet Group Management Protocol (IGMP), which is specified in Appendix I.. Also make the message corresponding to the operation specified above, IGMP also specifies one
"Deadman Timer" program takes this host regularly confirms their membership with MultiCast Agents.
The IP module must maintain a data structure that lists the IP addresses of all host groups currently belonging to the host, and the return policy of each group, access keywords and time variables. This data structure is used for IP multiple access communication services to find out which output data is reported to feed, and through the receiving service to learn which entry data is accepted. The use of IGMP and management interface is to maintain this data structure. Each member qualification is connected to the specific network interface, connects to the host of more than one network, on this host, each management interface operation above, may require an additional parameter to specify the interface creation,
Participate or leave the request. The identity data structure of the team member must also have to expand to enable each member to linked to an interface. If a host participates in the same host group on more than one network interface, it may expect to receive multiple copies of each datagram sent to that group.
8.3. Extension of the LAN Service Interface
In order to let an IP module control what packages should be accepted through a local area network module, the LAN service interface must be expanded with the following two new operations:
AcceptAddress (Group-Address)
REJECTADDRESS (Group-Address)
Here "Group - Address" is an IP host group address. This. AcceptAddress operations Requirements The local area network module accepts and abandoned those packets that were returned to the local network address with "Group-Address". The RejectAddress operation requires that the local area network module stops transmitting those packets that are from the local network address that are quite for "Group-Address".
The ANY LAN module is free to ignore the RejectAddress request, and may pass to a package that is more addressed than the address specified in the AcceptAddress requirements, if it does not fully filter into the bureau.
8.4. Extension of the Ethernet LAN Module
An Ethernet module can respond to the AcceptAddress operation by adding the corresponding Ethernet multipoint broadcast address to the receiving filtering condition for its incoming package. The REJECTADDRESS operation caused the corresponding Ethernet address from filtering. For Ethernet interfaces that limit the number of addresses that can be added to the filter, when the critical is exceeded the Ethernet software module, it must be listened and opened all of the filtered packages. When the number of the address is reduced to the degree of critical entry, it should also listen and restore a single address filtering.
8.5. Extension of the LAN module instead of Ethernet
In order to control the address filter, other multipoint broadcast networks are, for example, in line with the IEEE 802.2 network, to control the address filter can be processed with Ethernet. For a pure broadcasting network or one
Point-to-point network, the AcceptAddress and RejectAddress operation may be invalid; in order to perform IP-level filtering all incoming packages can be delivered to the IP module.
Appendix I. Internet GROUP Management Protocol (IGMP)
IGMP is used to support temporary groups to generate and delete a group of members between IP hosts and their immediate neighboring multipoint broadcast agents, regularly verifying group membership. IGMP is an asymmetric protocol and herein is described here from a host view rather than a multi-player agent.
Like ICMP (Internet Report Control Protocol), IGMP is an integral part of IP. It requires full implementation through the level 2 IP multipoint broadcast specification corresponding to all hosts. IGMP packets are compressed in IP datagrams, with an IP protocol number 2. All IGMP packets 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
| | |
- - - - - - - - - - - - - - - -
Types of
There are eight IGMP packets:
1 = Creating Group Requirements
2 = Creating Group Answers
3 = Participation requirements
4 = Participation group response
5 = Leaving group requirements
6 = Leaving group response
7 = Confirm Group Requirements
8 = Confirm Group Answer
Code
In a creative group request message, the code field indicates that the new host group will be public or private:
0 = public
1 = private
In all other request messages, the code field contains zero.
In an answer information, the results required by the code field:
0 = request promise
1 = Requirement is rejected, no resources
2 = Requirement is rejected, invalid code
3 = Requirements, invalid group address 4 = Requirement, invalid access keyword
5 - 255 = Requires hang, retry after a few seconds
Check and verify
EGP checksum is 16-bit binary inverse code value in IGMP packets starting from the EGP version IGMP type.
In order to calculate the checksum, the checksum should be zero.
Identifier
In a confirmation group request message, the identifier field contains zero.
In all other request messages, the identifier field contains a value to distinguish other requirements from the other requirements of the same host.
In an answer message
The identifier field contains the same value in the corresponding request message.
Group address
In a group creation request message, the group address field contains zero.
In all other request messages, the group address domain contains a host group address.
In a group Create a response message, a group address domain, or a new specified host group address (if the request is allowed) or contains zero (if rejected).
In all other response packets, the group address domain contains the same host group address as in the corresponding request message.
Access keyword
In a group creation request message, access the keyword field contains zero.
In all other request messages, accessing keywords contains (zero-to-public group) access to the host group (zero for public groups) to access keywords.
In a group Create a reply message, access a keyword domain or contain a non-zero 64 bit number (if a private group is required to be allowed) or contain zero (if rejected).
In all other response packets, access keywords contains the same access to the keywords in the corresponding request.
Agreement rules
The request message is sent only by the host. The response message is sent only by multi-point broadcasting agent. If a host receives a type of IGMP packet other than the four previously specified response types, the message is discarded.
A request message has its IP destination field, which contains the address of the famous multi-player agent group. The IP Survival Time (TTL) domain is initialized by sender 1 to constrain the range of neighboring machine multipoint broadcast agents. The IP source address contains a dedicated IP address for sending hosts.
The response message is sent only when responding to a request message.
The IP destination address field contains private addresses of the host (send the corresponding request). (A group confirmation response may be sent to the host group address specified in its corresponding group confirmation requirements.) The IP source field contains the dedicated IP address of the answer multipoint broadcast agent.
When a host sends a new group creation, group participation, or leave the group request message, it supplies an arbitrary identifier that is not used in the last T0 seconds. (The identifier is added to each new request plus 1.) The host initializes a timer to T1 seconds and initialize a repetitive transmission counter as zero. If a message has a matching identifier, it is not received before the timer expires, which is reset to T1 seconds and the repeated transmission counter plus 1. If the calculator is less than N1, the host repeatedly transmits the request message with the same identifier. If the calculator is equal to N1, the host is discarded; if the request will be created or participated in a group, it is considered to fail; if the request will leave a group, it is considered to be delayed;
If a "requires hang" code is received in a group creation group, the participation group or leave group requires an answer, the timer is reset to the value specified by the code, and the repeated transmission counter is reset to zero. The new timing value is applied only to a time-time interval - if the timer expires, it is reset to T1 second, the counter plus 1, and requires retransmission.
A group creation, group participation, or the first matching answer of the group request contains a "request promise" or "Request to be rejected" code to determine the result of the required. Any later or non-matched response is discarded by the host. However, if a host receives a positive creative group response or participation in group response, they neither match a unresolved request and does not contain the group address to which the host belongs, the host should immediately send a group request to resolve it. Unexpected group address.
A "Request granted" answered a creating group request, hint, and groups are being created, the requesting host agreed to have member qualifications in this group, that is to say that a separate participation group request is not required.
The group confirmation requirement must be sent regularly by the host to inform the host's extended member qualification in the prescribed group to give a multi-point broadcast agent. If an agent does not receive a group confirmation request message from a specific group within the time interval defined in a proxy, it stops passing the datagram to that group. For each group to which it belongs, the host maintains a confirmation timer and a variable T. The variable T initializes T2 seconds. Whenever the host creates a group request, or each host sends a group confirmation request or receive a group confirmation response, the group confirmed or received a group confirmation response has one
The "request promise" code of this group sets the timer of the group, which is evenly distributed between T and T T3 seconds. If the host receives a group confirmation answer, the group confirmed a response has one
"Request Pending" code, T becomes a code value and the timer is reset to a new T and T T3 DE random number.
The variable T keeps its value until the other "request hang" code is received. Whenever the timer expires, the host sends a group confirmation request.
Even if a host fails to receive a reception confirmation group answering group answering, it will continue to think of the group of members, as it may still receive multi-playback datagram from other hosts on the same LAN. Only when a host receives a "Request Reject" code in a group confirmation response to stop the sending group to confirm the request, it is considered that its membership has been withdrawn.
Multi-Damper Acknowledges a message by sending a group to confirm the response message or give the requested personal sender or a host group address specified in the request. By sending back a group to confirm that all neighboring members of a group, a multi-player agent can reset the timer of each member with a single package. Randomness of the timer is only used to facilitate a timer expiration member to give a group confirmation requirement to help reset all timers with a reply. By using the "request hang" code to let the multi-playback proxy control the speed of the receiving group to confirm the requirements.
Protocol timing constant
The following time constant is for IGMP. They may change because of the results of operation experience.
T0 = 300 second identifier minimum cycle time
T1 = 2 seconds, Create / Join / Leave request retransmission interval
N1 = 5 Tries, Create / Join / Leave Request Heavy Transmission Limit
T2 = 15 seconds, confirm the initial value of the request variable T
T2 = 15 seconds, confirm any number of request variable t
Appendix II. Host group address problem
This appendix does not belong to the IP multi-point broadcast specification, but provides a few discussion on a dispute point associated with the IP host group address.
Group address bundle
The IP host group address bundle of physical hosts may consider the generalization of IP single transmission address bundles. An IP single transmission address is static to a single local network interface on a single IP network. The IP host group address dynamically bundles a set of local network interfaces on a set of IP networks.
It is important to understand an IP host group address is not bundled to a set of IP single transmission addresses. Multi-playback proxy does not need to maintain a special member of each host group. For example, a multi-point broadcast agent attached to an Ethernet is only associated with a single Ethernet multipoint broadcast address with a local member host group, rather than a dedicated IP or Ethernet address of a column.
Group address as logical address
The host group address has explicitly defined for the destination address segment for multi-play IP datagrams. However, the group address is a separate location (they are not staticly bundled with a single network interface), which may be used as multiple normal "logical addresses" in the source and destination address of the datagram. For example, a movable IP host may have a source of a datagram that is only used as its identity land host group address. Whenever the movable host moves from a network to another, it may participate in its own group in the new network and leave the group on the original network. Other hosts and mobile host communication only handle group addresses and may not be known, and will not be affected by the change of the network location of the movable host.
However, the host group address cannot be used to solve all the problems of all interconnected network logic addresses, such as the most close-to-place or minimum load of a multi-point host. In addition, when the Group actually on the source address field contains the above host, there is a danger of using the group address in the source address field of the data. For example, the IP datagram re-assembly algorithm uses different source addresses. Relying on the same time, the error in the datagram with a set of source addresses may result in an error report to return to all members of the group, not just the sender. In view of this danger, this memorandum specifies the use of the host group address only as the destination of the datagram, or at the destination address segment or the last element as a source routing option. However, datagrams with a set of source addresses are best consposed to be received without having to complaint, allowing other implementation of the application logical address of the host group address. Temporary host group address period
Because the host group address is fixed, there is a relatively small size, the short group address must be repeated to meet the requirements of continuing to create a new group. Multi-DVR efforts to ensure that a group specifies its new group address before any member in any place in the Internet. However, under a particular interconnect network segmentation and membership movement conditions, it is impossible to ensure that the unique assignment of an address does not endanger the robustness and effectiveness of the host group. In addition, I don't know that the host that has not existed in a group may be assigned to a new group to send a datagram. Therefore, the host should have a non-deliberate host or even private group multipoint broadcast IP datagram. The possibility of misunderstandings is prepared, and this mishapped only allows the use of advanced identifiers or authentication markers to listen in the IP. (A private group access keyword may be used for some apps such an identifier.) Of course, in addition to the group address conflict in the Internet, there are other hidden communication threats, such as the gateway or no trusted gateway or no Safeted network. End-to-end encryption is a validity against threats.
RFC988 - Host Extensions for ip multicasting IP multi-point broadcast host extension
10
RFC Document Chinese Translation Program
