的任何地方。
6.3本地網絡服務接口的擴展
為了支持多播IP數據報的發送，對本地網絡服務接口沒有任何改變。當IP模塊調用現
存的“send local"操作時，只不過指定一個IP主機組目的地址，而不是單個IP目的地址。
6.4以太網本地網絡模塊的擴展
通過允許多播地址出現在以太網分組中的目的地址字段，以太網就能支持本地多播分組
的發送。為了支持多播IP數據報的發送，所需的是一個將IP主機組地址映射到以太網多播
地址的過程。
IP主機組地址映射到以太網多播地址，是通過將IP地址的低23位放在以太網多播地址
01-00-5E-00-00-00(十六進制)的低23位上。因為在IP主機組地址上有28個有意義的位，所
以多個主機組地址可以映射到相同的以太網多播地址上。
6.5 非以太網的本地網絡模塊的擴展
其它的那些本身就支持多播的網絡，例如符合IEEE 802.2標準的環和總線網絡。它們
可以像以太網那樣達到發送多播IP數據報的目的。對于那些支持廣播而不支持多播的網絡，
例如實驗性以太網，所有的IP主機組地址可以被映射為單個本地廣播地址（以增加所有本
地主機費用為代價）。對于連接兩個主機（或者一個主機，一個多播路由器）的一個的點對
點連接，多播應該完全像單播那樣傳遞。對于像ARPANET這樣的存儲轉發網絡，或公共的
X.25網絡，所有IP主機組地址必須映射為IP多播路由器的眾所周知的本地地址；在這些網
絡上路由器負責完成在一個網絡內或所有網絡中的多播傳遞。
7. 接收多播IP數據報
7.1 對IP服務接口的擴展
高層協議使用與接收標準的單播數據報一樣的“Receive IP”操作，接收到來的多播IP
數據報。目的高層協議的選擇由IP首部的協議字段決定，而與目的IP地址無關。然而，在
屬于一個特定組的任意數據報被接收之前，高層協議必須請求IP模塊加入該組。因此，必
須擴展IP服務接口，提供以下兩個操作：
JoinHostGroup(group-address, interface)
LeaveHostGroup(group-address, interface) 
JoinHostGroup操作要求本主機在給定的本地網絡接口上成為以“group-address”標記的
主機組中的成員。LeaveGroup操作要求本主機在給定的本地網絡接口上離開以
“group-address”標記的主機組。如果主機只有一個接口，則interface參數可以省略。對于
屬于多個網絡的主機，高層協議可以不指明interface，這要求使用缺省的interface發送多播
數據報（參看6.1節）。
   允許在多個interface上加入一個相同的組，這種情況下可能會有重復的多播數據報被接
收；也允許多個高層協議要求加入同一個組。
   這兩種操作都立即返回（即它們是非阻塞操作），表示成功或是失敗。每種操作都可能因
為無效的組地址或接口標識符而出錯。JoinHostGroup操作可能由于缺少本地資源而失敗。
LeaveHostGroup可能因為本主機不屬于在給定接口上的某一組而失敗。LeaveHostGroup如
果成功，組成員關系可能還存在，因為可能有多個高層協議是同一個組的成員。
7.2 IP模塊的擴展
為了能夠接收多播IP數據報，必須擴展IP模塊，維持一個與每個網絡接口相關的主機
組成員列表。在到來的數據報中，目的地屬于這些組地址中某一個的數據報的處理方式與目
的地屬于主機的單播地址中某一個數據報的處理方式相同。
如果主機接收到目的地址是組地址的數據報，而該主機不屬于該組，則這個數據報將被
丟棄而不生成任何錯誤或日志記錄。在有多個網絡接口的主機上，如果目的地屬于某一組的
數據報經由一個接口到達，而該主機只在另一個網絡接口上屬于這個組，則這個數據報將被
毫無聲息的丟棄。（ 出現這種情況的唯一原因是本地網絡模塊的多播地址過濾功能不完
善。）
如果到來的數據報的IP生存時間（TTL）為1，則該數據報不會被拒收（即，如果到來
的數據報不會再被轉發，則它的生存時間字段不會自動減少）。如果到來的數據報的源地址
字段出現了IP主機組地址，則該數據報將被毫無聲息的丟棄。ICMP出錯信息（目的主機
不可達，超時，參數問題，源站被抑制，重定向）不會因為目的地為IP主機組的數據報而
產生。
主機組成員列表根據高層協議的JoinHostGroup和LeaveHostGroup操作要求而更新。每
個成員應該有一個相應的參照數或其它同樣的機制，來處理加入和離開同一組的多個要求。
當第一個要求加入和最后一個要求離開在給定接口上的某個組時，那個接口的網絡模塊就被
告知，去更新它的多播接收過濾器（參看7.3部分）。
IP模塊也必須擴展，實現在附錄1中說明的IGMP協議。IGMP是用來讓鄰近的多播路
由器獲知在一個特定的本地網絡中出現的主機組成員。為了支持IGMP，每個2級主機必須
在初始化時加入“所有主機”組（地址為224.0.0.1），而且只要主機是開著的，它都要是這
個組的成員。
（地址是所有主機組的數據報會被多播路由器當成一個特殊情況，不管它的生存時間是
多少，它不會被傳遞出單一的網絡。因此，所有主機地址不用于互聯網范圍上的廣播地址。
為了達到IGMP的目的，屬于所有主機組的這項要求僅僅在主機屬于至少一個其它組時才真
正是必須的。然而，要求主機在任何時候是一個所有主機組的成員的原因是(1)簡單，(2)接
收不必要的IGMP請求的頻率應足夠的低，以使開銷可以忽略不計。(3)所有主機地址可以
用于其它面向路由選路的目的，例如通知網關的存在或解析本地地址）
7.3 對本地網絡服務接口的擴展
把到來的本地網絡多播分組傳遞給IP模塊使用的方式與處理本地網絡單播分組時一
樣，都是使用“Receive Local”操作。為了允許IP模塊通知本地網絡模塊它要接收哪種多
播分組，必須擴展本地網絡服務接口，以提供以下兩個新操作：
JoinLocalGroup(group-address)
LeaveLocalGroup（group-address）
“group-address”是IP主機組地址，JoinLocalGroup操作要求本地網絡模塊接收和向上傳遞
目的地為給定IP主機組地址的分組。LeaveLocalGroup操作要求本地網絡模塊停止向上遞交
目的地為給定IP主機組地址的分組。本地網絡模塊應該能夠映射IP主機組地址到本地網絡
地址，
這是更新本地網絡模塊的多播接收過濾器所要求的。任何本地網絡模塊都可以忽略
LeaveLocalGroup操作的要求。如果它不能充分過濾到來的分組，也可以向上傳遞超出
JoinLocalGroup操作所要求的更多的多播地址的分組。
本地網絡模塊不會向上傳遞任何從該模塊出發的多播分組；多播回送是在IP層或更高
層處理。
7.4 對以太網本地網絡模塊的擴展
為了支持多播IP數據報的接收，以太網模塊必須能接收地址是與主機的IP主機組地址
相關的以太網多播地址的分組。利用以太網硬件接口可能具有的地址過濾能力是非常可取
的，這樣主機只接收目的地指向它的那些分組。
   不幸的是，許多當前的以太網接口對硬件能識別的地址數目有很少的限制。而且，一個
