IPv6排障工具之ping6完整過程細節剖析

導語 |關於ping的原理詳解，網上能夠搜索出不少相關內容，而ping6的詳解，則不多看見高質量的文章。但願本文可以讓更多朋友瞭解ping6的原理。經過本文你將瞭解到什麼是ICMPV6協議，以及一個完整的ping6過程到底是怎樣發生的。(本文做者：騰訊雲售後架構師 李彬文)

​1、ICMPv6簡介

ICMPv6（Internet Control Message Protocol for the IPv6）是IPv6的基礎協議之一。ICMPv6具有向源地址報告關於向目的地傳輸IPv6數據包過程當中的差錯信息和控制信息。

ICMPv6定義了一些消息，如：目的不可達、數據包超長、超時、響應請求和響應應答等。在IPv6中，ICMPv6除了提供ICMPv4經常使用的功能以外，還有其它一些功能，如鄰接點發現、無狀態地址配置（包括重複地址檢測）、PMTUD等。

2、ICMPv6報文格式

ICMPv6報文格式以下圖所示：

ICMPv6屬於OSI七層協議棧的網絡層，雖然和IPv6屬於同一層，可是封裝時必須先封裝IPv6報文頭部。

ICMPv6字段註釋：

• Type：代表消息的類型，0至127表示差錯報文類型，128至255表示信息報文類型。
• Code：表示此消息類型細分的類型。
• Checksum：表示ICMPv6報文的校驗和。

3、ICMPv6差錯報文

ICMPv6差錯報文用於報告在轉發IPv6數據包過程當中出現的錯誤，能夠分爲如下4種：

1. 目的不可達錯誤報文

在IPv6中間設備轉發IPv6報文過程當中，當設備發現目的地址不可達時，就會向發送報文的源地址發送ICMPv6目的不可達錯誤報文，同時報文中會攜帶引發該錯誤報文的具體緣由。

目的不可達錯誤報文的Type字段值爲1，根據錯誤具體緣由又能夠細分爲：

Code=0：沒有到達目標設備的路由。

Code=1：與目標客戶端的通訊被管理策略禁止。

Code=2：未指定。

Code=3：目的IP地址不可達。

Code=4：目的端口不可達。

2. 數據包過大錯誤報文

在IPv6中間設備轉發IPv6報文過程當中，發現報文超過出接口的鏈路MTU時，則向發送報文的源地址發送ICMPv6數據包過大錯誤報文，其中攜帶出接口的鏈路MTU值。數據包過大錯誤報文是Path MTU發現機制的基礎。

數據包過大錯誤報文的Type字段值爲2，Code字段值爲0。

3. 時間超時錯誤報文

在IPv6報文收發過程當中，當設備收到Hop Limit字段值等於0的數據包，或者當設備將Hop Limit字段值減爲0時，會向發送報文的源地址發送ICMPv6超時錯誤報文。對於分段重組報文的操做，若是超過定時時間，也會產生一個ICMPv6超時報文。

時間超時錯誤報文的Type字段值爲3，根據錯誤具體緣由又能夠細分爲：

Code=0：在傳輸中超越了跳數限制。

Code=1：分片重組超時。

4. 參數錯誤報文：

當目的節點收到一個IPv6報文時，會對報文進行有效性檢查，若是發現問題會向報文的源地址迴應一個ICMPv6參數錯偏差錯報文。

參數錯誤報文的Type字段值爲4，根據錯誤具體緣由又能夠細分爲：

Code=0：IPv6基本頭或擴展頭的某個字段有錯誤。

Code=1：IPv6基本頭或擴展頭的NextHeader值不可識別。

Code=2：擴展頭中出現未知的選項。

4、ICMPv6信息報文

ICMPv6信息報文提供診斷功能和附加的主機功能，好比組播偵聽發現和鄰居發現。

常見的ICMPv6信息報文主要包括迴應請求報文（Echo Request）和迴應應答報文（Echo Reply），這兩種報文也就是一般使用的Ping6報文。能夠分爲如下2種：

1. 迴應請求報文

迴應請求報文用於發送到目標地址，以使目標地址當即發回一個迴應應答報文。迴應請求報文的Type字段值爲128，Code字段的值爲0。

2. 迴應應答報文

當收到一個迴應請求報文時，ICMPv6會用迴應應答報文響應。迴應應答報文的Type字段的值爲129，Code字段的值爲0。

5、ping6 完整過程梳理

以下圖所示，雲主機CVM1要和CVM2通訊（假設CVM的IPV6地址和VPC已經按文檔https://cloud.tencent.com/doc...）。

從CVM1輸入命令 ping6 2402:4e00:1200:2001::2020 -c 10，輸出的結果以下圖所示：

這是一次成功的ping6測試，可是此次ping6的細節你們也許不太瞭解。接下來咱們主要按OSI協議棧來剖析整個ping6的工做過程以及整個過程會用到的相關報文。

Step1：ICMPv6建立一個56字節的迴應請求： 

Step2：ICMPv6在56字節的請求數據基礎上加上ICMPv6頭部：

迴應請求報文的Type字段值爲128，Code字段的值爲0，而後交給IPv6協議封裝；

