導語 | 關於ping的原理詳解，網上可以搜索出很多相關內容，而ping6的詳解，則很少看見高質量的文章。希望本文能夠讓更多朋友了解ping6的原理。通過本文你將了解到什么是ICMPV6協議，以及一個完整的ping6過程究竟是怎樣發生的。(本文作者：騰訊雲售后架構師 李彬文)
一、ICMPv6簡介
ICMPv6（Internet Control Message Protocol for the IPv6）是IPv6的基礎協議之一。ICMPv6具備向源地址報告關於向目的地傳輸IPv6數據包過程中的差錯信息和控制信息。
ICMPv6定義了一些消息，如：目的不可達、數據包超長、超時、響應請求和響應應答等。在IPv6中，ICMPv6除了提供ICMPv4常用的功能之外，還有其它一些功能，如鄰接點發現、無狀態地址配置（包括重復地址檢測）、PMTUD等。
二、ICMPv6報文格式
ICMPv6報文格式如下圖所示：
ICMPv6屬於OSI七層協議棧的網絡層，雖然和IPv6屬於同一層，但是封裝時必須先封裝IPv6報文頭部。
ICMPv6字段注釋：
- Type：表明消息的類型，0至127表示差錯報文類型，128至255表示信息報文類型。
- Code：表示此消息類型細分的類型。
- Checksum：表示ICMPv6報文的校驗和。
三、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：擴展頭中出現未知的選項。
四、ICMPv6信息報文
ICMPv6信息報文提供診斷功能和附加的主機功能，比如組播偵聽發現和鄰居發現。
常見的ICMPv6信息報文主要包括回應請求報文（Echo Request）和回應應答報文（Echo Reply），這兩種報文也就是通常使用的Ping6報文。可以分為以下2種：
1. 回應請求報文
回應請求報文用於發送到目標地址，以使目標地址立即發回一個回應應答報文。回應請求報文的Type字段值為128，Code字段的值為0。
2. 回應應答報文
當收到一個回應請求報文時，ICMPv6會用回應應答報文響應。回應應答報文的Type字段的值為129，Code字段的值為0。
五、ping6 完整過程梳理
如下圖所示，雲主機CVM1要和CVM2通信（假設CVM的IPV6地址和VPC已經按文檔https://cloud.tencent.com/document/product/213/40010正常配置且IPV6路由和地址檢查都正常）。
從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的過程就結束了，同樣的道理，其他協議報文也是有這樣的一個封裝和解封裝過程，希望本文能夠讓對大家有所幫助。
