組織：中國互動出版網（http://www.china-pub.com/）
RFC文件中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：15222775@61.(15222775@61. hbzzx2001@yahoo.com.cn )
譯文釋出時間：2002-3-27
版權：本中文翻譯文件版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須保留本文件的翻譯及版權資訊。
Network Working Group S. E. Deering
Request for Comments: 988 Stanford University
July 1986
IP多點廣播的主機擴充套件
⒈備忘錄地位
本備忘錄說明了主機Internet協議為支援互連網路多點廣播所需要的擴充套件。
本規範取代了RFC - 966給出的ARPA網際網中的IP多點廣播，併為它制定一個提議的協議標準。 RFC - 966詳述了這裡說明的多點廣播擴充套件的基本原理和動機。 本備忘錄的分發不受限制。
⒉介紹
IP多點廣播定義為一個去往"主機群"的IP資料包的傳輸,有零個或多個主機組成的"主機群"通過單個IP目的地址標識。 一個多點播送資料包被投遞給它的目的主機群的所有成員，具有和常規單路傳送IP資料包同樣的"“盡力”安全性，，那就是說該資料包不保證達到目的地組的所有成員或不合其他資料包具有相同的順序。
主機組的會員數是動態的；也就是說,主機隨時可以參加和離開組。 沒有對主機組中的成員的數目或地點加以限制,但是會員僅限於那些擁有專用的存取鍵的主機。 一個主機可能同時是多個組的成員。
一個主機不用是一個組的成員就可以給它傳送資料包。
主機組可能永久性或暫時性的。 永久性組具有一個眾所周知的、政府分配的IP地址。 它是地址,非該組的會員,也就是說永久性；任何時間，一個永久性團體也許有許多成員,甚至可能有零個成員。 另一方面,臨時性的團體,當應一個主機的請求建立時被動態地指派一個地址。 當它的會員跌至零,臨時性的團體要解散時，它的地址可以重新分配。
組員身份臨時團體的建立和組員身份資訊的維護是“多點播送代理”（存在於因特網閘道器或其他專用的主機內的實體）的職責。 至少有一個多點播送代理直接與每個支援IP多點廣播的IP網路或子網相連。 主機通過用鄰機代理交換報文來請求新建一個團組、參加或離開現有團組。
多點播送代理還擔負多點播送IP資料包的互連網路運送工作。 傳送一個多點播送IP資料包時,主機將它傳送到一個區域網多點播送地址那裡，哪些地址標識目的地主機組的所有鄰機成員。 如果該組具有在其他網路的成員,多點播送代理成為本地多點播送的輔助接收器並且通過因特網閘道器係統中繼該資料包給其他網路上的代理。 最後,另一個網路上的代理將資料包作為一個本地的多點播送傳送給他們自己]目的地組的鄰機成員。
本備忘錄說明了一個主機IP實現對IP多點廣播支援所需要的擴充套件,這裡的"主機"是任一internet主機或閘道器而不是充當多點播送代理的機器。 多點播送代理內部和之間使用的演算法和協議對非代理主機來說是透明的，並且在一個獨立的文件中詳細說明。 本備忘錄還未指定區域網多點廣播是怎樣完成的,儘管它規定了對一個任意的區域網所必需的服務介面並乙太網且規範作為一個例子。 其他型別的網路的規格可能是將來備忘錄的課題。
⒊一致水平
對本規範來說有三級一致水平：
0級∶不支援IP多點廣播。
在這時候沒有任何支援IP多點廣播的IP實現。 0級主機通常不受多點播送效率的影響。 唯一的例外發生在某些型別的區域網上,這裡存在的1級或２級主機可能引起多點播送IP資料包誤投給0級主機主機。 這樣的資料包可以通過在它們的目的地地址欄位中的D類IP地址輕易地認出;不支援IP多點廣播的主機應該丟棄他們。 D類地址在本備忘錄的4節定義。
1級∶支援傳送而不支援接受多點播送IP資料包。
1級允許主機參與某些基於多點播送的服務,諸如資源定位或狀態報告,但是不許一個主機建立或參加任何主機組。 IP實現可能從0級主機非常地輕易地升級到1級並且只需少量新程式碼。 本備忘錄的４、５、６節可應用到1級實現。
2級∶充分支援IP多點廣播。
２級容許一個主機去建立、參加和離開主機組,以及給主機組傳送IP資料包。 它要求在主機內部實現IGMP並且擴充套件IP和區域網服務介面。 本備忘錄以下的所有部分可適用於實現２級。
⒋主機組地址
主機組高四位位元組可以通過D類IP地址認出，那就是說D類IP地址用" 1110 "作為它們的高四位位元組。 餘下的28位未組織，直到主機關心他們的時候為止。 有名的永久性組的地址將被刊登於"分配號碼"中。E類IP地址即用" 1111 "作為它們的高四位位元組的IP地址專供將來定址方式之用。
附錄II包含某些背景知識，詳述了與主機組地址相關的幾個爭執點。
IP多點廣播的主機擴充套件
5.一個主機IP實現的模型
擴充套件主機IP實現的多點播送如下圖所示： 在本模型中, Internet信報控制協議和(用於２級主機的) IGMP被認為是在IP模組內部實現的,並且IP地址到本地網路地址的對映被認為是區域網模組的職責。 本模型僅用於說明意圖，但是不應該把它看作是一個實際實現。
| |
| 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) |
| |
為支援２級IP多點廣播,主機IP實現必須提供三個新業務∶ ( 1)傳送多點播送IP資料包、( 2)接收多點播送IP資料包、和(３)管理組員身份。
1級主機僅需要提供第一個服務。 每種服務在下面用一個獨立的部分說明。 每一種服務,都為IP服務介面、IP模組、區域網服務介面和乙太網區域網模組規定了一些擴充套件。 對於區域網模組而不是乙太網區域網模組的擴建部分進行簡短地敘述,但是沒有詳細地規定。
⒍傳送多點播送IP資料包
6.1.對於IP服務介面的擴建部分
為支援多點播送IP資料包的傳送IP服務介面不需要做出修改。 當它啟用現存"傳送IP "操作時上層協議模組僅僅規定了一個IP主機組目的地,而非一個個人IP目的地,。
6.2.對於IP模組的擴建部分
為支援多點播送IP資料包的傳送, IP模組必須進行擴充套件以便當路由輸出資料包時能分辨IP主機組地址。 大多數IP實現包括以下:
如果IP目的地在同一個區域網上,傳送資料包給當地IP -目的地，別的傳送資料包給當地GatewayTo( IP目的地)
為容許多址通訊傳輸,路徑選擇邏輯必須變成∶
if IP目的地在同一個區域網上或IP目的地是一個主機組,傳送資料包給當地IP -目的地，否則傳送資料包給當地gatewayto ( IP目的地)
如果傳送主機是目的地組的一個成員本身,輸出資料包的備份必須環回區域性運送，當且僅當主機參加該組時才回送(參見8.1部分)。(這個問題在1級實現中沒有出現.)
在連線一個以上網路的主機上,每個多點播送IP資料包必須僅通過一個網路介面傳送,離開它去往多點播送代理直到投遞給任何其他要求的網路。
主機組地址不應該處於一個輸出IP資料包的源地址欄位。 主機組地址可能用於源路由選項。
人們注意到一個小型的IP生存時間( TTL) ( TTL)值可以
阻止投遞給一個目的地組的某些成員。 因此,一個巨大的TTL值應該用於到達所有成員。 相反地,一個小型的TTL值可用於僅到達分散廣泛地組的"附近的"成員。 在小延遲區域網叢集中TTL域作為一個路程段限制;因此,可以這樣完成擴充套件環調查：TTL開始為1並且每次重傳加１,直到由叢集直徑定義的極限。
6.3.對於區域網服務介面的擴建部分
為支援多點播送IP資料包的傳送區域網服務介面不需要做出修改。 當它啟用現存" Send Local "操作時IP模組僅僅規定了一個IP主機組目的地,而非一個個人IP目的地,。
6.4.對於乙太網區域網模組的擴建部分
通過允許在乙太網資訊包的目的地域使用多點播送地址，乙太網可以直接支援本地多點播送包的傳送。 為支援多點播送IP資料包的傳送，需要一個用於將IP主機組地址對映到乙太網多點播送地址的方法。
通過將IP地址的低28位放入一個乙太網地址的低28位，一個IP主機組地址被對映到一個乙太網多點播送地址。 乙太網地址的高20位設定成一個在"分配號碼"（" Assigned Numbers "）中刊登的有名的值。
[在發表本備忘錄時,具有28未指定的位的乙太網多點播送地址塊還沒有從分配權力機構處獲得。 如果不能獲得這樣的地址塊,可能會規定一個替換對映方案.]
6.5.對區域網模組而不是乙太網的擴充套件
為了傳送多點播送IP資料包，其他的直接支援多點廣播的網路例如符合IEEE 802.2標準的環或匯流排型網路,可以用和乙太網一樣的方法處理。 對於支援廣播而不是多點播送地網路,例如試驗性乙太網,所有IP主機組地址都可以被對映到單個區域性廣播地址(以增加所有本地主機開銷為代價）。 對於一個象ARPANET或公用資料網那樣的點到點網路
( X.25),所有IP主機組地址都可能被對映到一個盡人皆知的一個IP多點播送代理的區域性地址;一個這種網路上的代理負責在網路以及網路間完成多點播送投遞。
⒎接收多點播送IP資料包
7.1.對於IP服務介面的擴建
為支援多點播送IP資料包的接收IP服務介面不需要做出修改。 利用和普通的" Receive IP"一樣的操作（單路傳送資料包），入局多點播送IP資料包被投遞給上層協議模組。
7.2.對IP模組的擴充套件
為了支援多點播送IP資料包的接收,必須擴充套件IP模組，使它除認出主機的專用IP地址之外可以認出主機當前所屬的IP主機組的地址, 去往那些組地址中的一個的入局資料包用和處理主機的私有地址中的一個的資料包完全一樣的方法處理。
去往非該主機所屬的組的入局資料包被丟棄，不產生任何關於錯誤的報告。
關於連線一個以上網路的主機,如果一個資料包到達一個網路介面,要去的該主機所屬的組在一個不同的介面上,該資料包被默默地丟棄。 (這個只有在區域網模組缺乏多點播送地址過濾的情況下才會發生.)
在它的源地址欄位或在源路由選項中的什麼地方具有一個IP主機組地址的入局資料包不會被拒絕。
ICMP錯誤報文(目的地不可達、時間超出、引數問題、源熄滅或重定向)從來不因一個去往IP主機組的資料包引起。
7.3.對於區域網服務介面的擴建部分
為支援多點播送IP資料包的接收區域網服務介面不需要做出修改。 入局區域網包,不管多點播送或單路傳送,被用" Receive Local"一樣的操作投遞給IP模組。
IP多點廣播的主機擴充套件
7.4.對於乙太網區域網模組的擴充套件
為了支援多點播送IP資料包的接收,一個乙太網模組必須能夠接收發給該乙太網多點播送地址的包，該乙太網多點播送地址與主機的IP主機組地址對應。 任何地址過濾器能力（乙太網硬體介面可能具有）的優越性都是非常所希望的,所以主機僅接收去往它的那些包。
令人遺憾地是，當前許多乙太網介面對硬體可以辨認的地址的數目只有一個很小的限制。 不過,一個實現必須能夠偵聽偵聽任意數目的乙太網多點播送地址,可能意指為了在地址的數目越出過濾器允許範圍期間全部接受多點播送包開啟地址過濾器。
缺乏的機器地址過濾器的那些介面,可能希望在乙太網模組的軟體內部完成乙太網地址過濾。 不過,這不是強制性的,因為IP模組根據IP目的地址執行它的自己的過濾。
7.5.對區域網模組而不是乙太網的擴充套件
為了接收多點播送IP資料包，其他的直接支援多點廣播的網路例如符合IEEE 802.2網路,為了接收多點播送IP資料包可以用和乙太網一樣的方法處理。 對於純廣播式網,例如試驗性乙太網,所有入局廣播包都被接受然後為了進行IP級過濾而傳送給IP模組。 在一個點到點網路上,多點播送IP資料包可能作為區域網單路傳送到達,所以沒有必要改變區域網模組。
⒏管理組員身份
8.1.78.1.對於IP服務介面的擴充套件
為了讓上層協議模組要求它們的主機建立、參加、或離開一個主機組, IP服務介面必須被擴充套件以便提供以下三個新操作∶
CreateGroup ( private, loopback )
--> outcome, group-address, access-key
該CreateGroup操作請求生成一個新的、臨時的主機組,只有這個主機作為它的成員。 這
" private（私有）"引數規定了該組將是私有的or公共的。 該" loopback（回送）"引數規定了不管是否是發自這個主機去該組的資料包都應該區域性地其他的成員主機。遞送給 The " outcome（結果）"指出請求是允許或被拒絕的。 如果是允許,返回一個新的32位IP主機組地址,以及一個64位存取關鍵字，零是為公共的組和非零為私有組。 該請求可能被被拒絕的，由於缺乏來自一個多點播送代理響應、或缺乏資源。
JoinGroup ( group-address, access-key, loopback ) --> outcome
該joingroup操作要求這個主機成為該主機組的通過"組地址"辨認的一個成員,具有規定的存取關鍵字。該" loopback（回送）"引數規定了不管是否是發自這個主機去該組的資料包都應該區域性地其他的成員主機。遞送給 The " outcome（結果）"指出請求是允許或被拒絕的。 由於缺乏來自一個多點播送代理響應、一個缺乏資源、一個非法組地址、一個錯誤的存取關鍵字或已是一個成員,該請求可能被拒絕。
LeaveGroup ( group-address, access-key ) --> outcome
該LeaveGroup操作要求這個主機放棄該主機組的能夠通過"組地址"辨認的一個成員的資格,具有規定的存取關鍵字。 The " outcome（結果）"指出請求是允許或被拒絕的。 由於缺乏來自一個多點播送代理響應、一個缺乏資源、一個非法組地址、一個錯誤的存取關鍵字或當前不是一個成員,該請求可能被拒絕。
這些操作中間每一個可能佔據一分鐘以上才能完工,取決於IGMP重傳的數目
在IP模組內部執行、多點播送代理產生一個應答需要的時間。不過,標準的延遲應該幾秒左右。
除LeaveGroup操作之外,每當主機或它的IP模組崩潰，或在罕見的情景中——當一個多點播送代理撤回它的會員時，該主機丟失它在一個組中的會員資格。 當它的會員資格已經被撤回時， IP服務介面將提供某些方法通知上層模組。
會員資格可能由於缺乏資源、組地址的儲存單元分配、或發現另一個主機組用具有一個不同的存取關鍵字的同樣的組地址，會員資格可能被撤回。 (參見附錄II，詳述了地址回收問題.)
注意到IP組員身份是per - host（每主機）而非per - process（每程式）是是很重要的。 一個IP服務介面不應該為同一個組讓多程式啟用JoinGroup操作作為完成投遞給跟多的程式的方法 IP模組傳遞每個入局資料包,不管多點播送或單路傳送,給一個上層協議模組,該上層協議模組通過資料包的IP報頭中的協議域認出;不管是否傳遞入局資料包給多個程式,它都是個上層問題,也許應該using " process groups（程式組）"概念或" shared ports（共享入口） "概念。
8.2.對IP模組的擴充套件
IP模組內部,會員資格management操作通過Internet Group Management Protocol ( IGMP)支援，在附錄I.中規定。也使報文與每一上面規定的操作相對應，IGMP還規定一個
" deadman timer "程式藉此主機定期用multicast agents確認它們的會員資格。
IP模組必須維護一個資料結構,該資料結構列出主機當前所屬的所有主機組的IP地址、以及每個組的回送政策、存取關鍵字和時間變數。 這個資料結構被用於IP多址通訊傳輸服務，瞭解哪些輸出資料包給回送,通過接收服務瞭解哪些入局資料包去接受。 IGMP的和management介面操作的用途是維護這個資料結構。
每個會員資格與具體的網路介面相聯絡，連線一個以上網路的主機上, 在這種主機上，上面的每個management介面操作可能要求一個附加引數來規定介面建立、
參加或離開請求申請。 組員身份資料結構還必須必須進行擴充套件以便使每個會員資格於一個介面聯絡起來。 如果一個主機在一個以上網路介面上參加同一個主機組,它可能期望接收每個傳送給那個組的資料包的多個副本。
8.3.對於區域網服務介面的擴充套件
為讓一個IP模組控制什麼樣的包應該通過區域網模組接受,必須用以下兩個新的操作擴充套件該區域網服務介面∶
AcceptAddress ( group-address )
RejectAddress ( group-address )
這裡的" group - address（組地址）"是一個IP主機組地址。 該。AcceptAddress操作要求該區域網模組接受和放棄隨後到達的去往與" group - address（組地址）"相當的本地網路地址的那些包。 該RejectAddress操作要求該區域網模組停止傳輸隨後到達的去往與" group - address（組地址）"相當的本地網路地址的那些包。
Any區域網模組都能夠自由地忽略RejectAddress請求,並且可能傳遞去往比那個在AcceptAddress要求中規定的地址多的包,如果它不能充分地過濾入局包。
8.4.對於乙太網區域網模組的擴充套件
一個乙太網模組通過給它的入局包的接受過濾條件增加對應的乙太網多點播送地址就可以響應AcceptAddress操作。 rejectaddress操作引起對應乙太網地址從過濾處落下。 對於限制能夠被增加給過濾器的地址的數目的乙太網介面,當臨界被超出乙太網軟體模組必須偵聽並且開啟過濾全部接受多點播送包。 當地址的數目降低到臨界入口程度，它還應該偵聽並且恢復單個地址過濾。
8.5.對區域網模組而不是乙太網的擴充套件
為了控制地址過濾器，其他的多點廣播網路例如符合IEEE 802.2網路,為了控制地址過濾器可以用和乙太網一樣的方法處理。 對於一個純廣播式網或一個
點到點網路,該AcceptAddress和RejectAddress操作也許已無效;為了進行IP級過濾所有入局包能夠傳送給IP模組。
附錄I. INTERNET GROUP MANAGEMENT PROTOCOL ( IGMP)
IGMP被用在IP主機和它們的緊接的鄰機多點播送代理之間支援臨時團體的生成新增和刪除一個組的成員,定期證實組員身份。 IGMP是一個不對稱協議而且這裡從一個主機觀點而非一個多點播送代理來加以說明。
像ICMP（Internet信報控制協議）一樣, IGMP是一個IP的組成部分。 它要求通過所有主機對應的２級IP多點廣播規範完全地實現。 IGMP報文被壓縮在IP資料包中,具有一個IP協議號碼2.所有IGMP報文具有以下格式∶
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
型別
有八種IGMP報文∶
1 =建立組要求
２=建立組應答
３=參加組要求
４=參加組應答
５=離開組要求
６=離開組應答
７=確認組要求
８=確認組應答
程式碼
在一個建立組請求訊息中程式碼欄位指出新的主機組將是公共的或私有∶
0 =公共的
1 =私有
在所有其他的請求訊息中,程式碼欄位包含零。
在一個回答資訊中,程式碼欄位規定要求的結果∶
0 =請求答應
1 =要求被拒絕,無資源
２=要求被拒絕,無效程式碼
３=要求被拒絕,無效組地址
４=要求被拒絕,無效存取關鍵字
5 - 255 =要求掛起,幾秒後重試
校驗和
EGP校驗和是從EGP版本IGMP型別開始的IGMP報文中16位字二進位制反碼和的16位二進位制反碼值。
為了計算該校驗和,校驗和域應該為零。
識別符號
在一個確認組請求訊息中,識別符號欄位包含零。
在所有其他的請求訊息中,識別符號域包含一個值以便將來自同一個主機的其他的要求其他的要求與該要求區別開來。
在一個回答資訊中
,識別符號域包含與在對應請求訊息中同樣的值。
組地址
在一個組建立請求報文中,組地址欄位包含零。
在所有其他的請求訊息中,組地址域包含一個主機組地址。
在一個組建立應答報文中，組地址域或包含新的指定的主機組地址(如果該要求被允許)或包含零(如果被拒絕)。
在所有其他的應答報文中,組地址域包含與在對應請求報文中同樣的主機組地址。
存取關鍵字
在一個組建立請求報文中,存取關鍵字欄位包含零。
在所有其他的請求訊息中,存取關鍵字域包含分配給主機組在組地址域識別的(零對於公共的組)存取關鍵字。
在一個組建立應答報文中，存取關鍵字域或包含一個非零的64位元編號(如果要求一個私有組被允許)或包含零(如果被拒絕)。
在所有其他的應答報文中,存取關鍵字域包含與在對應要求中相同存取關鍵字。
協議規則
請求報文只通過主機傳送。 應答報文只通過多點播送代理髮送。 如果一個主機收到一個前面規定的四種應答型別之外的一種型別的IGMP報文,該報文被丟棄。
一個請求報文傳送時具有它的IP目的地欄位，該目的地欄位包含著名的多點播送代理組的地址。 IP生存時間( TTL)域通過傳送者置1初始化,以便約束要求的範圍為近的鄰機多點播送代理。 IP源地址欄位包含傳送主機的專用IP地址。
應答報文只在響應一個請求報文時傳送。
IP目的地址域的包含該主機（傳送該對應要求）的私有地址。 (一個組確認應答可能同時被髮給在它的對應組確認要求中規定的主機組地址.) IP源地址欄位包含該應答多點播送代理的專用IP地址。
當一個主機傳送一個新的組建立、組參加、或離開組請求報文時,它供給一個任意的識別符號，該任意的識別符號在最後的T0秒內沒有用。 (僅僅為識別符號在每個新的要求加１就足夠了.)該主機初始化一個計時器為T1秒並且初始化一個重複傳輸計數器為零。 如果具有一個匹配識別符號應答報文沒有在計時器到期之前收到,它被重新設定為T1秒並且該重複傳輸計數器加１。 如果計算器小於N1該主機重複傳輸該具有相同識別符號的請求報文。 如果該計算器等於N1,該主機放棄;如果該要求將建立或參加一個組,它被認為失敗;如果該要求將離開一個組,它被認為得逞;
如果一個"要求掛起"程式碼在一個匹配一個建立組、參加組或離開組要求回答中收到,計時器重新設定為由該程式碼規定的數值，並且重複傳輸計數器重新設定為零。 新的定時值僅應用於一個超時時間間隔——如果該計時器到期,它重新設定為T1秒,該計數器加１,並且要求被重傳。
一個組建立、組參加或離開組請求的第一個匹配的回答包含一個"請求答應"或"要求被拒絕"程式碼，判斷該要求的結果。 任何後來的或非匹配的應答由該主機丟棄。 不過如果一個主機收到一個肯定的建立組應答或參加組應答，但是他們既不匹配一個未解決的請求又不包含一個該主機所屬的組地址,該主機應該立即傳送一個離開組要求以便解決該出乎意外的組地址。
一個"請求答應（request granted） "回答一個建立組請求，暗示,以及組正在建立,該請求主機被同意在該組中具有會員資格,那就是說不必傳送一個單獨的參加組請求。
組確認要求報文必須由主機定期傳送，以便通知主機在規定的組中的延續會員資格給鄰機多點播送代理。 如果一個代理沒有在一個代理定義的時間間隔內收到一個具體的組的組確認要求報文,它停止傳遞去往那個組的資料包。
對於它所屬的每個組，主機維護一個確認計時器和一個變數t.該變數t初始化為T2秒。每當主機的建立參加一個組請求的被允許,或者每當主機傳送一個組確認要求或者收到組確認應答，該組確認要求或者收到組確認應答具有一個
該組的"請求答應"程式碼,該主機設定該組的計時器為一個，該隨機數均勻分佈在t和t + T3秒之間。 如果該主機收到一個組確認應答，該組確認應答具有一個
" request pending "程式碼, t變成程式碼值並且該計時器重新設定為一個新的t和t +T3間de隨機數。
變數t保持它的值，直到另一個"請求掛起"程式碼收到為止。 每當計時器到期,主機傳送一個組確認要求。
即使一個主機未能它的請求的接收確認組回答,它繼續將本身認為該組的成員,因為它可能仍然能夠從在同一個區域網上的其他的主機收到多點播送資料包。只有當一個主機在一個組確認應答中收到一個"要求被拒絕"程式碼讓它停止傳送組確認要求時才認為它的會員資格已經被撤回。
多點播送代理通過傳送組確認應答報文或者給該請求的個人傳送者或者給在該請求中規定的主機組地址來響應組確認要求報文。 通過送回一個組確認應答一個組的所有鄰機成員,一個多點播送代理能夠用單個包重新設定每個成員的計時器。 計時器的隨機化只不過是用來促成一個計時器到期成員優先傳送一個組確認要求,有助於用一個回答重置全部計時器。 通過利用"請求掛起"程式碼讓多點播送代理控制接收組確認要求的速度。
協議定時常量
以下時間常數是為IGMP規定的。 由於執行經驗的結果他們可能會變化。
T0 = 300秒識別符號最小數週期時間
T1 = 2秒，Create/Join/Leave請求的重傳時間間隔
N1 = 5 tries，Create/Join/Leave請求重傳極限
T2 = 15秒，確認請求變數t的初值
T2 = 15秒，確認請求變數t的任意數範圍
附錄II。 主機組地址問題
這個附錄不屬於IP多點廣播規範,但是提供幾個與IP主機組地址相關的爭執點的論述背景。
組地址捆綁
物理主機的IP主機組地址捆綁可能認為IP單路傳送地址捆綁的普遍化。 一個IP單路傳送地址被靜態地捆綁給單個IP網路上的單個區域性網路介面。 IP主機組地址動態地捆綁給一組IP網路上的一組區域性網路介面。
領會一個IP主機組地址不是捆綁給一組IP單路傳送地址是很重要的。 多點播送代理不需要維護每個主機組的一列專用成員。 比如,一個附著於一個乙太網地多點播送代理只不過跟每個具有區域性成員主機組的單個乙太網多點播送地址關聯,而非一列會員們的專用IP或乙太網地址關聯。
組地址作為邏輯地址
主機組地址已經明確地定義供多點播送IP資料包的目的地地址段裡使用。 不過,組地址是獨立的位置(他們不靜態地捆綁與單個網路介面)，可能作為多個普通"邏輯地址"在資料包的源和目的地址中段運用。 比如,一個可移動IP主機可能具有一個只不過作為它的身份地主機組地址,用作它傳送的資料包的源。 每當可移動主機從一個網路移動到另一個網路,它可能在新的網路參加它的自己的組並且離開在原網路上的組。 其他的主機和可移動主機通訊僅僅會處理組地址並且可能不知道,並且不被可移動主機的網路位置的改變所影響。
不過主機組地址不能用來解決所有互連網路邏輯地址的所有問題,例如投遞到一個多穴主機的最靠近地或最小荷載的網路介面。此外,當組實際上源地址欄位包含以上主機的時候，在資料包的源地址欄位使用組地址存在危險。 舉例來說, IP資料包再裝配演算法每個主機使用不同的源地址。依靠 同時,用一組源地址傳送的資料包中的錯誤可能導致錯誤報告回到該組的所有成員,不只是傳送者。 鑑於這個危險,本備忘錄規定主機組地址的使用僅僅作為資料包的目的地,或在目的地址段或作為一個源路由選項的最後元素。 然而,具有一組源地址的資料包最好由被接收而不必申訴,從而允許其他實現的試用主機組地址的應用程式邏輯地址。
臨時的主機組地址的週期
因為主機組地址是固定的,有相對較小的尺寸,所以短暫的組地址必須反覆迴圈以便滿足繼續新建一個團組的要求。 多點播送代理努力確保一個組指定它的新建群組地址之前在Internet中任何地方的不具有成員。 然而,在特定互連網路分割和會員資格移動條件下,不可能保證一個地址的唯一的分配不危及主機組的健壯性和有效性。此外,不知道某個組已經不存在的主機可能在它的地址已經分配給一個新建群組很久以後還給它傳送資料包， 所以主機應該對非故意的主機甚至私有組多點播送IP資料包的誤投的可能性有所準備, 這種誤投只得使用高階的識別符號或認證記號在IP以上級偵聽。 (一個私有組的存取關鍵字可能用於某些應用程式地這樣一個識別符號.)當然,在Internet中除組地址衝突之外，存在其他的隱避的通訊威脅,例如不能信賴的閘道器或無擔保的網路。端到端加密是這種對威脅的一個有效抵禦。
RFC988——Host Extensions for IP Multicasting IP多點廣播的主機擴充套件
10
RFC文件中文翻譯計劃