IGMPv1：IP 組播的主機擴展

IP 組播是將 IP 數據報傳輸到“主機組/host group”，即由單個 IP 目標地址標識的零個或多個主機的集合。組播數據報以與常規單播 IP 數據報相同的“盡力而為/best-efforts”可靠性傳送到其目標主機組的所有成員，即，不能保證數據報完整地到達目標組的所有成員或以相同的順序到達相對💞于其他數據報。

主機組的成員資格是動態的；也就是說，主機可以隨時加入和離開組。對主機組中成員的位置或數量沒有限制。一個主機一次可能是多個組的ও成員。主機不需要是組的成員就可以向它發送數據報。

主機組可以是永久的🌸或臨時的。永久組具有眾所周知的管理分配的 IP 地址。永久的是地址，而不是組的成員；在任何時候，一個永久組可能有任意數量ꦆ的成員，甚至為零。那些不為永久組保留的 IP 組播地址可用于動態分配給臨時組，只要它們有成員就存在。

IP 組播數據報的互聯網轉發由“組播路由器/multicast routers”處理，該路由๊器可能與互聯網網關共存或分離。主機將 IP 組播數據報作為本地網絡組播傳輸，該數據報到達目標主機組的所有緊鄰成員。如果數據ไ報的 IP 生存時間大于 1，則連接到本地網絡的組播路由器負責將其轉發到具有目標組成員的所有其他網絡。在 IP 生存期內可達的其他成員網絡上，附加的組播路由器通過將數據報作為本地組播傳輸來完成交付。

本備忘錄指定了主機 IP 實現所需的擴展以支持 IP 組播，其中“主機/host”是除充當組播路由器的主機或網關之外的任何 Internet 主機或網關。組播路由器內部和之間使用的算法和協議對主機是透明的，并將在單獨的文檔中指定。本備忘錄也沒有指定如何為所有類型的網絡實現本地網絡組播，💧盡管它指定了任意本地網絡所需的服務接口，并以以太網規范為例。其他類型網絡的規范將成為未來備忘錄的主題。

1. 一致性級別

本規范的一致性分為三個級別：

級別0：不支持 IP 組播。

目前，沒有要求所有 IP 實現都支持 IP 組播。級別0主機通常不受組播活動的影響。唯一的例外出現在某些類型的本地網絡上，其中級別1或級別2主機的存在可能導致組播 IP 數據報錯誤傳送到級別0主機。此類數據報可以通過其目標地址字段中存在的 D 類 IP 地址輕松🌄識別；它們應該被不支持 IP 組播的主機悄🍸悄丟棄。D 類地址在本備忘錄的第 4 節中描述。

級別1：支持發送但不接收組播 IP 數據報。

級別ꦍ 1 允許主機參與一些基于組播的服務，例如資源位置或狀態報告，但不允許主機加入任何主機組。IP 實現可以很容易地從級別0꧙升級到級別1，并且幾乎不需要新代碼。只有本備忘錄的第 4、5 和 6 節適用于級別1實現。

級別2：完全支持 IP 組播。

級別2允許主機加入和離開主機組，以及向主機組發送 IP 🦩數據報。它需要實施互聯網組管理協議 (Internet Group Management Protocol，IGMP) 并擴展主機內的 IP 和本地網絡服務接口。本備忘錄的以下所有部分都適用于級別2實現。

2、 主機組地址

主機組由 D 類 IP 地址標識，♏即以“1110”作為其高四位的那些。E 類 IP 地址，即那些以“1111”作為其高四位的地址，保留用于將來的尋址模式。

在 Internet 標準的“點分十進制”表示法中，主機組地址的范圍從 224.0.0.0 到 239.255.255.255。地址224.0.0.0保證不分配給任何組，224.0.0.1分配給所有IP主機（包括網關）的永久組。﷽這用于尋址直連網絡上的所有組播主機。整個 Internet 上的所有主機都沒有組播地址（或任何其他🍰 IP 地址）。其他著名的永久團體的地址將在“指定號碼”中公布。

附錄2包含一些與主機組地址相關的幾個問題的背景討論。

3、 主機 IP 實現模型

