IGMP協定詳解

1、引言

　　本文将介紹用于支援主機和路由器進行多點傳播的Internet組管理協定（IGMP）。它讓一個實體網絡上的所有系統知道主機目前所在的多點傳播組。多點傳播路由器需要這些資訊以便知道多點傳播資料報應該向哪些接口轉發。IGMP在RFC 1112中定義[Deering 1989].

　　正如ICMP一樣， IGMP 也被當作IP 層的一部分。IGMP封包通過IP資料報進行傳輸。不像我們已經見到的其他協定， IGMP有固定的封包長度，沒有可選資料。圖13-1顯示了IGMP封包如何封裝在IP資料報中。

IGMP（Internet組管理協定）封包及協定（圖一）

　　IGMP封包通過IP首部中協定字段值為2來指明。

2、 IGMP封包

　　圖1 3 - 2顯示了長度為8位元組的IGMP封包格式。

IGMP（Internet組管理協定）封包及協定（圖二）

　　這是版本為1的IGMP.IGMP類型為1說明是由多點傳播路由器發出的查詢封包，為2說明是主機發出的報告封包。檢驗和的計算和ICMP協定相同。

　　組位址為D類IP位址。在查詢封包中組位址設定為0，在報告封包中組位址為要參加的組位址。在下一節中，當介紹IGMP如何操作時，我們将會更詳細地了解它們。

3、 IGMP 協定

　　3.1 加入一個多點傳播組

　　多點傳播的基礎就是一個程序的概念（使用的術語程序是指作業系統執行的一個程式），該程序在一個主機的給定接口上加入了一個多點傳播組。在一個給定接口上的多點傳播組中的成員是動态的—它随時因程序加入和離開多點傳播組而變化。

　　這裡所指的程序必須以某種方式在給定的接口上加入某個多點傳播組。程序也能離開先前加入的多點傳播組。這些是一個支援多點傳播主機中任何API所必需的部分。使用限定詞“接口”是因為多點傳播組中的成員是與接口相關聯的。一個程序可以在多個接口上加入同一多點傳播組。

　　Stanford大學伯克利版Unix中的IP 多點傳播詳細說明了有關socket API的變化，這些變化在Solaris 2.x和ip（7）的文檔中也提供了。

　　這裡暗示一個主機通過組位址和接口來識别一個多點傳播組。主機必須保留一個表，此表中包含所有至少含有一個程序的多點傳播組以及多點傳播組中的程序數量。

　　3.2 IGMP 報告和查詢

　　多點傳播路由器使用IGMP封包來記錄與該路由器相連網絡中組成員的變化情況。使用規則如下：

　　1） 當第一個程序加入一個組時，主機就發送一個IGMP報告。如果一個主機的多個程序加入同一組，隻發送一個IGMP報告。這個報告被發送到程序加入組所在的同一接口上。

　　2） 程序離開一個組時，主機不發送IGMP報告，即便是組中的最後一個程序離開。主機知道在确定的組中已不再有組成員後，在随後收到的IGMP查詢中就不再發送報告封包。

　　3） 多點傳播路由器定時發送IGMP查詢來了解是否還有任何主機包含有屬于多點傳播組的程序。多點傳播路由器必須向每個接口發送一個IGMP查詢。因為路由器希望主機對它加入的每個多點傳播組均發回一個報告，是以IGMP查詢封包中的組位址被設定為0.

　　4） 主機通過發送IGMP報告來響應一個IGMP查詢，對每個至少還包含一個程序的組均要發回IGMP報告。

　　使用這些查詢和報告封包，多點傳播路由器對每個接口保持一個表，表中記錄接口上至少還包含一個主機的多點傳播組。當路由器收到要轉發的多點傳播資料報時，它隻将該資料報轉發到（使用相應的多點傳播鍊路層位址）還擁有屬于那個組主機的接口上。

　　圖1 3 - 3顯示了兩個IGMP封包，一個是主機發送的報告，另一個是路由器發送的查詢。該路由器正在要求那個接口上的每個主機說明它加入的每個多點傳播組。

3.3 實作細節

　　為改善該協定的效率，有許多實作的細節要考慮。首先，當一個主機首次發送IGMP報告（當第一個程序加入一個多點傳播組）時，并不保證該報告被可靠接收（因為使用的是IP傳遞服務）。下一個報告将在間隔一段時間後發送。這個時間間隔由主機在0 ~ 1 0秒的範圍内随機選擇。

