距離以該速率開始新流程還有幾天時間 來自奧圖斯。 在這方面，我們想與您分享有關該主題的有用材料的翻譯。
有關解決 IPv6 ping 問題的提示和技巧的一系列部落格文章（ICMPv6 回顯請求/回顯回應）
請注意，我使用的是 Linux（特別是 Fedora 31），但其他作業系統的 ping 命令語法應該非常相似。
Ping 頻道上的所有 IPv6 節點
第一個也是最簡單的技巧是對鏈路上的所有 IPv6 節點執行 ping 操作。
IPv6 使用多播位址進行所有類型的一對多通訊。 沒有廣播（或廣播）IPv6 位址。 這將 IPv6 與 IPv4 區分開來，後者有多種類型的廣播位址，例如「有限廣播」位址 255.255.255.255 [RFC1122]。
然而，有一個「全節點多播」IPv6 位址，因此我們將使用它來 ping 連結上的所有 IPv6 節點。 （「廣播」位址實際上只是一個專門命名的多播位址，它是一個包括所有節點的多播群組。注意，例如，乙太網路廣播位址中的「群組」或多播位址位元在連結層打開）。
通道的全節點組播 IPv6 位址： ff02::1. ff 表示組播 IPv6 位址。 接下來的 0 是標誌中未設定位的部分。
進一步 2 定義多播組的區域。 與組播 IPv4 位址不同，組播 IPv6 位址具有範圍。 範圍值指示允許轉送多播封包的網路部分。 一旦資料包到達指定範圍的邊界，無論其跳數字段是否非零，都必須丟棄該資料包。 當然，如果跳數在到達指定的多播組邊界之前就達到零，也會立即重設。 以下是 IPv6 多播範圍的完整清單。
最後，該 ::1 指定全節點組播群組。
關於地址 ff02::1 需要注意的是，它是有歧義的。 在具有多個介面的 IPv6 主機（例如路由器或多宿主主機）上，位址 ff02::1 您無法指定向哪個介面發送 ICMPv6 回顯請求或期望在 ICMPv6 回顯回覆到達時收到它們。 ff02::1 有效並且可以在連接到多介面節點的任何介面和通道上使用。
因此，當我們 ping 鏈路上的所有 IPv6 節點時，我們還需要以某種方式告訴實用程式 ping 對於 IPv6，使用哪個介面。
定義介面 - 命令列選項
正如我們已經看到的，我們想要使用的全節點多播位址是 - ff02::1 - 不提供任何關於哪個介面發送和接收 ICMPv6 回顯請求和回顯應答資料包的資訊。
那麼，我們如何指定用於多播位址空間或單播鏈路本地位址空間的介面呢？
第一種也是最明顯的方法是將其作為參數提供給我們正在使用的應用程式。
為了實用 ping 我們透過選項提供 -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$使用此全節點多播 ping，我們收到了來自 6 個 IPv6 節點的回應。 回應來自連結本地 IPv6 節點位址，以前綴開頭 fe80::/10.
該 ping 不會無限期地繼續發送 ICMPv6 echo 請求，直到我們中斷它，我們通常透過 -c 選項指定要傳送的封包數量。 但是，這也會阻止 ping 在發送多播 ICMPv6 回顯請求時接受和顯示多個 ICMPv6 回顯回應。 相反，我們使用 -w 選項指定 ping 應在 1 秒後完成，無論發送或接收了多少 ICMPv6 回顯請求或回顯回應。
另外要注意的是（DUP!）輸出第二個及後續答案。 這些封包被識別為重複回應，因為它們與首先發送的各個 ICMPv6 回顯請求具有相同的 ICMP 序列值。 它們出現是因為 ICMPv6 多播回顯請求會導致多個單獨的單播回應。 統計摘要中也指出了重複項的數量。
定義介面 - 區域 ID
公開介面以供使用的另一種方法是作為 IPv6 位址參數的一部分。
我們可以在 ping 輸出中看到這樣的範例，其中回應的 IPv6 主機的位址也具有後綴 %enp3s2例如：
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms這種指定介面的方法在 [RFC4007]「IPv6 定義的位址架構」中正式描述。 儘管它們通常被稱為作業系統接口，但它們實際上定義了更通用的東西——“區域”或“範圍”。
具有更通用區域或範圍區域的原因是，如 [RFC4007] 中所述，IPv6 節點可以有多個連接到相同通道的不同 IPv6 介面。 這些介面是同一區域的成員。
應該可以在作業系統下將多個介面分組到一個區域內； 目前我不知道這在 Linux 下是否可行或如何做到。
使用後綴 %<zone_id>，我們可以刪除命令列選項 -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$鏈路本地地址回應
從這個全節點多播 ping 中，我們總共收到了 6 個獨特的回應。
這些回應來自單播鏈路本地 IPv6 主機位址。 例如，這是第一個答案：
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms所有啟用 IPv6 的介面都需要單播鏈路本地 IPv6 位址 [RFC4291]，「IP 版本 6 尋址架構」。 原因是 IPv6 節點始終自動具有單播 IPv6 位址，它至少可以使用該位址與其直接連接的鏈路上的其他節點進行通訊。 這包括透過本機鏈路主機位址與其他主機上的應用程式進行通訊。
這簡化了 IPv6 鄰居發現和 OSPFv3 等協定的設計和實作。 它還允許主機上的最終用戶應用程式透過通道進行通信，而無需通道上任何其他支援 IPv6 基礎設施。 連接的 IPv6 主機之間的直接通訊不需要連接上的 IPv6 路由器或 DHCPv6 伺服器。
鏈路本地地址以 10 位元前綴開頭 fe80，後面跟著 54 個零位，然後是 64 位元介面標識符 (IID)。 在上面第一個答案中 2392:6213:a15b:66ff 是 64 位元 IID。
循環組播
預設情況下，多播資料包在內部返回到發送它們的節點。 IPv6 和 IPv4 尋址都會發生這種情況。
這種預設行為的原因是，當發送多播封包時，發送主機本身以及網路上的某個位置也可能有一個偵聽本機多播應用程式正在執行。 該本地應用程式還必須接收多播資料包。
我們可以在 ping 輸出中看到這個多播本地循環：
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...第一個也是最快的響應（0,106 毫秒與 0,453 毫秒相比）來自介面本身配置的鏈路本地位址 enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$效用 ping 提供了一種使用參數抑製本地多播回饋的方法 -L。 如果我們發送帶有此標誌的所有節點多播 ping，則回應僅限於遠端節點。 我們沒有收到來自發送介面的鏈路本地地址的回應。
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping 連結本地位址
正如您可能猜到的那樣，單播鏈路本地地址本身也沒有提供足夠的資訊來指示使用哪個介面來存取它們。 與全節點多播 ping 一樣，我們還需要將介面指定為命令列參數 ping 或在 ping 連結本地地址時帶有地址的區域 ID。
這次我們可以使用 -c限制發送和接收的資料包和回應的數量 ping，因為我們正在執行單播 ping。
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping（所有）其他 IPv6 位址？
在本文中，我們了解如何使用全節點多重播送 IPv6 位址 ping 通道上的所有 IPv6 節點 ff02::1。 我們也了解如何指定與全節點多播 IPv6 位址一起使用的接口，因為該位址本身無法提供此資訊。 我們使用命令列選項 ping，或使用後綴指定接口 %<zone_id>.
然後我們了解了單播鏈路本地位址，它是用於回應全節點多播ICMPv6 echo請求的位址。
我們還了解了預設情況下多播資料包如何返回到發送節點以及如何為該實用程式停用此功能 ping.
最後，我們使用後綴 ping 單一鏈路本地地址 %<zone_id>，因為本地鏈路位址本身也不提供有關傳出介面的資訊。
那麼，如何 ping 所有其他節點並獲取它們的全域單播位址 (GUA)（即它們在 Internet 上的公共位址）或其唯一的本地單播位址 (ULA)？ 我們將在下一篇部落格文章中討論這一點。
這就是全部。
您可以在以下位置找到有關我們課程的更多信息.
來源： www.habr.com