要注意的是，多播路由器接收所有IP多播數據報，因此不需要明確的指明它的地址。還要
注意的是，路由器不需知道哪些主機屬于一個組，而僅需知道是否至少有一個主機屬于在特
定網絡上的一個組。
對以上描述的特性有兩個例外。第一，如果在請求收到以前，已經有一個報告延時定
時器在為一個組成員運行，則該定時器不會重置為一個新的隨機值，而允許以它的當前值運
行。第二，報告定時器不會因為主機是所有主機組（224.0.0.1）的成員而生成，這個成員關
系不會被報告。
如果主機使用偽隨機數生成器計算報告延遲時間，主機的單個IP地址之一應用作生成
器種子的一部分，以減少多宿主機生成相同的延遲序列的可能性。
主機應該確保接收到的報告的IP目的地址字段和IGMP組地址字段有相同的IP組地
址。以保證主機自己的報告不會因為錯誤的接收報告而取消。主機應該丟棄除了主機成員請
求或主機成員報告類型以外的任何IGMP報文。
多播路由器周期性地發送請求，以更新它所知的，在特定網絡上目前的成員關系情況。
如果在幾次請求之后，沒有接收到特定組的報告，則路由器假設這個組已經沒有本地成員，
它們就不需轉發從遠端傳來的那個組的多播數據報到本地網絡上。正常情況下，請求被發送
的頻率很低（每分鐘不超過一次），因此IGMP對主機和網絡的開銷非常小。然而，當多播
路由器啟動時，它可以發出幾個時間間隔很小的請求，以便盡快獲知本地成員的情況。
當主機加入一個新的組時，它應該立即發送一個那個組的報告，而不是等待一個請求，
以防萬一它是這個網絡上該組的第一個成員。考慮到初始的報告可能丟失或損壞，建議在一
個短的延遲后重復報告一到兩次。（達到這一目的的一種簡單的方式是好像僅僅那個組的請
求被接收，設置組隨機報告延遲定時器。以下的狀態變換圖解釋了這種方法。）
要注意的是，在一個沒有多播路由器的網絡上，當有主機加入一個新組時，唯一的IGMP
通信量是一個或多個報告的傳送。

狀態變換圖
通過下面的狀態轉換圖，將更加正式地說明IGMP特性。每個主機可能處于三種可能
的狀態中的一種，這與在任意的單個網絡接口上的一個單獨的IP主機組有關。
—非成員狀態，當主機不屬于這個接口上的組時。這是所有網絡接口上所有成員的初
始狀態；它不需要主機的存儲空間。
—延時成員狀態，當主機屬于那個接口上的組時，需要為這個成員關系運行一個報告
延時定時器。
—空閑成員狀態，當主機屬于那個接口上的組時，不需要為這個成員關系運行一個報
告延時定時器。
有五種重大的事件能使IGMP狀態變換：
  —當主機決定加入這個接口的組時，出現“加入組”事件。這只能出現在非成員狀態。
  —當主機決定離開這個接口的組時，出現“離開組”事件。這只能出現在延遲成員和
空閑成員狀態。
  —當主機收到一個有效的IGMP主機成員請求報文時，出現“請求收到”事件。要達
到有效狀態，請求報文必須至少有8字節長，有一個正確的IGMP校驗和和地址為224.0.0.1
的IP目的地址。單一的請求適合于收到請求的接口的所有成員關系。這里不考慮非成員狀
態或延遲成員狀態的情況。
—當主機接收到一個有效的IGMP主機成員報告報文時，出現“報告收到”狀態。要達
到有效狀態，報告報文必須至少有8字節長，有一個正確的IGMP校驗和，而且在它的IP
目的地址字段和IGMP組地址字段有相同的IP組地址。報告僅用于在接收到報告的接口上，
由報告標識的組組成員。這里不考慮非成員狀態或空閑成員狀態的情況。
—當接口上的組的報告延遲定時器超時時，出現“定時器超時”事件。它只出現在延遲
成員狀態。
所有其它的事件，如收到無效的IGMP報文，或收到除請求或報告之外的IGMP報文，
被忽略了。
有三種可能的動作，可以用來響應以上事件：
—為那個接口上的組“發送報告”。
—為那個接口上的組“打開定時器”，使用在0到D秒之間的隨機延時值。
—為那個接口上的組“停止定時器”。
在下面的圖表中，每個狀態轉換弧由促使轉換的事件標記，在圓括號中的是在轉換過程
中所執行的動作。















                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   --------->|     非成員     |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  |   離開組          |     加入組       | 離開組
                  | (停止定時器)      |  (發送報告，     |
                  |                   |  打開定時器)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |                    |                 |
         |                 |<-------------------|                 |
         |                 |    接收到請求      |                 |
         | 延遲成員        |    (開始定時器)    |     空閑成員    |
         |                 |------------------->|                 |
         |                 |    接收到報告      |                 |
         |                 |    (停止定時器)    |                 |
         |_________________|------------------->|_________________|
                                定時器超時
                                (發送報告)
	所有主機組（地址為224.0.0.1）的處理屬于特殊情況。主機開始時是每個接口上的那個
組的空閑成員狀態，不會變換到其它狀態，也不會為那個組發送報告。

協議參數
最大報告延時D為10秒。
附錄2  主機組地址問題
本附錄不是IP多播規范的一部分，但提供了有關IP主機組地址的一些問題的背景討論。

組地址綁定
    IP主機組地址到物理主機地址的綁定可以被認為是IP單播地址綁定的推廣。一個IP單
播地址靜態地綁定到一個單一的IP網絡上的一個單一的本地網絡地址接口上。一個IP主機
組地址動態地綁定到一個IP網絡集合上的本地網絡接口集合上。
IP主機組地址不會綁定到IP單播地址集合上，理解這一點很重要。多播路由器不會維
持每個主機組的單個成員的列表。例如，屬于一個以太網的多播路由器僅需有一個與有本地
成員的每個主機組對應的單一的以太網多播地址，而不是那些成員的單個IP或以太網地址
列表。     
臨時主機組地址的分配
    本備忘錄沒有說明暫時的組地址是如何分配的。預期是IP暫時主機組地址空間的不同
部分的分配使用不同的技術。例如，可能有許多服務器聯系在一起獲得一個新的暫時組地址。
一些高層協議（比如VMTP，在RFC-1045中說明）可以生成高層暫時“進程組”或“實體
組”地址，這些地址會在算法中映射到IP暫時主機組地址的子集中，這與IP主機組地址映
射到以太網多播地址上類似。IP組地址空間的一部分可以留給一些應用程序隨機分配，這
些應用程序能容忍和其它多播用戶偶爾沖突，在發現一個合適的“安靜”地址之前，一直生
成新的地址。
一般來說，主機不能假設被送到主機組地址的數據報將僅僅到達目的主機，或作為暫時
主機組的一個成員接收數據報的目的就是為了接受。在IP層以上，使用高層標識符或認證
標志來檢測錯誤投遞。如果發送者不想讓不必要的用戶收到，則傳遞給主機組地址的信息應
該被加密或用路由管理控制方法進行控制。

作者地址
   Steve Deering
   Stanford University
   Computer Science Department
   Stanford, CA 94305-2140 
Phone: (415) 723-9427
   EMail: deering@PESCADERO.STANFORD.EDU
RFC1112  Host Extensions for IP Multicasting                         RFC 主機擴展用于IP多點傳送