主機 IP 實現的組播擴展是根據下面所示的分層模型指定的。在這個模型中，ICMP和（對于級別2主機）I🌌GMP被認為是在IP模塊內部實現的，IP地址到本地網絡地址的映射被認為是本地網絡模塊的職責。此模型僅用于說明目的，不應被解釋為限制實際實現。

要提供級別1組播，主機 IP 實現必須支持組播 IP 數據報的傳輸。要提供級別2組播，主機還必須支持組播 IP 數據報的接收。這兩個新﷽服務中的每一個都在下面的單♛獨部分中進行了描述。對于每個服務，為IP 服務接口、IP 模塊、本地網絡服務接口和以太網本地網絡模塊指定了擴展。對以太網以外的本地網絡模塊的擴展被簡要提及，但沒有詳細說明。

4、 發送組播 IP 數據報

4.1、 IP 服務接口的擴展

使用與發送單播 IP 數據報相同的“發送 IP”操作發送組播 IP 數據報；上層協議模塊只是指定一🔯個IP主機組地址，而不是一個單獨的IP地址作為目的地。然而，一些擴展可能是必要的或可取的。

首先，服務接口應該為上層協議提供一種方法來指定傳出組播數據報的 IP 生存時間，如果這種能力尚不存在。如果上層協議選擇不指定生存時間，則對于ꦰ所有組播 IP 數據報應默認為 1，因此需要明ꦺ確選擇以超出單個網絡進行組播。

其次，對于可能連接到多個網絡的主機，服務接口應該為上層協議提供一種方法來識別哪個網絡接口用于組播傳輸。初始傳輸只使用一個接口；如有必要，組播路由器負責轉發到任何其他網絡。如果上層協議選擇不標識出接口，則應使用默認接✅口，最好在系統管🧸理的控制下。

第💫三（僅限級別2實現），對于主機本身是數據報發送到的組的成員的情況，服務接口應該為上層協議提供一種方法來禁止本地傳輸數據報;默認情況下，數據💛報的副本被環回。這是對上層協議的性能優化，這些協議將組的成員資格限制為每個主機一個進程（例如路由協議），或者在較高層處理組通信的環回（例如組播傳輸協議）。

4.2、 IP 模塊的擴展

為了支持組播 IP 數據報的發送，必須擴展 IP 模塊以在路由傳出數據報🏅時識別 IP 主機組地址。大🤡多數 IP 實現包括以下邏輯：

如果 IP-destination 在同一本地網絡上，則將數據報本地發送到 IP-destination；𒉰否則，將數據報本地發送到 GatewayTo( IP-destination )。

要允許組播傳輸，必須將路由邏輯更改為：

如果 IP-destination 在同一個本地網絡上✨或 IP-destination 是一個主機組，則將數據報本地發送到 IP-destination；否則，將數據報本地發送到 GatewayTo( IP-destination )。

如果發送主機本身是傳出接口上目標組的成員，則傳出數據報的副本必須環回本地傳遞，除非被發送方禁止。（僅限級別2實現。）傳出數據報的 IP 源地址必須是對應于傳💦出接口的單個地址之一。

主機組地址絕不能放置在源地址字段中，或者位于傳出 IP 數據報的源路由或記錄路由選項中的任何位置。

4.3、 本地網絡服務接口的擴展

無需更改本地網絡服務接口即可支持組播 IP 數據報的發送。當 IP 模塊調用現有的“發送本地”操作時，它๊僅指定 IP 主機組目的地，而不是單個 IP 目的地。

4.4、 以太網本地網絡模塊的擴展

𒁏以太網通過在以太網數據包的目的字段中允許組播地址來直接支持本地組播數據包的發送。支持組播 IP 數據報發送所需的只是將 IP♍ 主機組地址映射到以太網組播地址的過程。

通過將 IP 地址的低 23 位放入以太網組播地址 01-00-5E-00-00-00（十六進制）的低 23 位，將 IP 主機組地址映🌜射到以太網組播👍地址）。由于 IP 主機組地址有 28 位有效位，多個主機組地址可能映射到同一個以太網組播地址。

4.5、 對以太網以外的本地網絡模塊的擴展