Step3：IPv6協議在ICMPv6基礎上增長IPv6頭部：（網絡層封裝）

封裝的源IPv6地址是接口網卡v6地址：2402:4e00:1200:2002::2011

封裝的目標IPv6地址：2402:4e00:1200:2001::2020

Step4：根據目標IPv6地址和本地網段前綴作對比，發現目標地址不屬於本地網段2402:4e00:1200:2002::/64。只能查路由表進行跨網段路由，查找路由表發現沒有匹配的明細路由，最終只能選擇默認路由::/0進行轉發。

Step5：經過默認路由找到能夠經過網卡eth0進行轉發，可是須要數據鏈路層封裝成功後才能從網卡轉發出去。數據鏈路層封裝的源MAC就是出接口eth0的MAC地址，目標MAC地址要從ip -6 neigh 表（相似IPv4的ARP表）中查詢到。

這裏並無學習到目標IPv6地址2402:4e00:1200:2001::2020對應的MAC地址，致使沒法進行數據鏈路層封裝。

Step6：爲了學習到目標地址2402:4e00:1200:2001::2020對應的MAC地址，首先發送NS報文：Type字段值爲135，Code字段值爲0，在地址解析中的做用相似於IPv4中的ARP請求報文。

這裏面存在着兩個問題，下面咱們也會給出相應的解釋：

（1）被請求節點組播IPv6地址FF02::1:FF00:2020如何生成？

IPv6中沒有廣播地址，也不使用ARP。可是仍然須要從IP地址解析到MAC地址的功能。

在IPv6中，這個功能經過鄰居請求NS（Neighbor Solicitation）報文完成。當一個節點須要解析某個IPv6地址對應的MAC地址時，會發送NS報文，該報文的目的IP就是須要解析的IPv6地址對應的被請求節點組播地址，只有具備該組播地址的節點會檢查處理。

被請求節點組播地址由前綴FF02::1:FF00:0/104和目標單播地址的最後24位組成。因爲目標單播地址是2402:4e00:1200:2001::2020,因此生成的被請求節點組播地址是：FF02::1:FF00:2020。

（2）被請求節點組播MAC地址33:33:ff:00:20:20如何生成？

組播MAC地址48bit的前24bit默認固定是33:33:ff，後半部分是被請求節點組播地址的後24bit，因此生成的組播MAC地址是33:33:ff:00:20:20。

Step7：CVM1發送的NS請求報文給到虛擬網關路由器，虛擬網關路由器收到NS報文後查看路由表匹配到路由2402:4e00:1200:2001::/64，代理目標地址回覆一個NA報文：Type字段值爲136，Code字段值爲0，在地址解析中的做用相似於IPv4中的ARP應答報文。

IPv6地址解析示意圖：

學習到目標地址2402:4e00:1200:2001::2020對應的MAC地址是fe:ee:1e:1b:cb:e0。學習到的MAC存入到IPV6鄰居表中：

Step8：回到Step5有了目標IPv6地址2402:4e00:1200:2001::2020對應的MAC地址能夠進行數據鏈路層封裝，而後從網卡eth0發出第一個ICMPv6的迴應請求報文：

從第一個NS到第一個ICMPv6迴應請求的發出順序以下：（CVM1的網卡抓包）

Step9：該回應請求報文到達虛擬網關路由器A後查路由表找到對應的overlay網絡隧道（這裏的虛擬網關和overlay網絡暫不用展開）轉發到目標虛擬網關路由器B，而後由虛擬網關路由器B轉發給CVM2的eth0網卡。

Step10：CVM2的網卡eth0收到迴應請求報文後經過二層幀頭的type字段，確認遞交給IPv6協議處理。

Step11：IPv6協議處理頭部，檢查目標IP正確，檢查下一個協議頭部類型是ICMPv6。

Step12：當收到一個迴應請求報文時，ICMPv6會用迴應應答報文響應。迴應應答報文的Type字段的值爲129，Code字段的值爲0。

CVM2按一樣的方式去查路由表封裝網絡層報文，按Step5到Step7解析到MAC後，查ipv6 鄰居表封裝數據鏈路層的目的MAC。

具體CVM2從收到第一個迴應請求報文到發出第一個迴應應答報文順序以下：

NS報文： 

NA報文：

學習到MAC後發送迴應應答報文：

Step13：該回應應答報文到達虛擬網關路由器B後查路由表找到對應的overlay網絡隧道轉發到目標虛擬網關路由器A，而後由虛擬網關路由器A轉發給CVM1的eth0網卡。

Step14：CVM1和CVM2以及虛擬路由器A和B都已經緩存了對應IPv6地址的MAC，後續封裝無效再發送NS與NA，直接數據鏈路層封裝後路由轉發便可。

CVM1完整的10個ping6報文截圖以下：

CVM2完整的10個ping6報文截圖以下：

CVM1的ping6成功的截圖以下：

到此一次完整的ping6的過程就結束了，一樣的道理，其餘協議報文也是有這樣的一個封裝和解封裝過程，但願本文可以讓對你們有所幫助。

關注「雲加社區」公衆號，回覆「 IP 」，獲取更多IPv6相關內容。