具體的實現必須能偵聽任意數目的以太網多播地址，這意味著當地址數目超過過濾器的限制
時，“打開”地址過濾器以接收所有的多播分組。
   對于那些硬件地址過濾能力不強的接口，為了性能的原因，在以太網模塊的軟件中執行
以太網地址過濾可能要好一些。然而，這并不是強制性的，因為IP模塊基于IP目的地址執
行它自己的過濾。
7.5 對以太網以外的本地網絡模塊的擴展
  像IEEE 802.2網絡這樣的其它多播網絡，為了達到接收多播IP數據報的目的而進行的
處理方式與以太網相同。對于純廣播網絡，如實驗性以太網，所有到達的廣播分組能夠被接
收并傳遞給IP模塊以實現IP層過濾。在點對點或存儲轉發網絡，多播IP數據報以本地網
絡單播的形式到達，所以沒有必要修改本地網絡模塊。
附錄1 INTERNET組管理協議（IGMP）
Internet組管理協議（IGMP）用于IP主機向所有緊鄰的多播路由器報告它們的主機組
成員關系。IGMP是不對稱的協議，將從主機的視角而不是從多播路由器的視角描述它。
（IGMP也可以在多播路由器之間對稱或非對稱的使用。這樣的用法這里沒有指定。）
像ICMP一樣，IGMP是IP的一個組成部分。要在所有符合IP多播規范的2級主機上
實現。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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |版本   | 類型  |    未用       |           校驗和              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        組地址                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
版本
   本備忘錄說明IGMP版本1。版本0在RFC-988中說明，它現在已經廢棄。
類型
   有兩種與主機相關的IGMP報文：
    1=主機成員請求
    2=主機成員報告
未用
     未用字段，在發送時為零，接收時被忽略。
組地址
    主機成員請求報文在被發送時組地址字段為零，被接收時忽略該字段。
    主機成員報告報文中，組地址字段為被報告組的IP主機組地址。

非正式的協議描述
多播路由器發送主機成員請求報文（在下文叫做請求），以發現哪些主機組在它們所屬
的本地網絡上有成員。請求的目的地址為所有主機組（224.0.0.1），攜帶的IP生存時間為1。
主機為了響應一個請求，生成主機成員報告報文，報告它們在接到請求的網絡接口上
所屬的每個主機組。為了避免并發報告“爆炸”，減少被傳送的報告的總數，使用了兩種技
術：
1. 當主機接收到一個請求，不是立即發送報告，而是為到達請求的網絡接口上每個組
成員啟動一個報告延時定時器。每個定時器被設置為在0到D秒之間的一個不同的、隨機
選擇的值。當一個定時器超時，會為相應的主機組產生一個報告。因此，報告的產生時間分
散在D秒的間隔內，而不是都立即產生。
2. 被發送的報告的IP目的地址等于它要報告的主機組的地址，它的IP生存時間為1，
所以在同一網絡上這一組的其它成員能偵聽到該報告。如果主機聽到在那個網絡上它所屬的
組的報告，則主機停止那個組的定時器，不再產生那個組的報告。因此，在通常情況下，僅
僅為出現在網絡上的每個組生成一個報告，這是由延遲定時器最先超時的成員主機生成的。