其他直接支持組播的網絡，例如符合 IE💦EE 802.2 標準的環網或總線，為了發送組播 IP 數據報，可以采用與以太網相同的方式進行處理。對于支持廣播但不支持組播的網絡，例如實驗以太網，所有 IP 主機組地址都可以映射到單個本地廣播地址（以增加所有本地主機的開銷為代價）。對于連接兩臺主機（或一臺主機和一個組播路由器）的點對點鏈路，組播應該像單播一樣傳輸。對于像 ARPANET 這樣的存儲轉發網絡或公共 X.25 網絡，所有 IP 主機組地址都可能映射到 IP 組播路由器的眾所周知的本地地址；這種網絡上的路由器將負責完成網絡內以及網絡之間的組播傳送。

5、 接收組播 IP 數據報

5.1、 IP 服務接口的擴展

上層協議模塊使用與正常單播數據報相同的“接收 IP”操作來接收傳入的組播 IP 數據報。目的上層協議的選擇是基于IP頭中的🅘協議字段，與目的IP地址無關。但是，在可以接收任何發往特定組的數據報之前，上層協議必須要求 IP 模塊加入該組。因此，必須擴展 IP 服務接口以提供兩個新操作：

JoinHostGroup（組地址，接口）

LeaveHostGroup（組地址，接口）

JoinHostGroup 操作請求該主機成為給定網絡接口上由“group-address”標識的主機組的成員。LeaveGroup 操作請求該主機放棄其在給定網絡接口上由“group-addres🌞s”標識的主機組中的成員資格。在僅支持一個接口的主機上可以省略 interface 參數。對于可能連接到多個網絡的主機，上層協議可以選擇不指定接口，在這種情況下，請求將應用于發送組播數據報的默認接口（。

🍎允許在多個接口上加入同一組，在這種情況下可能會♌收到重復的組播數據報。也允許多個上層協議請求同一組的成員資格。

兩個操作都應該立即返回（即它們是非阻塞操作），指示成功或失敗。由于組地址或接口標識符無效，任一操作都可能失敗。由于缺少本地資源，JoinHostGroup 可能會失敗。LeaveHostGroup 可能會失敗，因為主機不屬于給定接口上的給定組。LeaveHostG🦩roup 可能會成功，但如果多個上層協議請求同一組中的成員身份，則成員身份會持續存在。

5.2、 IP 模塊的擴展

為了支持組播 IP 數據報的接收，必須擴展 IP 模塊以維護與🥀每個網絡接口關聯的主機組成員資格列表。以這些組之一為目的地的傳入數據報的處理方式與以主機的單個地址之一ꦏ為目的地的數據報完全相同。

發往主機不屬于的組的傳入數據報將被丟棄，而不會生成任何錯誤報告或日志條目。在具有多個網絡接口的主機上，如果數據報通過一個接𒈔口到達，而目的地是該主機所屬的組，但僅在不同的接口上，該數據報將被悄悄丟棄。（這些情況只會發生在本地網絡模塊中組播地址過濾不充分的結果。）傳入的數據報不會因為 IP 生存時間為 1 而被拒絕（即，生存時間不應在未轉發的到達數據報上自動遞減）。在其源地址字段中包含 IP 主機組地址的傳入數據報將被悄悄丟棄。響應發往 IP 主機組的數據報，從不生成 ICMP 錯誤消息（目標不🦩可達、超時、參數問題、源抑制或重定向）。

響應來自上層協議的 JoinHostGroup 和 LeaveHostGroup 請求，更新主機組成員資格列表。每個成員都應該有一個關聯的引用計數或類似的機制來處理多個加入和離開同一個組的請求。在給定接口上的第一個加入請求和最后一個離開組的請求時，該接口的本地網✃絡模塊會收到通知，以便它可ꦫ以更新其組播接收過濾器。

IP ജ模塊還必須擴展以實現 IGMP 協議♈，在附錄1中指定。IGMP 用于使相鄰組播路由器了解特定本地網絡上存在的主機組成員資格。為了支持 IGMP，每個級別2主機必須在初始化時加入每個網絡接口上的“所有主機”組（地址 224.0.0.1），并且只要主機處于活動狀態，就必須保持成員身份。

