前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >实战性的IPV6 报文分析

实战性的IPV6 报文分析

作者头像
网络技术联盟站
发布2023-03-13 14:08:26
6160
发布2023-03-13 14:08:26
举报
一、拓扑

要求:

  1. R1、R2、R3 上配 AGUA,分析 ipv6 中的 ARP 机制。
  2. R1、R2、R3 上配 AGUA,分析 ipv6 中的 DHCP 机制。

二、实验过程

1.ARP 机制的实验

①配置 ipv6 地址

②互访测试 R1 分别访问 R2、R3,并抓包

通过以上分析可以看到,ipv6 中的 ARP 功能是按以下方法实现的:

1.R1 如果要访问R2,当其仅知 R2 的AGUA,但不知 R2 的 MAC地址时,其会发出 ICMP135 的报文,即 NS 报文,在该报文中

①三层地址中,源 IP 为 R1 的 AGUA,目的 IP 为 R2 的被请求节点组播地址,其由前缀ff02::1:ff 及 R2 的 AGUA 的后 24 位组成。例如:R2 的 AGUA 为 2001:0:0:123::2/64,后24 位为 00:0002,那么其被请求节点组播地址为 ff02::1:ff00:0002

②二层地址中,源 IP 为 R1 的 MAC 地址,目的 IP 为 R2 的被请求节点组播地址对应的MAC 地址,其由前缀 33:33:ff 及 R2 的被请求节点组播地址后 24 位组成。例如:R2 的被请求节点组播地址后 24 位为 00:0002,故 R2 的被请求节点组播地址对应的 MAC 为33:33:ff:00:00:02

③数据为:请问 R2 的 MAC 是多少?

2.R2 收到 R1 的 ICMP135 报文,会向请求者 R1 发回一个 ICMP136 报文,即 NA 报文, 在该报文中:

①三层地址中,源 IP 为 R2 的 AGUA,目的 IP 为 R1 的 AGUA。

②二层地址中,源 MAC 为 R2 的 MAC,目的 MAC 为 R1 的 MAC。

③数据为 R2 的 MAC 值。

2.IPV6 中的 DHCP 机制

此时,我们让 R1 为支持 IPV6 的路由器,R2、R3 为支持 IPV6 的 PC,通过 Autoconfig 的方式获得 IPV6 地址。

然后查看 R2 的 e0/1、R3 的 e0/2 的 AGUA

可以看到此时 R2 的 e0/1、R3 的 e0/2 上的 AGUA 都是由 R1 通告的前缀加上 EUI-64 生成的接口构成的。

为了演示该实验过程,我们现在 R1的 e0/0 上关闭掉前缀通告功能,即 R1 不再向 R2、R3通告自己的 AGUA 地址前缀,并将 R2 的 e0/1、R3 的 e0/2 的地址清掉,查看 R2 的 e0/1、R3 的 e0/2 是否还可以通过 Autoconfig 方式获得 AGUA,

此时我们查看 R2 的 e0/1 、R3 的 e0/2,看有没有通过路由前缀和 EUI64,生成 AGUA

可以看到 R2 的 e0/1、R3 的 e0/2 都没有生成 AGUA,但是生成了 LLA,为什么会生成 LLA 呢?

由于采用 Autoconfig,则 R2 的 e0/1、R3 的 e0/2 可以使用 MAC 地址生成 LLA,例如,我们查看 R2 的 e0/1 的 MAC 地址为 aabb.cc00.2010

采用以下方法进行 LLA 生成

① 将 R2 的 e0/1 上 的 MAC 地 址 aabb.cc00.2010 中 间 插 上 fffe , 变为aabb.ccff.fe00.2010

②将变化后的值的第 7 位取反,即由 aabb.ccff.fe00.2010 变为 a8bb.ccff.fe00.2010

③在以上值前面加上前缀 fe80,变为 fe80:a8bb:ccff:fe00:2010

由于接口上的 MAC 是已知的,故可以生成 LLA 地址。

现在我们在 R1 的 e0/0 上开启 ra 报文通告功能,并抓包分析

可以看到此时 R1 已经向广播域中发出了 ra 报文,即路由通告报文,其具有以下特点:①三层地址中,源 IP 为 R1 的 LLA,目的 IP 为 ff02::1,即发给广播域中的所有节点。

②二层地址中,源 MAC 为 R1 的 MAC,目的 MAC 为 ff02::1 对应的组播 MAC,其由33:33:00 前缀和组播地址后 24 位构成,即由 33:33:0000:00:01 构成,即33:33:00:00:00:01

③数据则为 R1 的 AGUA 地址前缀,即 2001:0:0:321::/64

再查 R2 的 e0/1、R3 的 e0/2,查看是否形成 AGUA

可以看到 R2 的 e0/1 和 R3 的 e0/2 都获得了 AUGA,其按以下方式构成,即 R1 通告的路由前缀 2001:0:0:321::/64,再加上 EUI64 方式生成的接口 ID,其中接口 ID 由 MAC 地址生成,从前面分析 R2 的 e0/1 上的 LLA 过程中,我们知道 R2 的 e0/1 的接口 ID 应为a8bb.ccff.fe00.2010 , 在 其 前 面 加 上 前 缀 2001::321/64 , 变 为2001::321:a8bb:ccff:fe00:2010,这与我们分析到的完全一致。

如果有一台 PC 接到 IPV6 广播域中,其在一段时间内没有收到 IPV6 路由器通告的路由前缀,即未收到 ra(134 报文)报文,那么其会发出一个 133 报文, 即 rs 报文,现我们演示如下先将 R1 上的 ra 报文通告周期改大,使其大于缺省的 200S,

可以看到此时 R1 的 e0/0 上发出 ra 的周期为 1800S,即长时间不发出 ra 报文,现将 R2的 e0/1、R3 的 e0/2 进行初始

可以看到此时出现了一个 rs 报文,其特点如下:

①三层地址中,源 IP 地址为空,因为此时发出 rs 报文的设备——R2、R3 尚没有 AGUA,故源 IP 地址为空,目的 IP 为 ff02::2,表示发给广播域内所有的路由器。

②二层地址中,源 MAC 为请求 AGUA 前缀的设备的 MAC 地址,查看该值为aa:bb:cc:00:30:20

通过查看 R2 的 e0/1、R3 的 e0/2 可知

可以看到该 rs 报文是由 R3 的 e0/2 发出的。

同时也可以看到 R2 的 e0/1 上发的 rs 报文。

综合以上,可知:

1.ns、rs 报文为请求报文,都为单数编号,前者为 135 报文,后者为 133 报文。

2.na、ra 报文为应答报文,都为双数编号,前者为 136 报文,后者为 134 报文。

3.当 PC 发出 rs 报文后,广播域中的 ipv6 路由器,不管自己的 ra 发送周期是否到期,其都会发出一个 ra 报文,向广播域中发出 AGUA 路由前缀通告,使广播域中的其它设备获得AGUA 前缀,再生成对应的 AGUA 地址。

以上分析了 IPV6 中的 ARP、DHCP 功能,最后在这里补充一点,即 IPV6 中的重复地址检测功能,也是用 na、ns 报文来完成的,在这里就不再叙说。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-12-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 网络技术联盟站 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 二、实验过程
    • 1.ARP 机制的实验
      • 2.IPV6 中的 DHCP 机制
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档