　　其次，當一個主機收到一個從路由器發出的查詢後，并不立即響應，而是經過一定的時間間隔後才發出一些響應（采用“響應”的複數形式是因為該主機必須對它參加的每個組均發送一個響應）。既然參加同一多點傳播組的多個主機均能發送一個報告，可将它們的發送間隔設定為随機時延。在一個實體網絡中的所有主機将收到同組其他主機發送的所有報告，因為如圖1 3 - 3所示的報告中的目的位址是那個組位址。這意味着如果一個主機在等待發送報告的過程中，卻收到了發自其他主機的相同報告，則該主機的響應就可以不必發送了。因為多點傳播路由器并不關心有多少主機屬于該組，而隻關心該組是否還至少擁有一個主機。的确，一個多點傳播路由器甚至不關心哪個主機屬于一個多點傳播組。它僅僅想知道在給定的接口上的多點傳播組中是否還至少有一個主機。

　　在沒有任何多點傳播路由器的單個實體網絡中，僅有的IGMP通信量就是在主機加入一個新的多點傳播組時，支援IP多點傳播的主機所發出的報告。

　　3.4 生存時間字段

　　在圖1 3 - 3中，我們注意到IGMP報告和查詢的生存時間（TTL）均設定為1，這涉及到IP首部中的TTL字段。一個初始TTL為0的多點傳播資料報将被限制在同一主機。在預設情況下，待傳多點傳播資料報的TTL被設定為1，這将使多點傳播資料報僅局限在同一子網内傳送。更大的TTL值能被多點傳播路由器轉發。

　　回顧6 . 2節，對發往一個多點傳播位址的資料報從不會産生ICMP差錯。當TTL值為0時，多點傳播路由器也不産生ICMP“逾時”差錯。

　　在正常情況下，使用者程序不關心傳出資料報的TTL.然而，一個例外是Traceroute程式（第8章），它主要依據設定TTL值來完成。既然多點傳播應用必須能夠設定要傳送資料報的TTL值，這意味着程式設計接口必須為使用者程序提供這種能力。

　　通過增加TTL值的方法，一個應用程式可實作對一個特定伺服器的擴充環搜尋（eXPandingring search）。第一個多點傳播資料報以TTL等于1發送。如果沒有響應，就嘗試将TTL設定為2，然後3，等等。在這種方式下，該應用能找到以跳數來度量的最近的伺服器。

　　從224.0.0.0到224.0.0.255的特殊位址空間是打算用于多點傳播範圍不超過1跳的應用。不管TTL值是多少，多點傳播路由器均不轉發目的位址為這些位址中的任何一個位址的資料報。

　　3.5 所有主機組

　　在圖1 3 - 3中，我們看到了路由器的IGMP查詢被送到目的IP位址224.0.0.1.該位址被稱為所有主機組位址。它涉及在一個實體網絡中的所有具備多點傳播能力的主機和路由器。當接口初始化後，所有具備多點傳播能力接口上的主機均自動加入這個多點傳播組。這個組的成員無需發送IGMP報告。

4 、一個例子

　　現在我們已經了解了一些IP多點傳播的細節，再來看看所包含的資訊。我們使sun主機能夠支援多點傳播，并将采用一些多點傳播軟體所提供的測試程式來觀察具體的過程。

　　首先，采用一個經過修改的netstat指令來報告每個接口上的多點傳播組成員情況（在3.9節顯示了netstat-ni指令的輸出結果）。在下面的輸出中，用黑體表示有關的多點傳播組。

IGMP（Internet組管理協定）封包及協定（圖四）

　　其中， - n參數将以數字形式顯示IP位址（而不是按名字來顯示它們），- i參數将顯示接口的統計結果，- a參數将顯示所有配置的接口。

　　輸出結果中的第2行le0（以太網）顯示了這個接口屬于主機組224.0.0.1（“所有主機”），和兩行位址，後一行顯示相應的以太網位址為：01： 00：5e：00：00：01.這正是我們期望看到的以太網位址，和12 . 4節介紹的位址映射一緻。我們還看到其他兩個支援多點傳播的接口：SLIP接口sl0和回送接口l o 0，它們也屬于所有主機組。