（尋址到所有主機組的數據報被組播路由器識別為一種特殊情況并且永遠不會轉發到單個網絡之外，無論它們的生存時間如何。因此，所有主機地址不能用作互聯網范圍的廣播地址。為了IGMP的目的，只有當主機至少屬于一個其他組時才真正需要所有主機組的成員。但是，指定主機應保持為all-hosts組的成員。主機組一直是因為（1）它更簡單，（2）接收不必要的 IGMP 查詢的頻率應該足ꦰ夠低，開銷可以忽略不計，以及（3）所有主機地址可以用于其他面向路由的目的，例如通告網關的存在或解析本地地址。）

5.3、 本地網絡服務接口的擴展

使用與本地網絡單🔯播數據包相同的“接收本地”操作將傳入的本地網絡組播數據包傳送到 IP 模塊。為了讓 IP 模塊告訴本地網絡模塊接受哪些組播數據包，本地網絡服務接口被擴展以♉提供兩個新的操作：

JoinLocalGroup ( group-address )

LeaveLocalGroup ( group-address )

其中“group-address”是 IP 主機組地址。JoinLocalGroup 操作請求本地網絡模塊接受并傳送隨后到達的以給定 IP 主機組地址為目的地的數據包。LeaveLoඣcalGroup 操作請求本地網絡模塊停止傳送發往給定 IP 主機組地址的數據包。本地網絡模塊應根據需要將 IP 主機組地址映射到本地網絡地址，以更新其組播接收過濾器。任何本地網絡模塊都可以自由地忽略 LeaveLocalGroup 請求，并且如果無法充分過濾傳入的數據包，則可以將數據包發送到比 JoinLocalGroup 請求中指定的地址更多的地址。

本地網絡模塊不得傳送從該模塊傳輸的任何組播數據包；組播的環回在 IP 層或更高層處理。

5.4、 以太網本地網絡模塊的擴展

為了支持組播 IP 數據報的接收，以太網模塊必須能夠接收尋址到與主機的 IP 主機組地址相對應的以太網組播地址的數據包。非常需要利用以太網🔯硬件接口可能具有的任何地址過濾功能，以便主機只接收那些發往它的數據包。

不幸的是，許多當前的以太網接口對硬件可配置為識別的地𝄹址數量有很小的限制。然而，實現必須能夠偵💜聽任意數量的以太網組播地址，這可能意味著在地址數量超過過濾器限制的那些時間段內“打開”地址過濾器以接受所有組播數據包。

對于硬件地址過濾不充分的接口，可能需♏要（出于性能原因）在以太網模塊的軟件中執行以太網地址過濾。但是，這不是強制性的，因為 IP 模塊根據 IP 目標��地址執行自己的過濾。

5.5、 對以太網以外的本地網絡模塊的擴展

其他組播網絡，例如 IEEE 802.2 網絡，可以以與以太網相同的方式處理，以接收組播 IP 數據報。對于純廣播網絡，例如實驗以太網，所有傳入的廣播數據包都可以被接受并傳遞到 IP 模塊進行🦄 IP 級過濾。在點對點或存儲轉發網絡上，組播 IP 數據報將作為本地網絡單播到達，因此無需更改本地網絡模塊。

附錄1、 互聯網組管理協議 (IGMP)

IP 主機使用互聯網組管理協議 (Internet Group Management P𒅌rotocol，IGMP) 將其主機組成員身份報告給任何緊鄰的組播路由器。IGMP 是一種非對稱協議，這里是從主機的角度而不是組播路由器的角度來指定的。（IGMP 也可以在組播路由器之間對稱或非對稱地使用。這種用法在此未指定。）與 ICMP 一樣，IGMP 是 IP 的組成部分。要求所有符合 IP 組播規范級別2的主機都實現。IGMP 消息封裝在 IP 數據報中♛，IP 協議編號為 2。所有與主機相關的 IGMP 消息都具有以下格式：

版本/ Version

本備忘錄規定了 IGMP 的第 1 版。版本 0 在 RFC-988 中指定，現在已過時。

類型/ Type

主機關注的 IGMP 消息有兩種類型：

1 = 主機成員查詢

2 = 主機成員報告

未使用/ Unused

未使用的字段，發送時歸零，接收時忽略。

校驗和/ Checksum

校驗和是 8 字節 IGMP 消息的補碼和的 16 位補碼。為了計算校驗和，校驗和字段被清零。

組地址/ Group Address

在主機成員查詢消息中，組地址字段在發送時為零，在接收時被忽略。

