IPv6 用邻居请求和邻居公告替代ARP.

Technorati 标签: IPv6 arp, IPv6 NDP, ICMPv6 type 135, ICMPv6 type 136

这个文章主要讲述的是工作原理，也是我自己的疑问，在IPv4中， host发ARP广播给网络同网段和本vlan中所有成员，我要找1.1.1.1，请1.1.1.1收到请求回复我。

然后1.1.1.1这个时候回应一个单播报文回来。

最后host的arp缓存表学习到对端的IP地址和MAC，并且注明是动态还是静态学习到的。

这个时候主机就可以和对端进行通讯了，因为我的通讯录中有你了。你也有我了。学习本来也就是相互的嘛。

那么IPv6又是怎么来实现这个东东的呢？

从上面的表格中看出，实际上是用的ICMPv6 type 135和type=136来替代IPv4的ARP原理。

下面会结合原理是实验来进行深度剖析这个过程。

邻居请求消息 NS :ICMPv6 type = 135

邻居公告信息 NA+ 被请求节点多播地址FF02::1:FFxx:xxxx 的组合: ICMPv6 type = 136

邻居请求和邻居公告是如何工作的？(原理)

我个人理解，这个地方实际上是用得ICMPv6 type 135 NS,代替了以前ARP的广播，下面我自己做了一个对比表。关于这点。

再次复习IPv6的"ARP"协商原理:

最后我再做一个实验来验证关于V6中type 135和type 136的协商是否和原理图一致。

上面是一个拓扑图，也许这个图还不详细，我这里把R1的F0/0和R2的F0/0的详细地址都show出来。

下面是R1`的F0/0:

这里我根据原理图，理一个表格出来，对于R1:

源IP: 2012::1/64,目的被请求节点多播：FE80::C801:5FF:FE50:8.(link-local)

因为是直连的.

源MAC: ca:01:05:50:00:08

目的MAC: 33:33:ff:50:00:08.

注意目的mac是一个组播mac地址。

这样就构成了一个完整的ICMPv6 type 135 neighbor solicaitation的请求报文了。

下面有一个抓包，可以来证明一下，是否NS发送的时候是这样工作的：

然后再来看看关于R2给R1的NA邻居通告。是否是我理解的单播。

先来看看R2 interface f0/0的IPv6的具体参数:

下面是R2发给R1的NA.

给R1回应的是:

ICMPv6, type = 136 , NA报文-- neighbor advertisement.

源：FE80::c801:5ff:fe50:8.这个是R2的link local 地址.

目的：这个时候目的就是明确的组播地址了，而不是之前的被请求节点多播地址了。这里是FF02::1.

之前说过凡是以FF02开头的都是组播地址。

链路源地址：ca:01:05:50:00:08,这个是R2 interface f0/0的mac.

最后目的MAC:注意这里目的mac依然是组播MAC进行回复。

我们可以看到抓包文件：目的是33:33:00:00:00:01.

综合来说虽然这里只有两个步骤，但是和我在<<IPv6网络实现技术--cisco自学指导>>书中看到的原理还是有些不一样的。

比如说回应的时候,NA报文中在书上说的是目的链路地址是对端的mac，感觉和ipv4回应一样就变成单播了。这里抓包实验仍然是组播。我看了一下，书是2005年印刷的，是不是RFC修改了呢？呵呵，实在没有精力去查RFC了，以后在实践中再多磨练吧。

呵呵，只有等高手来解答了。呵呵.现在确实还有些地方不是很明确。