IPv6 用邻居请求和邻居公告替代ARP. 推荐
2011-08-08 22:04
323 查看
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了,以后在实践中再多磨练吧。
呵呵,只有等高手来解答了。呵呵.现在确实还有些地方不是很明确。
这个文章主要讲述的是工作原理,也是我自己的疑问,在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了,以后在实践中再多磨练吧。
呵呵,只有等高手来解答了。呵呵.现在确实还有些地方不是很明确。
相关文章推荐
- IPv6 邻居发现的工作机制和原理 推荐
- IPv6 auto config 原理详解之-----前缀公告 推荐
- Linux内核分析 - 网络[九]:邻居表 ARP杂谈
- Win7网上邻居提示未授予用户在此计算机上的请求登录类型解决办法
- Java for Web学习笔记(五九):Controller替代Servlet(1)请求匹配
- 推荐一款功能强大的Tomcat 管理监控工具,可替代Tomcat Manager
- 对代理ARP技术的误读、无法完成代理ARP实验的故障分析 推荐
- 论坛源码推荐(3月26日):iOS图片涂鸦控件 替代UISegmentedControl展示相关数目
- 使用WindowsAPI发送ARP请求获得MAC地址
- jQuery通过ajax请求php遍历json数组到table中的代码(推荐)
- 主流RAII class的存在价值——不存在能够完全替代Dumb Pointer的RAII class 推荐
- Outlook替代Hotmail:社交很重要,但邮箱是根本 推荐
- 为什么Spring Boot推荐使用logback-spring.xml来替代logback.xml来配置logback日志的问题分析
- Golang 建立RESTful webservice 接收客户端POST请求发送wav语音文件 推荐
- linux网络协议栈分析笔记9-arp邻居子系统2
- 推荐记事本替代工具Notepad++
- 演示:OSPF的邻居关系故障分析与排除 推荐
- 推荐的变更请求表格格式
- 代理ARP你牛啥? 推荐
- 图解ARP协议(四)代理ARP原理与实践(“善意的欺骗”) 推荐