在主機成員報告消息中，組地址字段保存正在報告的組的 IP 主機組地址。

非正式協議說明

組播路由器發送主機成員查詢消息（以下稱為查詢）以發🅠現哪些主機組在其連接的本地網絡上有成員。查⛎詢尋址到所有主機組（地址 224.0.0.1），并攜帶 IP 生存時間為 1。

主機通過生成主機成員報告（以下稱為報告）來響應查詢，在收到查詢的網絡接口上🉐報告它們所屬的每個主機組。為了避免并發報告的“內爆”并減少傳輸的報告總數，使用了兩種技術：

1. 𝐆當主機接收到查詢時，它不是立即發送報告，而是在傳入查詢的網絡接口上為其每個組成員啟動報告延遲計時器。每個計時器都設置為一個不同的、隨機選擇的值，介于 0 和 D 秒之間。當計時器到期時，將為相應的主機組生成報告。因此，報告分散在 D 秒間隔內，而不是同時發生。

2. 發送報告時，IP 目標地址與被報告的主機組地址相同，IP 生存時間為 1，以便同一網絡上同一組的其他成員可以偷聽報告。如果主機在該網絡上聽到其所屬組的報告，則該主機將停止該組自己的計時器，并且不會為該組生成報告。因此，在正常情況下♔，對于網絡上存在的每個組，僅由延遲計時器最先到期的成員主機生成一個報告。請注意，組播路由器接收所有 IP 組播數據報，因此無需明確尋址。進一步注意，路由器不需要知道哪些主機屬于一個組，只需知道至少一個主機ꦓ屬于特定網絡上的一個組。

上述行為有兩個例外。首先，如果在接收到查詢時已經為組成員資格運行報ꦿ告延遲計時器，則該計時器不會重置為新的隨機值，而是允許以其當前ꦓ值繼續運行。其次，永遠不會為所有主機組 (224.0.0.1) 中的主機成員資格設置報告延遲計時器，并且永遠不會報告該成員資格。

如果主機使用偽隨機數生成器來計算報告延遲，則應使用主機自己的單個 IP 地址之一作為生成器種子的一部分，以減少多臺主機生成𒅌相同延遲序列的機會。

主機應確認收到的Report🍌 的IP 目的字段和IGMP 組地址字段中的IP 主機組地址相同，以確保主機自己的Report 不會被錯誤接收的Report 取消。主機應該安靜地丟棄除主機成員查詢或主機成員報告之外的任何類型的 IGMP 消息。

組播路由器定期發送查詢以刷新他們對特定網絡上存在的成員資格的了解。如果在一定數量的查詢之后沒有收到特定組的報告，則路由器假定該組沒有本地成員并且它們不需要將該組的遠程發起的組播轉發到本地網絡。查詢通常很少發送（每分鐘不超過一次），以便將主機和網絡上的 IGMP 開銷保持在非常低的水平。然而，當組播路由器啟動時，它可能會發出幾個緊密間隔的查詢，以便快速建立其對本地成員資格的了𓃲解。

當主機加入一個新組時，它應該立即為該組發送一個報告，而不是等待一個查詢，以防它是網絡上該組的第一個成員。為避免初始報告丟失或損壞ꦍ的可能性，建議在短暫延遲后重復一次或兩次。（實現此目的的一種簡單方法是將其視為僅收到該組的查詢，設置該組的隨機報告延遲計時器。下面的狀態轉換圖說明了這種方法。）請注意，在不存在組播路由器的網絡上，唯一的 IGMP 流量是主機加入新組時發送的一個或多個報告。

狀態轉換圖

下面的狀態轉換圖更正式地指定了 IGMP 行為。對于任何單個網絡接口上的🔴任何單個 IP 主機組，主機可能處于以下三種可能狀態之一：

非成員/ Non-Member狀態，當主機不屬于接口上的組時。這是ℱ所有網絡接口上所有成員的初始狀態；它不需要主機中的存儲。

延⛄遲成員/ Delaying Member狀態，當主機屬于接口上的組并且為該成員運行♛報告延遲計時器時。

空閑成員/ Idle Member狀態，𒆙當主機屬于接口上的組并且沒有為該成員運行的報告延遲計時器時。

有五個重要事件會導致 IGMP 狀態轉換：

