單元 15 多播跨網段與服務探索

學習目標與問題

先讀 06 的群組位址、MAC 對映與成員管理，08 的 DNS 記錄與 TTL，09 的 UDP，13 的路由，以及 14 的 IPv6 位址與 NDP。本單元把 06 的同鏈路模型延伸到 IPv6、跨網段多播與服務探索。完成後應能說明 MLD 與來源篩選、判斷多播何時需要路由與 RPF 檢查、追蹤 DNS-SD 的記錄鏈，並定位「能以 IP 連線卻找不到印表機」的問題。故障表中的 ACL 與防火牆見 16；VPN 開啟後的探索變化見 §27.6。

問題：印表機在另一個 VLAN，用 IP 可以連上，為何列表找不到它？

15.1 IPv6 多播、成員管理與來源篩選

IPv6 沒有 broadcast 位址，以不同 scope 的 multicast 等機制完成相關功能。NDP 是 ICMPv6，鄰居解析常送 solicited-node multicast；IGMP／MLD 管理接收成員，不能替 ARP／NDP 找單播鄰居。例：鄰居要解析 14 的 2001:db8:10::abcd 時送往 ff02::1:ff00:abcd，該主機因此加入這個群組。

IPv6 群組位址由 ff00::/8 開始，含 scope 欄位；ff02 是 link-local scope，不能只看它是 IPv6 就當作全球可路由。IPv6 通常對映到 33:33 加目的位址低 32 bits，也可能別名。上例群組的 MAC 是 33:33:ff:00:ab:cd。

IGMPv3 用於 IPv4，MLDv2 用於 IPv6 且屬 ICMPv6，兩者都支援來源篩選。ASM（any-source multicast）以群組 G 識別服務，接收送往 G 的任意來源，可再排除部分來源；SSM（source-specific multicast）以 (S,G) 識別通道，只接收指定來源 S 送往 G 的流量。來源篩選是協定能力，不等同 ASM／SSM 的定義本身。group membership 不提供密碼學身分驗證，也不代替防火牆。

延伸：現行規範 RFC 9776／9777 於 2025 年分別取代 3376／3810，協定仍是 IGMPv3／MLDv2。部署可能使用較早版本，snooping 支援也需看設備；不要因 RFC 號更新就宣稱所有交換器已支援新版功能。

15.2 多播跨網段需要另一層設計

同 VLAN 的橋接不減少 IP TTL／Hop Limit；路由轉送則要處理跳數與 scope。snooping 不建立跨 VLAN 多播路徑。若目標是跨子網送同一資料流，需合適的多播路由、接收成員、來源路由、RPF 檢查及安全政策；PIM 是常見控制協定家族，不等於所有多播部署都必須用 PIM。

RPF（reverse path forwarding）檢查拿來源位址查往來源的路由，通常就是 13 的單播路由：封包要從往來源的介面進來，才往下游複製，以免迴路。例：R 往 203.0.113.0/24 走介面 1；S=203.0.113.9 送往 G 的封包從介面 1 進來才轉送，從介面 2 進來則不轉送。

許多服務探索採本鏈路 scope；即使網路支援一般多播路由，也不代表能直接轉送這些探索訊息。AP 的多播轉單播、用戶端隔離、無線省電／速率策略會改變鏈路現象。先描述自己的 VLAN 與 AP 模式，再解讀擷取。

15.3 mDNS 與 DNS-SD：發現不等於連得上

mDNS 將本鏈路名稱查詢／回覆送到 224.0.0.251 或 ff02::fb 的 UDP 5353；.local 是重要的本地名稱空間。協定也包含可要求單播回覆等情況，所以看到單播 UDP 5353 不必立即判定異常。IP TTL／Hop Limit 與 DNS record TTL 是不同欄位，前者管封包跳數，後者管記錄快取。

DNS-SD 描述如何用 DNS 記錄尋找服務：PTR 列出服務實例，SRV 給主機與埠，TXT 提供屬性，A／AAAA 得到位址。它可使用 mDNS，也可用普通單播 DNS；不能把 DNS-SD 與 mDNS 當同義詞。

PTR 的資料是另一個名稱，常用於由位址反查名稱；DNS-SD 用它由服務型別列出實例。SRV 給出實例的主機名、埠，以及優先順序與權重。記錄鏈因此是 PTR→SRV／TXT→A／AAAA，每筆都帶有 08 介紹的 TTL；裝置未送告別訊息就離線時，舊實例可能留在列表直到過期。

例：查詢 _ipp._tcp，PTR 得到「Lab Printer」實例，SRV 指向 printer.local:631，TXT 描述能力，再查 A／AAAA 並連線。探索訊息使用多播，不表示列印資料也用多播；後續連線可能是單播 TCP，且仍需路由、ACL 與服務端接受。

現象	優先蒐集的證據
手動 IP 可連但列表沒有印表機	VLAN、5353 收送、AP 隔離、服務廣告與快取
列表有實例但連線失敗	SRV 埠、A/AAAA 可達、服務、防火牆與名稱驗證
跨 VLAN 突然能發現大量裝置	reflector／gateway 的範圍、允許服務與信任邊界

跨 VLAN 可評估 mDNS reflector 或具政策的 discovery gateway，或改用單播 DNS-SD；它們有不同快取、可見範圍與實作限制。

不要將看見服務廣告視為端點可信；完成連線後的名稱／憑證驗證與存取控制仍是獨立工作。

延伸：RFC 6762 §11 建議 mDNS 回應（含單播回應）以 IP TTL／Hop Limit 255 發送，以相容早期實作。對送往本鏈路目的位址的查詢，查詢端須只接受本鏈路回應：送至 224.0.0.251／ff02::fb 的回應視為來自本鏈路；單播回應另檢查來源是否屬於本地子網／on-link 前綴。本鏈路限制不靠把 TTL 設成 1。

實驗、習題與檢核

做 L16 階段二：B5 的 IPv6 scope 與控制政策、C 的離線服務探索工作表，以及 D 延伸中的 UDP 5353 與 IPv6 檢查。C 的記錄可對照 L04 的 DNS 訊息格式；工作表是人工資料，不是擷取記錄。Linux bridge 觀察是延伸，未列為本機實測。

分析：snooping 與 querier 都正常，VLAN 20 的接收者為何仍可能收不到 VLAN 10 送出的 G？多播路由與 RPF 檢查各補上什麼？
基本：某 NAS 以 DNS-SD 公告網頁服務。從查詢 _http._tcp.local 到建立連線，依序寫出每一步查詢的名稱、記錄型別與得到的資料。
分析：上一題的 NAS 在探索列表中顯示為「Home NAS」時，哪些事已有證據、哪些還沒有？
分析：印表機跨 VLAN 可 ping 卻未顯示列表，提出兩個可區分假設及證據。
基本：已發現 printer.local:631 但 HTTPS 名稱驗證失敗，發現成功能否取代身分驗證？

檢核：能分開記錄群組與 scope、跨網段的路由與 RPF、PTR／SRV／TXT／A／AAAA、應用實例與實際連線；知道 L16 的模型未實作 MLD、PIM 與 mDNS 封包。

來源（查閱 2026-10-06；RFC 2782、RFC 7761 查閱 2026-10-21）：RFC 2464、RFC 4291、RFC 9776 IGMPv3、RFC 9777 MLDv2、RFC 4607 SSM、RFC 7761 PIM-SM、RFC 6762 mDNS、RFC 6763 DNS-SD、RFC 2782 SRV。