首先说为什么要兼容ping呢？作为汇聚分流设备，我们是运行在二层的环境下的。但是如果想和三层交换机互相发送流量呢？那我们就要能够对三层交换机发送来的PING包做响应。Tofino--目前最先进的可编程设备之一（非常严谨），那兼容的IPV6的ping不是简简单单？好吧，其实并没有想的那么简单。ipv6协议虽然走的也是icmp,但是又不太相同于ipv4下的arp / icmp这两套简单的东西，而是在icmpv6的基础下重新搞出来了一套ICMPV6协议，在此基础下兼容了很多很多的功能，我们在这就简单关注以下几个协议：
-
NS（Neighbor Solicitation）：邻居请求报文
-
NA（Neighbor Advertisement）：邻居通告报文
给大家推荐几篇介绍的比较好的文章：
简单阅读后呢我们可以大致了解下ping6的交互过程，首先就是取代了ARP的部分，NS/NA。在你ping一个ip时，如果在邻居表中没有查找到这个ip所对应的mac地址的话,那么发起ping命令的客户端就会封装NS报文，其中的dmac dip分别是被请求节点的组播MAC/IP，ICMPV6中的Targe Address是不知到Mac的IP,ICMPV6 Options字段中携带了链路层的一些状态。
?
?
那么怎么就知道这个ping包就是我们要响应的呢？常规来说需要确保组播MAC/组播IP都是当前节点需要处理的且Target Address是我们才去处理。那么这个条件到了P4的Table-Action中我们就可以流氓一点的抽象为：
Key:Target Address
Key:icmp type
当我们匹配到了NS报文，且NS报文中的Target Address是我们我们才去响应这个包。
那么第二个问题来了，我们该如何去响应这个报文？不同于CPU处理的报文，交换芯片想要生成一个报文可没有那么简单，虽然也不是没有办法，但是完全没有必要。那么我们要生成一个报文的最简单的办法就是--把原包给改成我们想要的总类。我们观测下正常的ping6过程中的回包，长什么样子呢？
?
?简单观察，大体结构上长的和NS的包差不多，主要有以下几种变化：
- 目的IP/MAC变为请求端的MAC/IP，源MAC/IP变为自己的MAC/IP
- ICMPV6 TYPE变为136（NA)
- Flags中的Solicitied/override被置位
- Options字段中的Type变为2，同时其中的Link Address变为自己的MAC。
了解了以上几点就简单了，再思考下？对于一个伪二层的设备我们如何实现拥有一个自己的MAC/IP呢？结合到上文中提到的抽象出来的Table-Action，Table的Key有了，那Table的Action是不是就可以把这个MAC/IP赋值到对应的地方呢。很显然这是可以的，这样我们就伪装出来了一个属于自己的IPV6/MAC地址。对端设备可不会管你是不是真有IP/MAC，他只认包。嘿伙计，我们是个三层设备，我们能响应你的PING，于是他就开开心心把流量扔过来了。
你以为这样就结束了吗？不还没有，我们还有一个很重大的问题没有解决，那就是ICMPV6中的checksum。不同于ARP中的Checksum,由于ARP响应中的字段变换比较固定，我们可以通过请求包的Checksum反推响应包的checksum。一般是在request的上+0x100（不考虑翻转情况下）。在ICMPV6中，CheckSum的计算可是要带上IPV6的Src Dst的。那事情就变的困难了起来。Tofino何德何能能够把IPV6的字段拿来参与计算啊。如果只是个简简单单的加减法那还好说，但是CheckSum的计算可是要稍微复杂一内内的。所以呢，这个工作我们就请CPU来做吧。
在我们修改好了ICMPV6的所有字段将其变为一个NA包后，我们将这个报文打上一层CPU头部，其中包含了Reason，Inport。告诉CPU，这个包是哪种类型为什么要你处理，这个包是从哪个入口进来的。CPU收到这个包之后进行校验，然后在CPU头上的Out port字段给上需要的出口。交换芯片收到这个包解析出来了了出口就根据这个出口进行对应的转发就好啦。如此我们就完成了一个完整的ICMPV6 NS的响应。
完成了响应之后在客户端上就能看到对应的邻居信息了。那么下一步就是发送ping 请求包了。这个于icmp v4的请求基本上类似。我们同样也只需要满足目的IP是我们，且类型是request。那就改下源目的IP,源目的MAC给他回过去就好了。
完整的请求与响应：
?
服务端看到的：
?