　我們也必須顯示IP路由表，用于多點傳播的路由表同正常的路由表一樣。黑體表項顯示了所有傳往224.0.0.0的資料報均被送往以太網：

IGMP（Internet組管理協定）封包及協定（圖五）

　　如果将這個路由表與9 . 2節中s u n路由器的路由表作比較，會發現隻是多了有關多點傳播的條目。

　　現在使用一個測試程式來讓我們能在一個接口上加入一個多點傳播組（不再顯示使用這個測試程式的過程）。在以太網接口（ 1 4 0 . 2 5 2 . 1 3 . 3 3）上加入多點傳播組2 2 4 . 1 . 2 . 3.執行n e t s t a t程式看到核心已加入這個組，并得到期望的以太網位址。用黑體字來突出顯示和前面n e t s t a t輸出的不同。

IGMP（Internet組管理協定）封包及協定（圖六）

　　我們在輸出中再次顯示了其他兩個接口： s l 0和l o 0，目的是為了重申加入多點傳播組隻發生在一個接口上。

　　圖1 3 - 4顯示了t c p d u m p對程序加入這個多點傳播組的跟蹤過程。

IGMP（Internet組管理協定）封包及協定（圖七）

　　當主機加入多點傳播組時産生第1行的輸出顯示。第2行是經過時延後的IGMP報告，我們介紹過報告重發的時延是1 0秒内的随機時延。

　　在兩行中顯示硬體位址證明了以太網目的位址就是正确的多點傳播位址。我們也看到了源IP位址為相應的s u n主機位址，而目的IP位址是多點傳播組位址。同時，報告的位址和期望的多點傳播組位址是一緻的。

　　最後，我們注意到，正像指明的那樣， TTL是1.當TTL的值為0或1時，tcpdump在列印時用方括号将它們括起來，這是因為TTL在正常情況下均高于這些值。然而，使用多點傳播我們期望看到許多TTL為1的IP資料報。

　　在這個輸出中暗示了一個多點傳播路由器必須接收在它所有接口上的所有多點傳播資料報。路由器無法确定主機可能加入哪個多點傳播組。

5、多點傳播路由器的例子

　　繼續前面的例子，但我們将在s u n主機中啟動一個多點傳播選路的守護程式。這裡我們感興趣的并不是多點傳播選路協定，而是要研究所交換的IGMP查詢和報告。即使多點傳播選路守護程式隻運作在支援多點傳播的主機（sun）上，所有的查詢和報告都将在那個以太網上進行多點傳播，是以我們在該以太網中的其他系統中也能觀察到它們。

　　在啟動選路守護程式之前，加入另外一個多點傳播組224.9.9.9，圖13-5顯示了輸出的結果。

IGMP（Internet組管理協定）封包及協定（圖八）

　　在這個輸出中沒有包括以太網位址，因為已經證明了它們是正确的。也删去了TTL等于1的說明，同樣因為它們也是我們期望的那樣。

　　當選路守護程式啟動時，輸出第1行。它發出一個已經加入了組224.0.0.4的報告。多點傳播位址224.0.0.4是一個知名的位址，它被目前用于多點傳播選路的距離向量多點傳播選路協定DVMRP（Distance Vector Multicast Routing Protocol）所使用（DVMRP在RFC 1075中定義[Waitzman ，Partridge， and Deering]）。

　　在該守護程式啟動時，它也發送一個IGMP查詢（第2行）。該查詢的目的IP位址為224.0.0.1（所有主機組），如圖13-3所示。

　　第一個報告（第3行）大約在5秒後收到，報告給組224.9.9.9.這是在下一個查詢發出之前（第4行）收到的唯一報告。當守護程式啟動後，兩次查詢（第2行和第4行）發出的間隔很短，這是因為守護程式要将其多點傳播路由表盡快建立起來。

　　第5、6和7行正是我們期望看到的：sun主機針對它所屬的每個組發出一個報告。注意組224.0.0.4是被報告的，而其他兩個組則是明确加入的，因為隻要選路守護程式還在運作，它始終要屬于組224.0.0.4.

　　下一個查詢位于第8行，大約在前一個查詢的2分鐘後發出。它再次引發三個我們所期望的報告（第9、10和11行）。這些報告的時間順序與前面不同，因為接收查詢和發送報告的時間是随機的。

　　最後的查詢在前一個查詢的大約2分鐘後發出，我們再次得到了期望的響應。