當主機決定加入接口上的組時，會發生“加入組/join group”。它可能只發生在非成員狀態。

當主機決定離開接口上的組時，會發生“離開組/leave group”。🤡它可能只發生在延遲成員和空閑成員狀態。

當主機收到有效的 IGMP 主機成員查詢消息時，會出現“查詢收到/query received”。要有效，查詢消息必須至少有 8 個八位字節長，具有正確的 IGMP 校驗和，并且 ♚IP 目標地址為 224.0.0.1。單個查詢適用于接收查詢的接口上的所有成員資格。對于處于非成員或延遲成員狀態的成員，它會被忽略。

當主機收到有效的 IGMP 主機成員報告消息時，會出現“報告收到/report received”。要有效，報🍌告消息必須至少有 8 個八位字節長，具有正確的 IGMP 校驗和，并且在其 IP 目標字段和 IGMP 組地址字段中包含相同的 IP 主機組地址。報告僅適用于在接收報告的界面上由報告確定的組中的成員。對于處于非成員或空閑成員狀態的成員，它會被忽略。

當接口上的組的報告延遲計時器到期時，發生“൩計時器🍌到期/timer expired”。它可能只發生在延遲成員國。

所有其他事件，例如接收無效的 IG꧟MP 消息，或除查詢或報告之外的 IGMP 消息，在所有狀態下都將被忽略。

針對上述事件，可以采取三種可能的行動：

在界面上為組“發送報告/send report”。

接口上組的“啟動計時器/start timer”，使用 0 到 D 秒之間的隨機延遲值。

接口上組的“停止計時器/stop timer”。

在下圖中，每個狀態轉換弧都標有導致轉換的事件，并在括號中標記了在轉換期間采取的任何操作。

all-hosts 組（地址 224.0.0.1）作為特殊情況處理。主機在每個接口上以該組的空閑成員狀態開始，從不轉換到另一個狀態，也從不發送該🙈組的報告。

協議參數

最大報告延遲 D 為 10 秒。

附錄2、 主機組地址問題

本附錄不是 IP 組播規范的一部分，但提供了與 IP 主機組地址相關的幾個問題的背景討論。

組地址綁定

IP主機組地址綁定到物理主機可以認為꧒是IP單播地址綁定的泛化。IP 單播地址靜態綁定到單個 IP 網絡上的單個本地網絡接口。IP 主機組地址動態綁定到一組 IP 網絡上的一組本地網絡接口。

了解 IP 主機組地址不綁定到一組 IP 單播地址很重要。組播路由器不需要維護每個主機組的單個成員的列表。例如，連接到以太網的組播路由器只需要將單個以太網組播地址與具有本地成員的每個主機組相關聯，而不是🧔成員的個人 IP 或以太網地址的ꩵ列表。

臨時主機組地址的分配

本備忘錄沒有指定如何分配臨時組地址。預計 IP 臨時主機組地址空間的不同部分將使用不同的技術進行分配。例如，可能有許多服務器可以聯系以獲取新的臨時組地址。一些更高級別的協議（例如 RFC-1045 中指定的 VMTP）可能會生成更高級別的臨時“進程組”或“實體組”地址，然后通過算法將這些地址映射到 IP 臨時主機組地址的子集，類似于IP 主機組地址映射到以太網組播地址的方式。IP 組地址空間的一部分可能會留出供應🌳用程序隨機分配，這些應用程序可以容忍與其他組播用戶偶爾發生沖突，可能會生成新地址，直到找到🥂合適的“安靜”地址。

通常，主機不能假設發送到任何主機組地址的數據報只會到達預期的主機，或者作為臨時主機組成員接收的數據報是為接收者準備的。必須使用更高級別的標識符或身份驗證令牌在 IP 之上的級別檢測誤投。如果發送者擔心不需要的🔯監聽器，則傳輸到主機組地址的信息應加密或由管理路由控制進行管理。

以上就是IGMPv1：IP 組播的主機擴展的介紹。如果你還有其他問題，歡迎進行咨詢探討，希望億聯云的專業的解決方案，可以解決你目前遇到的問題。億聯云提供主機托管、服務器租用、mpls專線接入、SD-WAN組網等方面的專業服務，資源覆蓋全球。歡迎咨詢。