IPv6 ICMPv6 | 原理 / 报文分析 / 配置示例

于 2025-07-05 19:25:13 发布
阅读量445 收藏 9
点赞数 4
CC 4.0 BY-SA版权
分类专栏： network 文章标签： IPv6 ICMPv6
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/u013669912/article/details/148521201

注：本文为“IPv6 ICMPv6 ”相关合辑。

图片清晰度受引文原图所限。
略作重排，如有内容异常，请看原文。

DHCPv6 原理浅谈 + 报文示例 + 简易配置 (SLAAC + DHCPv6 + PD 前缀代理) – RFC8415

fengxingzhe008 已于 2024-11-20 20:48:55 发布

理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

本文将在 DHCP 协议报文的基础上进行介绍。

在这里插入图片描述

相关资料：

…

DHCPv6 还存在大量相关 RFC，感兴趣者可查阅相关资料。

Note：RFC8415 是一篇综合性标准文档，融合了大量先前内容。例如，RFC3633 中关于 Prefixes Delegation 的内容；RFC3736 中关于无状态 DHCPv6 的内容；…等。有意者可阅读相关资料。并且 DHCPv6 交互过程常与 ND 协议相关联，建议优先了解 IPv6/ICMPv6 协议等相关内容。个人能力有限，这里仅涉及简易内容。敬请各位指导。

1. DHCPv6 协议原理

DHCPv6 协议主要用于 IPv6 网络环境中，其协议背景与 IPv4 网络下的 DHCP 背景相类似。先期已进行相关介绍，这里直接进行相关内容说明。

1.1. DHCPv6 术语

GUA：Global Unicast Address，IPv6 全球单播地址。

ULA：Unique Local Address，IPv6 私网地址。

binding：将身份关联信息与 DHCPv6 配置信息绑定的过程，与 DHCP 概念类似。

DHCP domain：单个管理实体负责的 DHCP 管理链路集合。

DUID：DHCP Unique Identifier，DHCP 参与者的唯一标识。每台设备仅有一个，不随时间更改。DUID 通常与设备的链路层地址有关，但不应通过 DUID 解析其链路层地址，而应通过 Option79=Client Link-Layer Address option 获取。

《RFC8415 的 11.DHCP Unique Identifier》定义了 DUID 的 4 种格式：

  • DUID-Type 1=Link-layer address plus time（DUID-LLT）；
  • DUID-Type 2=Vendor-assigned unique ID based on Enterprise Number（DUID-EN）；
  • DUID-Type 3=Link-layer address （DUID-LL）；
  • DUID-Type 4=Universally Unique Identifier（DUID-UUID）。

在这里插入图片描述

//这里使用的是 DUID-Type 3=DUID-LL 的 DUID。两个字节的 DUID Type=0x0003；两个字节的 Hardware Type=0x0001；6 个字节的 Link-layer Address=0x00e0fc6c6b31。

在这里插入图片描述

//这里则使用的是 DUID-Type 1 的格式。具体使用还是要看设备实际选择的方式。

在这里插入图片描述
//dhcpv6 duid 用来配置 DHCPv6 设备的唯一标识符 DUID 为 Type1 还是 Type4。

IA：Identity Association，身份联盟。由 Client 生成，向 Server 请求分配给 Client 的租约集合。IA 中的配置信息由一个或多个 IPv6 地址以及 T1 和 T2 生存期组成。IA 中的每个地址都有 preferred lifetime（首选生存期）和 valid lifetime（有效生存期）。一个接口至少关联一个唯一 IA，一个 IA 可以包含一个或多个地址信息。

IAID：Identity Association Identifier，IA 标识。IA 的身份由 IAID 唯一确定，同一个客户端的 IAID 不能出现重复。

IA_NA：Identity Association for Non-temporary Addresses，非临时地址 IA。

IA_PD：Identity Association for Prefix Delegation，前缀代理 IA。与 DHCPv6 的前缀代理场景相关。

IA_TA：Identity Association for Temporary Addresses，临时地址 IA。

这三种 IA 与 DHCPv6 工作模式相关。

@：Client 必须至少将一个不同的 IA 与其每个网络接口相关联。
@：Client 与接口关联的 IA 应当从该接口连接的服务器获取而来。
@：Option3=IA_NA 中的配置信息由一个或多个 IPv6 地址以及 IA 的 T1 和 T2 值组成。
@：IA_PD 与用于地址分配的 IA 不同，因为它不需要只与一个接口关联。一个 IA_PD 可以与 Client、一组接口或仅与一个接口相关联。配置为请求 PD 的 Client 必须至少创建一个不同的 IA_PD。
@：Option25=IA_PD 中的配置信息由一个或多个 IPv6 前缀以及 IA 的 T1 和 T2 值组成。
@：IA 中的每个地址都有一个 preferred lifetime（首选生存期）和一个 valid lifetime（有效生存期）。
@：DHCPv6 Server 不得分配保留 IPv6 地址给 IA。
这三种 IA Option 将在后文进行介绍。

singleton option：只允许作为 top-level option 或任何封装级别出现一次的 option。大多数选项都是 singleton option。

top-level option：直接在 DHCP 消息中传达的 option，即未封装在任何其他 option 中作为子 option。

transaction ID：传输 ID/交易 ID，用于标识特定相应和回复的编码。与 IPv4 的 DHCP 中 xid 字段意义相同。

1.2. DHCPv6 基本内容

1@：DHCPv6 通常使用 Link-local（链路本地地址）作为报文源地址。

《RFC8415 的 13.Assignment to an IA》 中指出，在某些情况下，允许其报文源地址非 Link-local 链路本地地址。但需要 Server 使能相应功能。

2@：DHCPv6 使用 ff02::1:2 作为报文目的地址。由于该地址为组播地址，因此 DMac 也为相应的组播 Mac=33:33:00:01:00:02。

ff02::1:2：在 RFC8415 中称为 All_DHCP_Relay_Agents_and_Servers 组播地址。这一地址是 Client 使用具有链路范围的组播地址。所有 Server 和中继代理都是此组播组的成员。
ff05::1:3：在 RFC8415 中称为 All_DHCP_Servers 组播地址。这一地址是中继代理所使用的具有站点范围的组播地址。因为中继代理希望将消息发送到所有 Server，或者因为它不知道 Server 的单播地址。所有 Server 都是此组播组的成员。
组播/单播：通常 Client 向 Server 以组播消息作为目的地址。但如果 Server 携带 Option12=Server Unicast Option 向 Client 通知了 Server 单播地址，那么 Client 可通过单播方式进行交互。

3@：DHCPv6 Client 使用 546 端口，监听来自 Server 的 546 端口，向 Server 使用的 547 端口发送消息；
DHCPv6 Server 使用 547 端口，监听来自 Client 的 547 端口，向 Client 使用的 546 端口发送消息。

在这里插入图片描述
//DHCP 报文帧头示例。

4@：类似于 BGP 的 Notification 消息，DHCPv6 通过 Option13=Status Code option 来指示 clients 和 servers 之间交互可能出现的问题。

在这里插入图片描述

status-message 使用 UTF-8 编码格式，介绍于 RFC3926 中。其值不得以空值结尾。
如果不包含该 Option 通常表示交互成功。

《RFC8415 的 7.DHCP Constants》中还定义了一些用于程序执行的相关参数，例如第一次 SOLICIT 最大时延为 1s，重传间隔等。
《RFC8415 的 14.Transmission of Messages by a Client》详细描述了重传上的考虑，一个特性是不在租期到期后立刻进行 RENEW 和 REBIND。
感兴趣者可查阅相关文档。

1.3. DHCPv6 报文简介

DHCPv6 目前已标准化了 35 种报文类型。与之前关于 DHCP 博客介绍的类似，这里仅简单介绍常用的 13 种报文类型。报文详细内容将在后文介绍。

msg-type ValueDescriptionCompared with DHCPused
1SOLICITDISCOVERClient 确定 Server 存在
2ADVERTISEOFFERServer 宣告可提供地址
3REQUESTREQUESTClient 请求地址及其他信息
4CONFIRM—Client 检查地址可用性
5RENEWREQUESTClient 第一次续租
6REBINDREQUESTClient 第二次续租
7REPLYACK/NAKServer 对 Client 的回应
8RELEASERELEASEClient 申请撤销地址
9DECLINEDECLINEClient 宣告地址的不可用性
10RECONFIGUREDISCOVERServer 宣告网络信息更新
11INFORMATION-REQUESTINFORMClient 请求其他网络信息
12RELAY-FORW—Relay 向 Server 转发请求消息
13RELAY-REPL—Server 向 Relay 回应网络信息

通用报文格式：

在这里插入图片描述

  • msg-type：1 字节，用于标识 DHCPv6 报文格式。
  • transaction-id：3 字节，用于标识 Client/Server 交互会话，与 DHCP 概念相同。
  • options：可变长选项，携带交互的相应信息。

中继报文格式：

在这里插入图片描述

  • msg-type：1 字节，用于标识 DHCPv6 报文格式。这里仅有 12 标识 RELAY-FORW 和 13 标识 RELAY-RELY 两种。
  • hop-count：1 字节，用于标识 relay agents 已经 relay 的次数。这里指的是途径中继节点的个数。在 DHCP 中未明确区分，实际上只有第一个 relay 节点处理相应消息。
  • link-address：16 字节，Server 可用于标识 Client 所在的链路的地址。通常是 GUA 或 ULA。
  • peer-address：16 字节，从中接收要中继消息的客户端或中继代理的地址。
  • options：可变长选项，携带交互的相应信息。

msg-type=13 的 RELAY-RELY 消息中，hop-count、link-address 和 peer-address 字段从 msg-type=12 的 RELAY-FORW 消息复制而来。

DHCPv6 报文示例：

在这里插入图片描述
// 这里携带了 Option1=Client ID，Option3=IA_NA，Option6=ORO 和 Option8=ELAPSED_TIME。

报文消息的可用性：出于安全性等的考虑，RFC8514 还给出了明显不符合报文交互流程的流程动作和报文内容。例如，Client 不会处理 msg-type 1=Solicit 的消息，同样 Server 不会处理 msg-type 2=Advertise 的消息。例如，msg-type 2=Advertise 的消息应当包含 Option1=Client ID option 和 Option2=Server ID option。

2. DHCPv6 基本原理

2.1. DHCPv6 的两种交互模型

Client/Server 的两步交互模型：也即仅交互两次报文。
当 DHCP Client 不需要让 DHCP Server 为其分配 IP 地址或 Prefix Delegation 前缀代理时，Client 可以通过与 DHCP Server 的单个消息和回复交换来获取其他例如 DNS 等配置信息。

这一过程通常和 SLAAC 结合使用。两步交互还可用于加快地址分配或 Prefix Delegation 前缀代理。

1@Client：向 ff02::1:2 发送 msg-type 1=Solicit 消息，其中携带 Option14=Rapid Commit option。该 Option 表明 Client 愿意接受来自 Server 的即时回复消息。
2@Server：愿意分配地址和/或 Prefix Delegation 前缀代理的 Server 会立即响应 msg-type 7=Reply 消息。

@分配给 Client 的每个地址或 Prefix Delegation 都具有 Server 指定的 preferred lifetimes 和 valid lifetimes。
@若要请求延长生存期，Client 会向 Server 发送 msg-type 5=Renew 消息。Server 使用新的生存期向客户端发送 msg-type 7=Reply 消息，允许 Client 继续使用。
@如果 Server 无法延长地址或 Prefix Delegation 的生存期，则通过返回生存期为 0 的地址或 Prefix Delegation 来指示这一点。同时，Server 可以分配其他地址或 Prefix Delegation。
@如果 msg-type 1=Solicit 消息中没有携带 Option14=Rapid Commit option，或消息中携带但 Server 不支持快速分配过程，则 Server 回复 msg-type 2=Advertise 报文随后按四步交互模型进行交互。

Client/Server 的四步交互模型：这一交互过程与 DHCP 过程基本类似。

在这里插入图片描述

1@Client：向 ff02::1:2 发送 msg-type 1=Solicit 消息，查找可用的 DHCPv6 Server。
2@Server：任何可以满足 Client 要求的 Server 都会以 msg-type 2=ADVERTISE 消息进行响应。
3@Client：Client 选择其中一个 Server，并向 Server 发送 msg-type 3=REQUEST 消息，要求确认地址和/或前缀代理和其他配置信息的分配。
4@Server：Server 使用包含已确认地址、前缀代理和配置的 msg-type 7=REPLY 消息进行响应。

此外，Client 如果已经和 Server 协商监听 msg-type 10=RECONFIGURE。（Server 可以通知 Client 网络信息的改变）。此时，Client 通过发送 msg-type 11=Information-request、msg-type 5=Renew 或 msg-type 6=Rebind 更新其配置。

2.2. DHCPv6 的三种操作模型

本节介绍一些当前最常见的 DHCP 操作模型。所描述的模型并不相互排斥，有时一起使用。

无状态 DHCPv6：RFC3736 - Stateless DHCP Server for IPv6
当 DHCP 不用于获取租约，但节点（DHCP 客户端）需要一个或多个 DHCP 其他配置参数（例如除 IPv6 地址外的包括 DNS [RFC3646]、SIP、SNTP 等服务器配置信息）时，将使用无状态 DHCP [RFC3736]。

1@Client：向 ff02::1:2 发送 msg-type 11=INFORMATION-REQUEST 消息，其中携带 Option6=ORO（Option Request option）。该 Option 表明 Client 所希望请求的信息。
2@Server：任何可以满足 Client 要求的 Server 都会以 msg-type 7=Reply 消息进行响应。客户端将选择最先收到的 Reply 报文，并根据该报文中提供的参数完成客户端无状态配置。
这一 NA 过程通常进行两步交互，并且在交互前往往需要进行一次 ND 交互用于说明仅请求非 IPv6 地址以外的网络信息。

DHCPv6 for Non-temporary Address：适用于无状态 DHCPv6 不可用的情况。
这种模式是 DHCP 的最初目标。Client 请求 Server 分配非临时地址。Server 分配适合于 Client 所连接链路的一个或多个地址。
每个地址都有关联的 preferred lifetimes 和 valid lifetimes。Client 可以请求延长地址的生存期，并且如果地址的 preferred lifetimes 到期，则需要终止地址的使用。
这一 NA 过程通常使用 DHCPv6 四步交互分配模型或两步交互分配模型。具体使用上取决于对 Option14=Rapid Commit option 的支持能力。

DHCPv6 for Prefix Delegation：简单来说就是 PD Client/CPE/Requesting Router 向 PD Server/Agg Device/Delegating Router 请求 IPv6 大段前缀后，将其划分为小段前缀分配给 DHCP Client/Subscriber PC。

在这里插入图片描述

1@PD Client：首先发送 msg-type 1=SOLICIT 意味着 Prefix Delegation 前缀代理过程开始。
2@PD Server：选择一个或多个可用的前缀通过 msg-type 2=Advertise 消息 PD 给 Client。
3@PD Client：根据 msg-type 2=Advertise 消息中的 Server 优先级等参数，选择优先级最高的一台 Server，发送 msg-type 3=Request 报文以确认为其分配地址前缀。
4@PD Server：回复 msg-type 7=Reply 报文，确认将 IPv6 地址前缀分配给 DHCPv6 PD Client 使用。
5@PD Client：将较长的前缀分配给 Subscriber PC 网络中的链路。这一过程主要通过 ICMPv6/NDP 协议的 RA 发现机制实现。

DHCPv6 的多地址和前缀：
由于 IPv6 支持链路复用，也即一个路由器接口上可配置多个 IPv6 地址，这就可能发生 DHCPv6 获取多个地址和前缀的场景。RFC8415 指出 DHCPv6 允许 Client 获取多个地址和前缀。基本原理在于通过 Option3=IA_NA 和 Option4=IA_TA 来实现。

  • Client：在初始 DHCPv6 交互过程中传递多个 Option3=IA_NA 和 Option4=IA_TA 来显式请求多个地址。
  • Server：将为每个 Option3=IA_NA 提供一个地址。
  • 同样的原则也适用于 Prefix Delegation 前缀代理过程，但通常不在 PD 过程中使用这种方式。 Server 的确切行为取决于相应策略。

关于 RFC8514 中介绍的 Customer Edge 场景和 Temporary Addresses 场景，这里不再进行描述。有意者可查阅相关资料。

RFC7084 中详细说明了家用小型路由的 CE 场景下 WAN 侧的 DHCPv6 交互过程。此场景下的典型 CE 设备提供的 IPv4 网络往往承担 NAT 的角色，而 IPv6 可能存在差异。一种可能的方式是类似 PD 交互的过程，实际上 CE 也可通过 PPP 等方式提供 IPv6 服务。
引入临时地址最初是为了避免无状态地址自动配置的隐私问题，以便在使用有状态地址分配时提供补充支持。临时地址分配的工作方式与非临时地址分配大致相同。

3. DHCPv6 场景及过程浅谈

在实际应用时，DHCPv6 交互过程往往受链路质量等情况影响。并且相关程序处理涉及多个判定，此处不进行细致的描述而仅介绍主要的交互过程。
Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。

3.1. DHCPv6 中继场景

在这里插入图片描述

在如上图所示场景中：

  • AR1：做 DHCPv6 Server 为 DHCPv6 Client 分配网络信息。
  • AR2：做 DHCPv6 Relay 设备为 PC1 和 PC2 中继 DHCPv6 报文。
  • AR3：做 DHCPv6 Client，采用 SLAAC+DHCPv6 方式获取网络信息。
  • PC1/PC2：做 DHCPv6 Client 通过 DHCPv6 方式获取网络信息。
  • Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。有相关问题可私信指导，以便本文及时更新错误。~

AR1：

#
#
sysname AR1
#
ipv6 
#
dhcp enable
#
dhcpv6 pool pool2
 address prefix FC00:2::/64 life-time 71 61
 static-bind address FC00:2::20 duid 000300015489981041B9
 excluded-address FC00:2::1 to FC00:2::3
 dns-server fc00:1::1
 information-refresh 600
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::1/64 
 ipv6 address FE80:1::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig other-flag
 dhcpv6 server pool2
#
ipv6 route-static :: 0 FC00:1::2 
#

1@这里在地址池中手动指定了 msg-type11=INFORMATION-REQUEST 消息的刷新时间，并且进行 DHCPv6 Client 的手动绑定。
2@由于 AR3 采用 SLAAC 方式获取地址，因此不应当将 ND 报文的 M-bit 置位。
3@DHCPv6 中继报文的源地址为中继代理的 Client 侧接口地址，因此需要在 DHCPv6 Server 上配置 IPv6 路由保证其可达。

AR2：

#
#
sysname AR2
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::2/64 
 ipv6 address FE80:1::2 link-local
#
interface GigabitEthernet0/0/1
 ipv6 enable 
 ipv6 address FC00:2::1/64 
 ipv6 address FE80:2::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig managed-address-flag
 ipv6 nd autoconfig other-flag
 dhcpv6 relay destination FC00:1::1
#

AR3：

#
#
sysname AR3
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:1::3 link-local
 ipv6 address auto global default
 dhcpv6 client information-request
#

1@AR3 这里使用 SLAAC 方式获取地址。
2@并且通过 msg-type 11=information-request 消息获取除地址以外的信息。

3.2. 报文交互

1@PC<—>DHCPv6 Relay：

在这里插入图片描述上图所示报文展示了 PC<—>DHCPv6 Relay 报文交互过程。仅作参考。

1@：其中夹杂了 IPv6 的 ICMPv6/NDP 协议的进行邻居发现和 DAD，其主要作用类似于 ARP 的地址解析和重复地址检测。
2@：这里 PC 使用的是 DHCPv6 的四步交互模型，而非 Solicit/Replay 两步交互模型。两步交互模型不仅需要 Client 在发送 msg-type 1=Solicit 消息时携带 Option14=Rapid Commit Option 进行标识，并且需要 Server 支持提供该功能并在 msg-type 7=Reply 消息中同样携带该 Option。由于网络中可能存在多台 Server，此时有可能造成相应的混乱。
3@：这里成功获取到地址后还进行了 ND 的 3 次重复地址检测。如果有地址冲突的情况，Client 将发送 msg-type 9 Decline 消息并携带 option13=Status Code Option 通知 Server 相应情况。随后重新发起 DHCPv6 交互过程。
4@：对于 PC/Client 而言，Relay 的存在通常并不具有特别的意义。

1@PC—>DHCPv6 Relay=msg-type 1 Solicit：
Client 通常以组播方式将 Solicit 发向特定组播地址 ff02::1:2，并在其中必须携带 Option1，Option6 等信息。

在这里插入图片描述

Option1=Client ID 用于唯一标识 Client，通常与其链路层地址相关。但不得以该值解析其链路层地址，而是应当以 Option80=LINK_ADDRESS 交互信息为准。

Option3=IA_NA 和 Option8=Elapsed time 在 DHCPv6 初始交互过程填 0。

Option6=ORO 为必须携带 Option 用于 Client 明确请求获得参数信息，相当于 IPv4 环境下 DHCP 的 Option55=Parameter Request List。

2@PC<—DHCPv6 Relay=msg-type 2 Advertise：
DHCPv6 Relay 代替 Server 回应 msg-type 2 Advertise 消息，其中必须携带 Option1，Option2 和其他 Client 请求的信息。

在这里插入图片描述此处以单播方式进行回应。

其中必须携带 Option1=Client ID，Option2=Server ID。

在 Option3=IA_NA 中还携带了 Server 提供的地址租期和生存期。T1 和 T2 分别默认为 Preferred lifetime 的 0.5 倍和 0.8 倍。

相应的回应了 Client 请求 Option6=ORO 参数的 Option23=DNS recursive name server。

3@PC—>DHCPv6 Relay=msg-type 3 Request：
Client 通常以组播方式重新发送 IA 的相关请求。此时将携带具有参数意义的内容。

在这里插入图片描述携带内容几乎与 msg-type 1=Solicit 消息相同。

4@PC<—DHCPv6 Relay=msg-type 7 Reply：
DHCPv6 Relay 代替 Server 回应 msg-type 7 Reply 消息，与 msg-type 2 Advertise 消息几乎相同。

在这里插入图片描述与 msg-type 2 Advertise 消息几乎相同。

2@DHCPv6 Relay<—>DHCPv6 Server：

在这里插入图片描述上图所示报文展示了 DHCPv6 Relay<—>DHCPv6 Server 报文交互过程。仅作参考。

1@：其中也可能夹杂了 IPv6 的 ICMPv6/NDP 协议的进行邻居发现和 DAD。
2@：注意这里使用单播进行 Relay 和 Server 之间的报文交互。并且 Relay 以 PC/Client 侧的接口地址为源 IPv6 进行交互。
3@：简单而言这一部分就是将 Client 与 Relay 之间的报文封装在 Option9=Relay Message Option 中以 msg-type 12=Relay-forward 消息和 msg-type 13=Relay-reply 消息承载进行交互。

1@DHCPv6 Relay—>DHCPv6 Server=msg-type 12 Relay-forward：

在这里插入图片描述

2@DHCPv6 Server—>DHCPv6 Relay=msg-type 13 Relay-reply：

在这里插入图片描述

其余两次交互过程不再展示。

3@DHCPv6 Client<—>DHCPv6 Server：SLAAC+DHCPv6

在这里插入图片描述上图所示报文展示了 SLAAC+DHCPv6 报文交互过程。其中夹杂了 IPv6 的 ICMPv6/NDP 协议的进行邻居发现和 DAD。

ICMP/NDP 的交互过程

1@：首先 DHCPv6 Client 在接口 Up 起来后进行了一次 fe80:1::3 链路本地地址的 DAD 重复地址检测。
2@：随后 DHCPv6 Client 与 DHCPv6 Server 进行了 3 次 RS/RA 交互，以便进行路由器和前缀发现。
3@：DHCPv6 Client 在第一次前缀发现后，SLAAC 自动生成了一个 GUI IPv6 地址并进行该地址的 DAD 重复地址检测。

在这里插入图片描述
// 这里 SLAAC 生成的地址为 fc00:1::2e0:fcff:fe2c:74c8。

4@：DAD 重复地址检测完成后，DHCPv6 Client 与 DHCPv6 Server 开始进行其他网络参数的 DHCPv6 交互过程。

5@：之后的时间 DHCPv6 Server “周期性”泛洪 RA 消息。

1@DHCPv6 Client—>DHCPv6 Server=msg-type 11 Information-request：
Client 通常以组播方式发送相关请求，此时请求除 IPv6 地址以外的其他网络参数信息。

2@DHCPv6 Client<—DHCPv6 Server=msg-type 7 Reply：
Server 以单播方式回应 option6=ORO 中的相关内容。

在这里插入图片描述
//msg-type 11=Information-request，无特别注意内容

在这里插入图片描述
//msg-type 7=Reply，无特别注意内容。Option32=Information Refresh Time Option 中内容为 DHCPv6 Server 中指定的 information-refresh 600 时间，未指定时默认取 IRT_DEFAULT =86400s。

3.3. Prefix Delegation 前缀代理场景

在这里插入图片描述在如上图所示场景中：

  • AR1：做 DHCPv6 PD Server 为 DHCPv6 Client 分配网络信息。
  • AR2：做 DHCPv6 PD Client 设备为 PC1 和 AR3 请求前缀信息。
  • PC1/AR3：做 DHCPv6 Client，采用 SLAAC 方式获取网络信息。
  • Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。有相关问题可私信指导，以便本文及时更新错误。谢谢~

AR1：

#
#
sysname AR1
#
ipv6 
#
dhcp enable
#
dhcpv6 pool pool1
 prefix-delegation FC00:1::/60 63
 dns-server 2001:DB8::1
 dns-server 2001:DB8::2
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::1/64 
 ipv6 address FE80:1::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig managed-address-flag
 ipv6 nd autoconfig other-flag
 dhcpv6 server pool1
#

AR2：

#
#
sysname AR2
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:1::2 link-local
 ipv6 address auto global default
 dhcpv6 client pd myprefix
#
interface GigabitEthernet0/0/1
 ipv6 enable 
 ipv6 address myprefix ::1:0:0:0:1/64
 ipv6 address FE80:2::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig other-flag
#

AR3：

#
#
sysname AR3
#
ipv6 
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:2::3 link-local
 ipv6 address auto global default
#

3.4. 报文交互

在这里插入图片描述上图所示报文展示了 DHCPv6 PD Client<—>DHCPv6 PD Server 报文交互过程。仅作参考。

1@：其中夹杂了 IPv6 的 ICMPv6/NDP 协议的进行邻居发现和 DAD，其主要作用类似于 ARP 的地址解析和重复地址检测。
2@：从报文交互流程上看，与普通 DHCPv6 场景无较大差别。

1@DHCPv6 PD Client—>DHCPv6 PD Server=msg-type 1 Solicit：

在这里插入图片描述//主要差别在于 DHCPv6 中携带的 IA 内容为 option25=IA_PD，请求 IPv6 前缀信息。此外还需要注意的是与 Relay 场景不同，交互的报文源地址不再是用户侧的接口地址。

2@DHCPv6 PD Client<—DHCPv6 PD Server=msg-type 2 Advertise：

在这里插入图片描述
//相应的 DHCPv6 PD Server 回应相应的前缀信息。

3@DHCPv6 PD Client—>DHCPv6 PD Server=msg-type 3 Request：
略。可参考先前内容。

4@DHCPv6 PD Client<—DHCPv6 PD Server=msg-type 7 Reply：
略。可参考先前内容。

AR2 和 AR3 交互获取地址的过程可参考《3.1.DHCPv6 中继场景》中的 SLAAC+DHCPv6 介绍内容。

3.5. 信息查看

这里以《3.3.Prefix Delegation 前缀代理场景》场景为例进行简单查看

在这里插入图片描述
//display dhcpv6 pool，查看地址池情况。

在这里插入图片描述
//display dhcpv6 server interface GigabitEthernet 0/0/0，查看接口功能。

在这里插入图片描述
//display dhcpv6 duid，查看设备 duid。

在这里插入图片描述
//display dhcpv6 client，查看设备作为 client 时的相关信息。

在这里插入图片描述
//display dhcpv6 client statistics，查看设备 DHCPv6 报文统计。

在这里插入图片描述在这里插入图片描述AR2 和 AR3 上都获取到相应地址。

3.6. 其他报文及协议细节

msg-type 8=Release：

在这里插入图片描述
//携带需要释放的 IA 信息，组播发送。

缺省路由：

需要注意的一点是，此种方式获得的缺省路由下一跳都为链路本地地址。

在这里插入图片描述
//注意 DHCPv6 use network route 路由优先级为 64，而 DHCP 默认为 60。

参考/附录：DHCPv6 常用 Option

每个 Option 可能仅出现在 DHCPv6 消息的 Option 区域中，并且只能出现一次。

如果一个 Option 确实出现多次，则每个实例都被视为单独的，并且 Option 的数据区域不得串联或以其他方式组合。只允许出现一次的选项称为 singleton option。

常用的 singleton option 有 Option3=IA_NA、Option4=IA_TA、Option16=Vendor Class、Option17=Vendor-specific Information 和 Option25=IA_PD。

通用 Option 格式：

在这里插入图片描述

  • option-code：2 字节，Option 类型。目前定义了约 150 种左右 Option。
  • option-len：2 字节，Option-data 字段长度。
  • Option-data：不定长。

Option1=Client ID option 和 Option2=Server ID option：

在这里插入图片描述

两种 Option 都只包含 DUID，用于唯一识别 Client 和 Server。通常与链路层地址相关，前文已进行 DUID 介绍。

Option3=IA_NA：

在这里插入图片描述

  • IAID：4 字节，IA 标识。IAID 在此 Client 的所有 IA_NAs 列表中必须是唯一的，并且 IA_NA、IA_TA 和 IA_PD 的编号空间是隔离的。
  • T1：4 字节，Client 请求或 Server 分配的 IA_NA 地址的生存期，以秒为单位表示。
  • T2：4 字节，Client 请求或 Server 分配的 IA_NA 地址的延长生存期，以秒为单位表示。
  • IA_NA-Option：可变长，与 IA_NA 相关的 Option。

@：每个 IA_NA 都包含一个非临时地址。
@：一个 DHCPv6 消息可能包含多个 IA_NA Option。
@：IA_NA Option 本身没有生存期或租期的概念，这一概念对应的是 IPv6 地址。当 IA_NA 中所有地址的 valid lifetimes（有效生存期）已过期时，可以将 IA_NA 视为已过期。
@：当 Client 发送该 Option 时，T1 和 T2 字段应当置 0。相应的 Server 忽略来自 Client 该消息的这两个字段。
@：建议 T1 和 T2 分别取值为 Server 所提供地址的 preferred lifetime（首选生存期）的 0.5 和 0.8 倍。如果 Server 所提供地址的 preferred lifetime（首选生存期）是无穷大的 0xffffffff，T1 和 T2 也应取该值。DHCP 为 IPv4 提供的是 0.5 和 0.875。
@：如果 Server 提供的 IA_NA-Option 中 T1 和 T2 字段为 0，表示更新 IA_NA 中的地址的时间由 Client 自行决定。如果 Client 已经确定自行决定地址时间，那么也将忽略 Server 提供的 IA_NA-Option 中 T1 和 T2 字段并处理消息的其余部分。
 
在这里插入图片描述
 
//address prefix 2001:DB8::/64 life-time 100 80 手动指定 DHCPv6 地址池的 Preferred lifetime 和 Valid lifetime 分别为 80s 和 100s。

在这里插入图片描述
 
/T1 和 T2 往往代表着 DHCPv6 Client 两次续租的时间，分别取 Preferred lifetime 的 0.5 和 0.8 倍。而 DHCP 的两次续租时间分别为 0.5 和 0.875 倍。
 在这里插入图片描述

//renew-time-percent rebind-time-percent 命令用于配置 IPv6 地址池的 T1 续租时间和 T2 重绑定时间。

Option4=IA_TA：

在这里插入图片描述

  • IAID：4 字节，IA 标识。IAID 在此 Client 的所有 IA_NAs 列表中必须是唯一的，并且 IA_NA、IA_TA 和 IA_PD 的编号空间是隔离的。
  • IA_TA-Option：可变长，与 IA_TA 相关的 Option。

@：每个 IA_TA 都包含一个临时地址。
@：一个 DHCPv6 消息可能包含多个 IA_TA Option。
@：IA_TA Option 本身没有生存期或租期的概念，这一概念对应的是 IPv6 地址。当 IA_TA 中所有地址的 valid lifetimes（有效生存期）已过期时，可以将 IA_NA 视为已过期。
@：IA_TA Option 不包含 T1 和 T2 概念。Client 可以发送携带该 Option 的 msg-type=5 的 RENEW 消息和 msg-type=6 的 REBINDING 消息，以延长 valid lifetime（有效生存期）。仅延长 valid lifetime（有效生存期）而不延长 preferred lifetime（首选生存期）意味着地址最终将处于弃用状态。
@：Client 通过向 Server 发送带有新 IAID 的 IA_TA Option 来获取新的临时地址，也可以在临时地址到期后重复使用 IAID 来标识具有新临时地址的新 IA_TA。

Option5=IA Address Option：

在这里插入图片描述

  • IPv6-address：16 字节，IPv6 地址。
  • preferred-lifetime：4 字节，IPv6 地址的 preferred lifetime（首选生存期），以秒为单位表示。
  • valid-lifetime：4 字节，IPv6 地址的 valid lifetime（有效生存期），以秒为单位表示。
  • IAaddr-options：可变长，与 IPv6 地址相关的 Option。

@：如果 Client 向 Server 发送的消息中携带该 Option，preferred lifetime（首选生存期）和 valid lifetime（有效生存期）应当置 0。相应的 Server 应忽略该字段。
@：Client 丢弃 Server 发送的消息中携带该 Option 中 preferred lifetime（首选生存期）大于 valid lifetime（有效生存期）的地址。
@：一个 Option3=IA_NA 或 Option4=IA_TA 中可以携带多个 Option5=IA Address Option。

Option6=Option Request Option（ORO）：

img

  • requested-option-code-n：不定长，携带 Client 所需请求的 option。作用类似 DHCP 报文中的 Option55=Parameter Request List。

@：Client 必须在 msg-type 1=Solicit、msg-type 3=Request、msg-type 5=Renew、msg-type 6=Rebind 和 msg-type 11=Information-request 消息中携带该 Option。
@：出于安全考虑，某些 Option-code 不应出现在 requested-option-code-n 字段中。例如，Option1=Client ID Option、Option2=Server ID Option、Option3=IA_NA、Option4=IA_TA、Option5=IA Address Option、Option6=Option Request Option 和 Option8=Elapsed Time 等。
@：只有 top-level 可能出现在 Option6=Option Request Option 中，并且只有 Client 请求 Option 后 Server 才会提供对应 Option 的响应。

Option7=Preference Option：

在这里插入图片描述

  • pref-value：1 字节，用于 Server 告知 Client 优先级。可用于多个 Server 时的地址优选。通常优选 pref-value 最大的 Advertise 中的 IA 信息。

在这里插入图片描述
 
// 服务器可以在 Advertise 报文中包含 Preference 选项，以便控制客户端对服务器的选择。

Option8=Elapsed Time Option：

在这里插入图片描述

  • elapsed-time：2 字节，Client 启动 DHCPv6 交互至今的时间，单位为 0.01s。这里指的是每一次交互过程而非整个 DHCPv6 启动的时间，是与 DHCPv6 中 Transaction ID 字段相关联的时间。

@：Client 必须在消息中包含 Option8=Elapsed Time Option 以通知 Server 自己试图完成 DHCP 交互的时间。
@：该字段可帮助备用 Server 了解主用 Server 的失效而提供响应。
@：elapsed-time 取 0xffff 时表示无穷大。

Option9=Relay Message Option：

在这里插入图片描述

  • DHCP-relay-message：不定长，在 msg-type 12=Relay-forward 消息中携带。Server 在 msg-type 13=Relay-reply 消息中复制回应。

Option13=Status Code Option：

在这里插入图片描述

  • status-code：2 字节，描述状态的编码。
  • status-message：使用 UTF-8 编码格式，介绍于 RFC3926 中。其值不得以空值结尾。如果不包含该 Option 通常表示交互成功。

Option14=Rapid Commit Option：

在这里插入图片描述

Client 计划以 msg-type 1=Solicit/msg-type 7=Reply 两步交互模型启动时使用。

@：两步交互模型使用需要 Client 和 Server 都支持相应功能。
@：如果 Server 支持该功能，应在 msg-type 7=Reply 消息中也携带 Option14=Rapid Commit Option。
@：由于网络中多台 Server 都携带租期进行响应的可能，应当设计 DHCP 服务，以便只有一台 Server 响应请求。

Option18=Interface-Id Option：

在这里插入图片描述

  • interface-id：不定长，用于标识来自 relay agent 的接口信息。

@：该 Option 必须仅出现在 msg-type 12=Relay-forward 和 msg-type 13=Relay-reply 消息中。
@：Server 回应 msg-type 13=Relay-reply 消息时，应保证该字段与 msg-type 12=Relay-forward 消息中字段一致。
 在这里插入图片描述

//dhcpv6 interface-id insert enable 在收到的 DHCPv6 报文中插入 Interface-ID 选项。

Option25=IA_PD：

在这里插入图片描述

  • IAID：4 字节，IA 标识。IAID 在此 Client 的所有 IA_PDs 列表中必须是唯一的，并且 IA_NA、IA_TA 和 IA_PD 的编号空间是隔离的。
  • T1：4 字节，Client 请求或 Server 分配的 IA_PD 地址的生存期，以秒为单位表示。
  • T2：4 字节，Client 请求或 Server 分配的 IA_PD 地址的延长生存期，以秒为单位表示。
  • IA_PD-Option：可变长，与 IA_PD 相关的 Option。

@：一个 DHCPv6 消息可能包含多个 IA_PD Option。
@：IA_PD Option 本身没有生存期或租期的概念，这一概念对应的是 IPv6 地址。当 IA_PD 中所有地址的 valid lifetimes（有效生存期）已过期时，可以将 IA_PD 视为已过期。
@：当 PD Client 发送该 Option 时，T1 和 T2 字段应当置 0。相应的 Server 忽略来自 Client 该消息的这两个字段。
@：建议 T1 和 T2 分别取值为 Server 所提供地址的 preferred lifetime（首选生存期）的 0.5 和 0.8 倍。如果 Server 所提供地址的 preferred lifetime（首选生存期）是无穷大的 0xffffffff，T1 和 T2 也应取该值。
@：如果 Server 提供的 IA_PD-Option 中 T1 和 T2 字段为 0，表示更新 IA_PD 中的地址的时间由 Client 自行决定。如果 Client 已经确定自行决定地址时间，那么也将忽略 Server 提供的 IA_PD-Option 中 T1 和 T2 字段并处理消息的其余部分。

Option26=IA Prefix Option：

在这里插入图片描述

  • preferred-lifetime：4 字节，IPv6 前缀的 preferred lifetime（首选生存期）。
  • valid-lifetime：4 字节，IPv6 前缀的 valid lifetime（有效生存期）。
  • prefix-length：1 字节，IPv6 前缀的长度。
  • IPv6-prefix：16 字节，IPv6 前缀。
  • IAprefix-options：可变长，与 IPv6 前缀相关的 Option。

@：如果 PD Client 向 Server 发送的消息中携带该 Option，preferred lifetime（首选生存期）和 valid lifetime（有效生存期）应当置 0。相应的 Server 应忽略该字段。并且 PD Client 发送时，不应将 prefix-length 字段置 0。
@：Client 丢弃 Server 发送的消息中携带该 Option 中 preferred lifetime（首选生存期）大于 valid lifetime（有效生存期）的地址。
@：Option26=IA Prefix Option 只能出现在 Option25=IA_PD 中。但其可以携带多个 Option26=IA Prefix Option。

Option32=Information Refresh Time Option：

在这里插入图片描述

  • information-refresh-time：4 字节，以秒为单位表示。相对于当前时间的持续时间，也即配置信息刷新时间。

@：Client 向 Server 发送 msg-type11=Information-request 的消息中 Option6=ORO 中必须携带该 Option。
@：此 Option 只能出现在 msg-type7=Reply 消息的 top-level options 区域中。并且值必须不小于 IRT_MINIMUM=600s 或者 Client 认为该值不小于 600s。如果 msg-type7=Reply 消息不包含此 Option，则 Client 认为其提供了值为 IRT_DEFAULT=86400s 的 Option。
@：取值 0xffffffff 时表示无穷大。

Option37=Relay Agent Remote-ID Option：

在这里插入图片描述

  • enterprise-number：4 字节，设备制造商于 IANA 注册的企业标识。
  • remote-id：不定长，remote-id。

@：remote-id 字段可以编码拨号连接的 caller ID，远程访问的用户名，DUID，VLAN，接口或端口标识符。
@：每个设备制造商必须确保 remote-id 对于其企业编号是唯一的。
@：DHCPv6 relay agents 可能会在 msg-type 12=RELAY-FORW 消息中携带该 Option，但 Server 的回应消息 msg-type 13=RRELAY-REPL 可能不会携带该 Option。这一点与 DHCP 不同。
@：Option37=Relay Agent Remote-ID Option 的作用相当于 DHCP 的 Option82=Relay Agent Information 属性。
 
在这里插入图片描述

// dhcpv6 remote-id insert enable 用于 DHCPv6 中继代理插入 Remote-ID（Option37) Option。

Option79=Client Link-Layer Address Option：

在这里插入图片描述

  • link-layer type：2 字节，Client 的链路层地址类型。
  • link-layer address：不定长，Client 的链路层地址。

IPv6/ICMPv6 - 原理介绍 + 报文分析 + 配置示例

fengxingzhe008 已于 2024-11-27 16:20:01 修改

本文将以 IPv6 的常用协议上进行介绍，以详细介绍 IPv6 的相关内容。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

相关资料：

ICMPv6/ND 协议较为复杂，建议详读 1.3.2、3.2、4.2 等章节或阅读其他资料。

另需说明的是本文档旨在介绍相关原理，对于不同设备及厂家的 ND 实现上不做深究。有意者建议阅读相关设备资料。

例如 CISCO 在 ND 的实现上，非请求 RA 的发送以 600s 为周期 (也可调整)；DAD 检测默认 3 次。

而 HW 实现上，非请求 RA 的发送参考了 RFC 的随机周期，并且 DAD 依照 RFC 描述也仅进行了 1 次。

此外对于服务器设备的 ND 实现也比较复杂，有意者可查阅相关资料。

IPv6 是一种新型的网络结构，并且通常与 ICMPv6/Neighbor Discovery 协议共生存在。本文旨在对 IPv6 的基础内容进行介绍。

个人能力有限，如有疑问欢迎留言指导～

1.IPv6 基础内容

1.1.IPv6 简介 / 分类

IPv6：

@新一代的 IP 用于替代 IPv4 的下一代 IP 协议

@核心解决 IPv4 地址不足的问题

IPv6 地址：

IPv6 地址共 128bits，使用冒号分隔的 16 进制表达。128=16*8

@通用格式为 X:X:X:X:X:X:X:X。X=16 进制。

举例当 X=2031 时，
2031=0010 0000 0011 0001

@压缩格式。

当 X 组中高位出现 0 时可进行省略，当每个 X=0 时，可进行”: :“缩写。但是”: :“缩写只可缩写一次。

举例，3001::1=3001:0000:0000:0000:0000:0000:0000:0001

其他还有内嵌 IPv4 的 IPv6 地址格式，暂不做介绍。

关于 IPv6 格式地址格式表达，可参考 2010 年发布的 RFC5952；

IPv6 分类

IPv6 的地址总共可分为 3 类：单播地址、组播地址、任播地址。

单播地址：

全球单播地址 = =2000::/3，占据 IPv6 的 1/8。

2000:: 至 3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

唯一本地单播地址 = =fc00::/7，占据 IPv6 的 1/2^7。类似 IPv4 的私网地址，但是可全球唯一。

FC00:: 至 FDFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

链路本地地址 = =fe80::/10，占据 IPv6 的 1/2^10。

FE80:: 至 FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

@：在全球单播地址中，又会有一些地址有特殊用途。 比如 2001:db8::/32 作为保留前缀，以便在文档中使用。
IANA 发布 *IPv6 Global Unicast Address Assignments* 进行了详细总结，有意者可阅读相关资料。

@：链路本地地址会在启用 IPv6 接口后自动生成，用于在接口链路上进行本链路上的通信和 ICMPv6 等协议交互。本链路通信指的是在链路上自动通告接口的 128 位 IPv6 路由，通过这种方式实际上可以实现同一链路两端不同网段通信的效果。

@：在这里插入图片描述
// 链路本地地址也可手动配置，链路上的链路本地地址只有 1 个。

@：在这里插入图片描述
//ping 链路本地地址需要指定链路。因为只有本地链路有效（链路本地地址具有链路本地范围），这也意味着同一台设备的不同接口可以具有相同的链路本地地址。

内嵌 IPv4 地址= =0000::/8，可用于协议报文的源地址。

:: 至 00FF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

未指定地址= =::/128，可用于协议报文的源地址。

内部环回地址= =::1/128。类似 IPv4 的 127.0.0.1/32，操作系统的内部通信地址。

组播地址：

指定组播地址= =ff00::/8，占据 IPv6 的 1/2^8。

FF00:: 至 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

请求节点组播地址= =FF02:1:FF00.0000/104。主要用于 ICMPv6 地址使用。FF02:0:0:0:0:1:FF00:0 至 FF02:0:0:0:0:1:FFFF:FFFF

1@：请求节点组播地址是为设备上的每个单播地址自动创建的，将请求节点组播前缀 FF02:0:0:0:0:1:FF00::/104 附加到单播地址的低阶 24bit 上即可生成请求节点组播地址。
2@：每个节点必须为分配给它的每个单播和任意播地址加入的一个组播地址，用于 DAD 地址重复检测和地址解析。
3@：与链路本地地址相同，只在本地链路上有效

在具体的组播地址上

在这里插入图片描述Flag：4bits，目前只有 0000 和 0001 两种取值。0000 表示为 IANA 分配的永久组播地址，0001 为临时组播地址。

Scope：4bits，组播数据流在网络中发送的范围。

可参考 2014 年发布的 RFC7346
1 标识接口范围 (不可传出，设备内部通信)，
2 标识链路本地也即仅在二层链路，
3 标识区域本地范围，
4 标识管理本地范围，
5 标识站点本地范围，
8 标识组织本地范围，
E 标识全局范围等

Group ID：32bits，同 IPv4 组播地址。建议使用最后 32bits。

常见的组播地址：
@Node-Local=
FF01::1 为所有节点组播；
FF01::2 为所有路由器组播
@Link-Local=
FF02::1 为所有节点组播
FF02::2 为所有路由器组播
FF02::5 为 OSPFv3 路由器组播
FF02::6 为 OSPFv3 路由器 DR 组播
FF02::9 为 RIP 路由器 DR 组播
FF02::13 为 PIM 路由器 DR 组播

任播地址：使用较少

任播地址与单播地址使用相同的地址空间；配置时须明确表明是任播地址以此区别单播和任播。可以用于距离用户最近的地址传输。例如在 ospf 不同区域宣告相同的任意播地址，通过 cost 优选可以让用户优选距离最近的节点。

IPv6 组播 MAC 映射：
将组播 IP 的后 32bits，叠加至 33:33 后形成 48bits 的 mac 地址。

1.2.IPv6 报文格式 / 配置

关于最新的 IPv6 报文格式相关内容，可参考 2017 年发布的 RFC8200。

链路层：

Ethernet Type=0x86dd

常用 Ethernet Type 举例：
802.1q Ethernet Type=0x8100；
ARP Ethernet Type=0x0806；
IPv4 Ethernet Type=0x0800；
**MPLS Ethernet Type=0x8847；**等
其他 Ethernet Type 可参考 IANA 发布的 IEEE 802 Numbers。

IPv6 报文格式：在这里插入图片描述Version：4bits，IPv6 固定为 6。IPv4 则固定为 4。

Traffic class：8bits，QOS 分类。功能类似于 IPv4 的 DSCP。

Flow Label：20bits，流标签。通常可用于区分是否是同一个流。例如 TCP/UDP 通过 5 元组确定流，而 IPv6 可根据该信息判断是否是同一个流。

Payload length：16bits，有效载荷的长度，单位 byte 字节。除去 IPv6 基本报文的长度，也即载荷长 + IPv6 扩展报文长。

Next header：8bits，下一报头。携带的上层报头的信息类型，也即扩展 IPv6 头部的类型或者上层协议的类型。

Hop limit：8bits，条数限制。与 IPv4 的 TTL 功能相似。

Source Address：128bits，报文的源地址。

Destination Address：128bits，报文的目的地址。

Extension Headers：IPv6 的扩展头部，长度不定。IPv6 使用扩展头部来扩展其他功能，扩展性好。另一个好处是只携带所使用的功能，减小 IPv6 报文的长。

常用扩展报头有：

1@逐跳选项报头(Hop-by-Hop Options header，Next Header=0)= 该选项主要用于为在传送路径上的每跳转发指定发送参数，传送路径上的每台中间节点都要读取并处理该字段。(每台 IPv6 都需要处理的参数)

应用场景：用于巨型载荷；用于路由器提示；用于资源预留。

2@目的选项报头(Destination Options header，Next Header=60)= 目的选项报头携带了一些只有目的节点才会处理的信息。目前，目的选项报文头主要用于移动 lPv6

3@路由报头(Routing header，Next Header=43)= 路由报头和 IPv4 的 Loose Source and Record Route 选项类似，该报头能够被 lPv6 源节点用来强制数据包经过特定的路由器。

4@分片报头(Fragment header，Next Header=44)= 同 IPv4 一样，IPv6 报文发送也受到 MTU 的限制。当报文长度超过 MTU 时就需要将报文分段发送，而在 IPv6 中，分段通过分段报头来实现。

5@认证报头(Authentication header，Next Header=51)= 该报头由 IPSec 使用，提供认证、数据完整性以及重放保护。它还对 IPv6 基本报头中的一些字段进行保护。

6@封装安全净载报头(Encapsulating Security Payload header，Next Header=50)= 该报头由 IPSec 使用，提供认证、数据完整性以及重放保护和 IPv6 数据报的保密，类似于认证报头。

@RFC8200 规定当有多个扩展报头时，必须按照如下顺序出现：IPv6 基本报头、逐跳选项扩展报头、目的选项扩展报头、路由扩展报头、分片扩展报头、授权扩展报头、封装安全净载报头、目的选项扩展报头（指那些将被分组报文的最终目的地处理的目的选项报头）、上层扩展报头。

@但是 IPv6 节点必须接受并尝试以任意顺序处理扩展标头，并在同一数据包中出现任意次数。“逐跳选项” 标头除外，该标头仅限于仅紧跟在 IPv6 标头之后。 尽管如此，仍强烈建议 IPv6 数据包源遵守上述规定。

@并且，IPv6 在源目的设备之间不允许分片。而是利用 PMTU 路径 MTU 检测确认链路上的允许通过的最大 MTU。

IPv6 的配置方式：

IPv6 的一个特性是链路复用，也即一条链路上支持多个 IPv6 前缀。

1@手工配置：

在这里插入图片描述

2@EUI-64 分配：

将 MAC 地址的第 7bit 置 1 (也有其他方案，指定第 7bit 进行反转)，并将接口 48bits 的 MAC 地址从中间插入固定长度 16bit 的 FFFE，共 64bits。将该 bits 转成 IPv6 的格式，填充到所分配的前缀上。

对于前缀小于 64，在前缀与后 64bit 间补 0；大于 64，则将冲突 eui-64 部分删除。

在这里插入图片描述

1@在单播 MAC 地址中，第 1 个 Byte 的第 7bit 是 U/L (Universal/Local, 也称为 G/L，其中 G 表示 Global) 位，用于表示 MAC 地址的唯一性。如果 U/L=0，则该 MAC 地址是全局管理地址，是由拥有 OUI 的厂商所分配的 MAC 地址；如果 U/L=1，则是本地管理地址，是网络管理员基于业务目的自定义的 MAC 地址。

2@在单播 MAC 地址中，第 1 个 Byte 的第 8bit 决定单播和多播。

3@而在在 EUI-64 接口 ID 中，第 7bit (也即 IPv6 地址后 8 个字节的第一个字节) 的含义与 MAC 地址正好相反，0 表示本地管理，1 表示全球管理，所以使用 EUIl-64 格式的接口 ID，U/L 位为 1，则地址是全球唯一的，如果为 0，则为本地唯一。这就是为什么要反转该位。

3@IPv6 unnumbered：

一个接口如果没有 IP 地址就无法生成路由也就无法产生 IP 报文转发报文。IPv6 unnumbered 就是路由器一个接口上没有配置地址，但借用其他其他接口的地址进行报文的路由转发。

以太口不能配置成无编号 (unnumbered) 接口。
串口中 (同步口) 中，使用也受限制。比如当封装成 帧中继的时候，只有点对点
的子接口才允许配置成 unnumbered。另外 X.25 封装也是不允许的。

Cisco 2500 系列 unnumbered 地址配置示例：// 关于本场景下的路由传递和出接口问题不做详细延申。在这里插入图片描述
// 指定串口共用 Ethernet0 的地址。

4@SLAAC：

利用 Stateless Address Autoconfiguration 协议进行 IPv6 地址的动态配置。

第 6 章节进行相关介绍。

5@DHCPv6：

利用 DHCPv6 协议进行 IPv6 地址的动态配置

1.3.IPv6 的扩展介绍

1.3.1.PMTU

通常情况下 IPv6 在源目的设备之间不允许分片。而是利用 PMTU 路径 MTU 检测确认链路上的允许通过的最大 MTU。

PMTU 可参考 2017 年发布的 RFC8201，原理上利用 ICMPv6 的 Packet Too Big (PTB) 发现路径上的 MTU。源节点向目的节点发送载荷不断减小的 MTU 值，以确认 PMTU。

1@：源节点将第一跳 MTU 作为初始 PMTU 向目的节点发送 ICMPv6，如果可正常通信就将该 MTU 作为 PMTU。

2@：在中间路径上收到限制，则在中间节点返回 ICMPv6 的 Packet Too Big (PTB) 并携带正确的 MTU 值。源节点重新携带该 MTU 重复上述过程直到在整个路径上都获得通过。

3@：考虑到拓扑变化的可能，源节点周期性地增加其假设的 PMTU。一般 PMTU 不变化，因此该周期应较大。

RFC8201 规定节点收到 ICMPv6 的 Packet Too Big (PTB) 后的 5min 内不进行检测。建议定时器设置为 10min。

4@：目的地址为组播场景下，可能有多个 PMTU。此时选择该路径集中最小的 PMTU 值。ECMP 场景下，也同样适用。

5@：节点不得收到 ICMPv6 的 Packet Too Big (PTB) 就更改 PMTU，因为可能是无效的信息。这通常指的是转发的 PTB 报文。

6@：PMTU 与到目的地址的 Path 相关联，因此可将该 PMTU 与本地目的地址相关的缓存关联起来。如果启用了 IPv6 的 Flow 字段，此时可将 Flow ID 作为 Path 的代表。也就将 Flow ID 和 PMTU 关联起来。

7@：在使用 IPv6 扩展报文路由报头情况下，目的地址选择的是 Segment List 的最后一个地址。

除此之外还有 Packetization Layer Path MTU Discovery (PLPMTUD)-RFC4821，主要用于 TCP 等包封装协议上确认路径 MTU。可以不基于 ICMPv6 来实现。这里不做介绍。

1.3.2.IPv6 的数据结构概念

IPv6 主机 / 节点通常会在本地为接口维护相应的表项 / 缓存，在此 参考 2007 年发布的 RFC4861 进行介绍说明。

对于多归的出接口场景等暂不说明。并且对于移动 IPv6 也可能添加其他的数据结构概念。有时也可将如下概念融合到一张路由表中。

Neighbor Cache：到邻居传递数据的缓存。包括邻居在活动链路上的单播地址、邻居的链路层地址、邻居的路由标识、指向等待地址解析完成的任何排队数据包的指针，等。

在进行邻居不可达检测时，还包括使用的不可达检测算法、未应答探测的数量、下一次不可达检测的剩余时间。

Neighbor Cache 支持静态配置：在这里插入图片描述
//ipv6 neighbor 用于在接口下配置静态 Neighbor Cache。

Destination Cache：到目标传递数据的缓存。包括目标的活动状态和到目标相关的下一跳邻居的 Neighbor Cache。可被 ICMPv6 的重定向报文更新。

Prefix List：活动链路上地址的集合。前缀列表缓存主要通过 RA 报文交互，并且每一条目都有对应的生存时间。

链路本地地址前缀具有无穷大的生存时间，该定时器并且不可被 RA 报文修改。

Default Router List：数据包被传递的路由器列表。路由器列表条目指向邻居缓存中的条目，选择算法优先选择具有良好可达性的邻居。

在实际进行数据转发时的原则可能不同。(例如可以选择最长掩码匹配)。但使用该路由器的所有 Destination Cache 条目都必须共享路由器的 Neighbor Cache 条目，以避免多余的邻居不可达性检测探测。

传递数据时的算法：节点通过 Destination Cache、Prefix List 和 Default Router List 确认到达目标的下一跳。这一动作可称为下一跳确认，并且将结果可以存储 Destination Cache 中。随后通过 Neighbor Cache 确认邻居的链路层地址。

1@：发送方根据前缀列表执行最长前缀匹配，以确定数据包的目的地是在链路上还是在链路外。在链路上将邻居地址作为目标地址，否则由 Default Router List 确认下一跳路由器。

2.1@：如果下一跳节点已知，就选择下一跳节点的链路层地址

2.2@：如果没有对应条目，就创建相应的条目并初始化为 INCOMPLETE。同时启动地址解析。在 NS 和 NA 交互完成创建 Neighbor Cache 条目后便可正常传递数据。

3@：组播数据包的下一跳总是组播地址，并认为其总在活动链路上。

Neighbor Cache 条目的 5 种状态：

1@：INCOMPLETE。地址解析时所展现的状态。也即已经发出了一个发往请求节点组播地址的 NS 报文，但是未收到 NA 报文。

类似于发出了特定组播为目的 IP 的 ARP，但未收到 ARP 回应。
收到地址解析 NA 回应时过渡到 REACHABLE 状态，否则之间删除条目。
2@：REACHABLE。在最后的 Reachable_Time 毫秒（节点常数 30,000ms）内收到了邻居转发能力的确认。转发数据包时无特殊动作。
在最多 30s 前，已经确认邻居可达。如果持续流量 / 持续确认，则持续保持该状态。

在这里插入图片描述
//display ipv6 neighbor 用于查看 Neighbor Cache 状态。

该 REACHABLE 状态持续时间也可更改：在这里插入图片描述
//ipv6 nd nud reachable-time 用于配置 Neighbor Cache 的 REACHABLE 状态持续时间。该命令除控制本设备邻居表项的老化时间外，还可填充于 RA 报文中帮助主机配置邻居可达时间。

这里 30s 的 Reachable_Time 指的是 REACHABLE 可以维持的最大时间。(不经流量刷新 / 不经邻居状态检测)

3@：STALE。收到了邻居转发能力的确认。在转发数据包前无特殊动作。当接收到可更新缓存的链路层地址的非请求型 ND 消息时，进入 STALE 状态。

邻居的可达性存疑，但在发送流量前不进行可达性验证。一般 nd 缓存在仅在 REACHABLE 后的 30s 内没有刷新就会过渡到该状态。

处于该状态时，Neighbor Cache 可正常使用但需要进行可达性检测进行验证。

4@：DELAY。自收到上一次邻居转发能力的确认，并且在最后一次 DELAY_FIRST_PROBE_TIME（节点常数 5s）内发送了数据包以来，已过去了超过 Reachable_Time 毫秒（节点常数 30,000ms）。

虽然并且最近向邻居发送了流量，但是邻居的可达性仍然存疑。然而，与其立即探测邻居，不如将发送探测延迟一段时间，以便给上层协议一个不通过邻居请求就可达性确认刷新条目的机会。

收到了可达性确认就转变为 REACHABLE 状态。

5@：PROBE。如果在进入 DELAY 状态后的 DELAY_FIRST_PROBE_TIME（节点常数 5s）内未收到可达性确认，则发送邻居请求并将状态更改为 PROBE。

并每 Retrans_Timer 毫秒（节点常数 1,000ms）重新发送 NS，直到接收到可达性确认。也即正在进行可达性检测的状态。

邻居的可达性存疑，因此发送单播 NS 进行邻居探测。在这里插入图片描述
// 在 MAX_MULTICAST_SOLICIT 次（节点常数，3 次）的 NS 消息后没有收到 NA 报文，也即地址解析失败。此时将会删除 Neighbor Cache。

注意：每次发送 NS 后都需要等待 Retrans_Timer (节点常数，1000ms) 时间才可进行判定。

2.ICMPv6

2.1.ICMPv6 简介

ICMPv6 是 IPv6 的基础协议之一，用于向源节点传递报文转发的信息或者错误，并执行其他互联网层功能。例如类似 IPv4 中 ARP 等的相关功能。

ICMPv6 是 IPv6 的一个组成部分，是每个 IPv6 节点必须完全实现基本协议。

ICMPv6 的基本格式：IPv6 的 Next Head 标识 58

在这里插入图片描述
Type：ICMPv6 类型，1 字节。
Code：代码，1 字节。在 TYPE 字段的基础上，用来创建更详细的报文等级。
CheckSum：校验和，2 字节。用于校验 ICMPv6 和部分 IPv6 扩展头。

总的来说 ICMPv6 可分为两大类：
差错消息 error message：Type=0-127;
通知消息 informational message：Type=128-255。

2.1.1.ICMPv6 差错消息

*2006 年发布的 RFC4443* 给出常用的 ICMPv6 差错类型：
这一情况不包括拥塞导致的丢包。

TypeCodeDescription
1 - 不可达0没有路由到达目的地
1与目的地的通信由于管理被禁止
2超过了源地址分类的范围
3地址不可达
4端口不可达
5源地址的入口 / 出口策略失败
6拒绝路由到达目的地
2 - 包太大0包太大
3 - 超时0hop-limit 超时
1分片重组超时
4 - 参数错误0-3各种参数错误
127XICMPv6 差错报文扩展保留

IANA 收集了一些 ICMPv6 的详细的 Type 字段分类，感兴趣者可以 点击此处阅读查看。

ICMPv6 的源目的 IPv6：

与 IPv4 相同，ICMPv6 报文必须确认源目的 IPv6 地址。当地址为单播地址时，无需多言。

当目的地址为组播地址 / 任播地址 / 不属于任何节点的单播地址时，回应报文必须是从属于节点的单播地址。

ICMPv6 的处理规则：

1@：如果目的节点收到未知类型的差错消息包 ICMPv6，必须传递至产生该数据包的上层进程。

2@：如果目的节点收到未知类型的通知消息包 ICMPv6，必须静默丢弃。

3@：在传递 ICMPv6 差错消息时，必须在不超过 MTU 的情况下一次涵盖尽可能多的差错信息。

4@：在收到某些报文情况下，禁止发布 ICMPv6 的差错消息。

例如，ICMPv6 差错消息，ICMPv6 重定向消息，目的地址为组播 IPv6 且提示数据包太大或提示参数错误，链路组播 IPv6 和链路广播 IPv6 以及其他不属于单个节点的 IPv6 报文。

5@：为了防止上层程序未注意到错误，ICMPv6 的差错报文的产生速率应当也受到限制。但是 RFC4443 并未给出明确的指导，只说明可以通过令牌桶来做限制。

2.1.2.ICMPv6 通知消息

ICMPv6 常用通知消息

TypeCodeDescription
1280回显请求
1290回显应答
133X路由请求 RS
134X路由通告 RA
135X邻居请求 NS
136X路由通告 NA
137X重定向
143XMLDv2

Type128 和 Type129 功能与 IPv4 的 ICMP 的 ping 几乎完全相同。而其他类型的 ICMPv6 主要用于实现 IPv6 的邻居可达性检测、地址重复检测，等一些其他功能。

2.2.ICMPv6 的其他考虑

ICMPv6 的防攻击：

1@：使用 IPv6 的扩展头进行加密认证。

2@：IPv6 的组播源应正确设置，以防止其他节点对自身的发送差错报文造成的 DOS 功能。

3@：ICMPv6 通常要将结果上送至上层协议，例如 TCP 等，因此上层协议需要对 ICMPv6 做相应的检查以避免可能造成的 TCP-Attack。

4@：ICMPv6 的差错消息，在某些场景下是不会得到解决或解决时间比较长。

3.Neighbor Discovery 协议

3.1.ND 所涉及的基本概念

Neighbor Discovery 协议的作用：

借用 ICMPv6 的 Type133-137 类型报文实现如下功能。

1@-Router Discovery：主机用来确定可为自己路由数据的相邻路由器。

2@-Prefix Discovery：节点用来确定所连接链路上为活动链路 (on-link) 的一系列地址前缀。

3@-Parameter Discovery：节点 (主机和路由器) 用来确认链路参数或网络参数。

4@-Address Autoconfiguration：节点用来无状态下的地址自动获取。

5@-Address resolution：节点用来在活动链路 (on-link) 给定目标地址的地址解析。

6@-Next-hop determination：节点用来映射目的 IP 与传递流量的目的 IP。

7@-Neighbor Unreachability Detection：节点用来确定邻居是否可达，邻居的地址是否改变。

8@-Duplicate Address Detection：节点用来确定地址是否重复。

9@-Redirect：路由器通知主机一个更合适的下一跳。

所涉及到的 IPv6 地址：

all-nodes multicast address 所有节点组播地址：ff02::1，发送给所有主机和路由器；

all-routers multicast address 所有路由器组播地址：ff02::2，发送给所有路由器；

solicited-node multicast address 请求节点组播地址：ff02:1:ff00.0000/104；

link-local address 链路本地地址：fe80::/10，只具有链路范围的单播地址；

unspecified address 未指定地址：缺少地址的保留地址，例如::/128。不可作为报文的目的地址。

所支持的链路类型：

ND 协议支持多种链路类型：PtoP、组播、NBMA、shared media、可变 MTU、同步可达性。

PtoP 链路下的 ND 协议：//PtoP 链路下不在执行 ND 的地址解析。在这里插入图片描述
// 此处直接进行 NS/NA 的交互。

尽管实际操作可能不同。

3.2.ND 报文格式

接下来首先介绍下 ND 协议所涉及的 5 种 ICMPv6 报文的基本报文格式：Router Solicitation、Router Advertisement、Neighbor Solicitation、Neighbor Advertisement和Redirect。

3.2.1.RS 和 RA

Router Solicitation 路由请求消息：

在这里插入图片描述1@IP Fields：

源地址= = 发送报文的源接口地址 or 未指定地址，

目的地址= = all-routers multicast address=ff02::2，

Hop Limit= = 255。

2@Type：133，

3@Code：0，

4@Checksum：校验 ICMPv6 和部分 IPv6 扩展头，

5@Reserved：4 字节必须置为 0，

6@Valid Options：发送者的 Source link-layer address Option；如果是未指定地址则必须置空。

//RS 消息示例：

*RFC4861 规定源 IP 地址为源接口地址，更新后改为链路本地地址 *。

在这里插入图片描述

Router Advertisement 路由通告消息：

在这里插入图片描述

1@IP Fields：

源地址= = 发送报文的链路本地地址

目的地址= = 调用路由器请求的源地址或者 all-nodes multicast address=ff02::1，

Hop Limit= = 255。

2@Type：134，

3@Code：0，

4@Checksum：校验 ICMPv6 和部分 IPv6 扩展头，

5@Cur Hop Limit：8 字节的无符号整数，由传出该报文时 IPv6 头部的 Hop Count 字段填充。

// 设备初始发送的 IPv6单播报文的跳数限制或作为 RA 报文中的参数，帮助主机自动配置跳数限制。默认值是 64。在这里插入图片描述
//ipv6 nd ra hop-limit 用来配置 RA 报文的跳数限制。

6@5 个 bit 位：

M-bit是管理地址配置标记位。置 1 时表示地址可通过 DHCPv6 获得，并且此时 O-bit 可忽略。

O-bit是其他配置标记位。置 1 时表示除地址外的其他信息可通过 DHCPv6 获得。

当 M-bit 和 O-bit 都可置 0，表示不可从 DHCPv6 协议获取信息。

可在路由器上手动配置：在这里插入图片描述

H-bit是本地代理标记位。主要与移动 IPv6 相关，移动 IP 可以实现将设备物理连接点从一个网络移动到另一个网络的无缝实现切换。关于移动 IPv6 的相关资料 可参考 2011 年发布的 RFC6275 和 CISCO 提供的资料IP Mobility: Mobile IP Configuration Guide, Cisco IOS Release 15M&T。CISCO 将 Home agent 本地代理描述为移动 IPv6 的 3 个核心组件之一。置 1 时，需要刷新本地代理列表。

Preference-bit是路由器优先级，共 2bits。00 为 Medium，01 为 High，11 为 Low。

当主机所在的链路中存在多个交换模块时，主机需要根据报文的目的地址选择转发交换模块。在这种情况下，交换模块通过发布默认路由器优先级和特定路由信息给主机，提高主机根据不同的目的地址选择合适的转发交换模块的能力。

路由器发送 RA 报文的路由器优先级默认为 medium：在这里插入图片描述
此时如果节点有多条路由，可优选 High 的 Prefix 产生的路由。

Proxy-bit是代理标记位。

7@Router Lifetime：路由器生存时间，16 位无符号整数。与默认路由器关联的生存期，以秒为单位。最大值 65535s (RFC8391 更改为此值)。置 0 时表示不可作为默认路由器，并且不可出现在默认路由器列表中。Router Lifetime 仅适用于作为默认路由器的路由器应用；对包括在其他消息字段或选项中的信息不适用。需要对它们的信息规定时间限制的选项有它们自己的生存期字段。

// 路由器生存时间默认 1800s。最小 MaxRtrAdvInterval (RA 报文发送的最大时间)，最大 9000s。详情查看 4.1 章节相关介绍。在这里插入图片描述

8@Reachable Time：32 位无符号整数。此时间以毫秒计。在收到可达性确认后节点假定该邻居是可到达的。它由 Neighbor Unreachability Detection 算法使用。

9@Retrans Timer：32 位无符号整数。重发的 Neighbor Solicitation 消息间隔时间，以毫秒计。由地址解析和 Neighbor Unreachability Detection 算法使用。

需要注意 RA 的重传和 NS 的重传。一般来说 RFC 给出 Neighbor Cache 的 Reachable_Time (节点常数，30000ms) 和 RETRANS_Timer (节点常数，1000ms) 可等效为这两个值。

10@可能用到的 Option 字段：Source link-layer address、MTU 和 Prefix Information。

//RA 消息示例：

在这里插入图片描述

3.2.2.NS 和 NA

Neighbor Solicitation 邻居请求消息：

在这里插入图片描述

1@IP Fields：

源地址= = 发送报文的接口地址或 (在 DAD 场景下，使用) 未指定地址

目的地址= = 目标地址的请求节点组播地址或目标地址

Hop Limit= = 255。

2@Type：135

3@Code：0

4@Checksum：校验 ICMPv6 和部分 IPv6 扩展头

5@Reserved：4 字节

6@Target Address：目标地址，不可为组播地址

7@可能用到的 Option 字段：Source link-layer address。

//NS 消息示例：

在这里插入图片描述

Neighbor Advertisement 邻居通告消息：

在这里插入图片描述1@IP Fields：

源地址= = 发送报文的接口地址

目的地址= = NS 报文的源地址；如果 NS 源地址为空或者 NA 不是对 NS 的回应报文则使用 all-nodes multicast address=ff02::1

Hop Limit= = 255。

2@Type：135

3@Code：0

4@Checksum：校验 ICMPv6 和部分 IPv6 扩展头

5@Flags：1 字节的标志位

R-bits

路由器标识位。置 1 时标识发送 NA 报文的设备为路由器，可用于邻居不可达检测。

S-bits

请求标识位。置 1 时标识该 NA 报文是对 NS 报文的回应。在邻居不可达检测时置 1 表明邻居时可达的。在组播或未分配地址情况下，必须置 0。

O-bits

重写标志位。置 1 时标识收到该 NA 报文的设备将重写现存的缓存条目并更新链路层地址 MAC 地址。置 0 时，不更新链路层 MAC 地址但更新缓存条目。对发往任播地址、不包含 Target Link-Layer Address option 的 NA 报文或者发送的是代理的请求应答类型的 NA 报文必须置 0，其他场景必须置 1。

6@Reserved：29-bits 的保留位。

7@Target Address：对 NS 的请求回应类型的 NA 报文为 NS 对应地址，非请求回应 / 主动发送的 NA 报文为链路层地址。不可为组播地址。

8@可能用到的 Option 字段：Target link-layer address。

//NA 消息示例：

在这里插入图片描述

3.2.3.Redirect 和 ND 的 Option

Redirect 重定向消息：

在这里插入图片描述1@IP Fields：

源地址= = 发送报文接口的链路本地地址

目的地址= = 触发重定向的数据包的源地址

Hop Limit= = 255。

2@Type：137

3@Code：0

4@Checksum：校验 ICMPv6 和部分 IPv6 扩展头

5@Reserved：保留位，4 字节

6@Target Address：用于 ICMP 目标地址的更好的第一跳的 IP 地址。当目标是通信的实际端点，即目标是邻居时，目标地址字段必须包含与 ICMP 目标地址字段相同的值。否则，目标是更好的第一跳路由器，目标地址必须是路由器的链路本地地址，以便主机可以唯一地识别路由器。

7@Destination Address：被重定向到的地址

8@可能用到的 Option 字段：Target link-layer address、 Redirected Header

重定向生效的相应原则：其他内容不做过多介绍

  • 报文的目的地址不是一个组播地址。
  • 报文并非通过路由转发给路由器。
  • 经过路由计算后，路由的下一跳出接口是接收报文的接口。
  • 路由器发现报文的最佳下一跳 IP地址和报文的源 IP 地址处于同一网段。
  • 路由器检查报文的源地址，发现自身的邻居表项中有用该地址作为全球单播地址或链路本地地址的邻居存在。

常见 Options 字段：Options 字段必须是 8 字节的倍数

1/2@Source/Target Link-layer Address：

在这里插入图片描述1@Type：1 字节，1 标识发送者的 Source Link-layer Address、2 标识目标的 Target Link-layer Address。

2@Length：1 字节，整个 Option 字段的长度。

3@Link-Layer Address：可变长的链路层地址

除了上文描述的每种 ND 消息所可以携带的该 Option 外，其他携带该 Option 字段的 ND 报文应当忽略其 ND 报文的该 Option 字段。其他 Option 也同理。（也即仅应识别和响应每种 ND 消息所要求的 Option 字段。）

3@Prefix Information：

在这里插入图片描述
1@Type：1 字节，必须为 3。

2@Length：1 字节，必须为 4。

3@Prefix Length：1 字节，无符号整数但取值 0-128。

4@L-bit：1bit 的标志位。置 1 时标识该前缀位于活动链路上 (on-link)。

注意置 0 时，表示不传递关于链接上确定的信息，也即不生成相应的直连路由。并且不得解释为前缀所覆盖的地址是链接外 (off-line) 的。
只可通过 L-bit 置 1 且 Lifetime 置 0 撤销先前的活动链路状态 (on-line)。

5@A-bit：1bit 的标志位。置 1 时标识该前缀可用于无状态地址配置

6@Valid Lifetime：32-bits 无符号整数。标识该前缀用于链路上 (on-link) 的时间，单位秒 /s。0xffffffff 标识无穷大。

7@Preferred Lifetime：32-bits 无符号整数。标识该前缀用于无状态地址自动配置时地址的生存时间，单位秒 /s。0xffffffff 标识无穷大。

Preferred Lifetime 不得大于 Valid Lifetime。

在这里插入图片描述

关于 Preferred Lifetime 和 Valid Lifetime 的详细表述可查看本文第 6 章节。

8@Prefix：IPv6 前缀。不得是链路本地地址。

Prefix information:

在这里插入图片描述 最终生效：在这里插入图片描述

// 本 Option 通常用于 SLAAC，用于为主机提供 IPv6 前缀以供自动生成 IPv6 地址。

4@Redirected Header：

在这里插入图片描述
1@Type：1 字节，必须为 4。

2@Length：1 字节，不定长。

3@IP header + data：重定向相关内容。

5@MTU：

在这里插入图片描述
1@Type：1 字节，必须为 5。

2@Length：1 字节，必须为 1。

3@MTU：32 位无符号整数。链路推荐 MTU，确保链路上使用相同的 MTU。可用于不同链路的最大 MTU 不同的异步传输场景下。

6@Route Information：

在这里插入图片描述

Route Information：将特定的路由信息发布给本网段主机。主机可以使用这些路由来发送报文。

在这里插入图片描述
//ipv6 nd ra route-information 用来配置 RA 报文中的路由选项信息。主机收到包含路由选项信息的 RA 报文后，会更新自己的路由表。当主机向其他设备发送报文时，通过查询该列表的路由信息，选择合适的路由发送报文。

此处仅初步介绍了 ND 协议的报文字段，详细的报文交互和相应字段情况可阅读第 4 章节和第 5 章节。

4.ND 协议的路由器和前缀发现 - RS/RA 报文

Neighbor Discovery 协议主要通过 Router Solicitation 和 Router Advertisement 报文来完成路由器和前缀发现。

路由器发现用于实现前缀学习和无状态地址自动配置；前缀发现可用于确认自动所在的活动链路上可直达的 IP 地址范围。

主机任何情况下不发送 RA 报文，并丢弃收到的 RS 报文。但可以发送 RS 报文。

4.1. 接口资源 - ND 通用

在介绍本部分内容前，首先介绍下每个路由器为 IPv6 接口分配的系统资源：主要参考 RFC4861。

IsRouter：路由器标志位。该标志位用于表明该接口是否启用了路由功能，是否可用于从这个接口转发数据包或向该接口转发数据包。

Default: FALSE。

在这里插入图片描述
// 此处可看到接口标识为路由器。

AdvSendAdvertisements：RA 标志位。该标志位用于表明路由器是否周期发送 RA 报文并响应 RS 报文。

Default: FALSE。

**RFC4861 要求该系统 IPv6 标志位必须为 FALSE，以便节点不会意外启动充当路由器，除非系统管理明确配置为发送 RA 路由器通告消息。**目前厂家都遵循此规则。在这里插入图片描述
//ipv6 nd ra halt 用于去使能系统发布 RA 报文功能。默认抑制 RA 的发送。

MaxRtrAdvInterval：接口发送非请求型组播 RA 报文的最大时间。

Default: 600s。取值：最小 4s，最大 1800s。

在这里插入图片描述
//ipv6 nd ra max-interval 用来设置 RA（Router Advertisement）报文的最大发布时间间隔。

MinRtrAdvInterval：接口发送非请求型组播 RA 报文的最小时间。

Default: 9s 内等于 MaxRtrAdvInterval，否则 0.33*MaxRtrAdvInterval。取值：最小 3s，最大 0.75*MaxRtrAdvIntervals。

在这里插入图片描述
//ipv6 nd ra min-interval 用来设置 RA（Router Advertisement）报文的最小发布时间间隔。默认最小时间间隔是 200 秒。

AdvManagedFlag：RA 报文的 M-bit。用于是否 DHCPv6。

Default: FALSE。

AdvOtherConfigFlag：RA 报文的 O-bit。用于是否支持 DHCPv6 的其他功能。

Default: FALSE。

AdvManagedFlag 和 AdvOtherConfigFlag 主要用于 DHCPv6 和 SLAAC。关于 IPv6 地址的 SLACC+DHCPv6 具体交互原理和使用案例介绍，可参考博客– DHCPv6 - 原理浅谈 + 报文示例 + 简易配置 (SLAAC+DHCPv6+PD 前缀代理)–RFC8415

AdvLinkMTU：路由器发送 MTU Option 中的 MTU 值。

Default: 0。

AdvReachableTime：路由器发送 RA 报文中 Reachable Time 字段的值。

Default: 0，表示路由器未分配。必须小于 1h。

AdvRetransTimer：路由器发送 RA 报文中重传定时器的值。

Default: 0，表示路由器未分配。

AdvCurHopLimit：路由器发送 RA 报文中 Cur Hop Limit 字段值。

Default: Assigned Numbers。0 表示路由器未分配，主机收到跳数限制为 0 的 RA 报文后，将自身的跳数限制设置为缺省值 64。

// 配置由设备初始发送的 IPv6 单播报文的跳数限制，或作为 RA 报文中的参数，帮助主机自动配置跳数限制。在这里插入图片描述
//ipv6 nd ra hop-limit 用来配置 RA 报文的跳数限制。缺省情况下，RA 报文的跳数限制是 255。

AdvDefaultLifetime：路由器接口发送 RA 报文中 Router Lifetime 字段值。

Default: 3*MaxRtrAdvInterval。也即默认值为 1800s。取值：最小 MaxRtrAdvInterval，最大 9000s。还可置为 0 时表示不可作为默认路由器。

此时表示填充于 RA 消息中 Router Lifetime 字段的值，设置 RA 报文的存活时间。在这里插入图片描述
//ipv6 nd ra router-lifetime 用来配置 RA 报文的存活时间。

AdvPrefixList：路由器接口发送 RA 报文中 Prefix Option 中的前缀列表。

Default: 路由器通过路由协议应被通告的活动链路上的所有前缀，不包括链路本地地址前缀。

每个前缀都有独立的
AdvValidLifetime：Prefix Option 中的 Valid Lifetime。0xffffffff 表示无穷大。Default: 2592000。
AdvOnLinkFlag：Prefix Option 中的活动链路标志位 L-bit。Default: TRUE。

无状态地址配置还定义了如下信息：
AdvPreferredLifetime：Prefix Option 中的 Preferred Lifetime。0xffffffff 表示无穷大。Default: 604800s，不能大于 AdvValidLifetime。
AdvAutonomousFlag：Prefix Option 中的 Autonomous Flag。Default: TRUE。在这里插入图片描述
此时可在 RA 报文中看到 Prefix Option：

在这里插入图片描述

需要说明的是以上某些参数，在系统初始化时为了快速响应具有另外的资源值。

同样的，每个主机为 IPv6 接口分配的系统资源主要有：

CurHopLimit：发送 IP 包时的默认下一跳限制。

Default: 生效时的数值。

BaseReachableTime：计算随机 ReachableTime 的值。

Default: REACHABLE_TIME（节点常数，30,000ms）。

ReachableTime：邻居进行可达性确认的值。

无默认值，建议取 MIN_RANDOM_FACTOR（节点常数，0.5）到 MAX_RANDOM_FACTOR（节点常数，1.5）倍 BaseReachableTime 的值。

RetransTimer：邻居进行地址解析或在 Probe 状态时发送 NS 报文的间隔。

Default: RETRANS_TIMER (节点常数，1,000ms)。

在这里插入图片描述
//ipv6 nd ns retrans-timer 命令用来设置系统发送 NS 报文的时间间隔。

该命令可用于：控制本路由设备进行邻居可达性探测的时间间隔，控制本路由设备进行重复地址检测的时间间隔，作为 RA 报文的参数，知会主机。主机将该值设置为自身发送邻居请求报文的时间间隔。

4.2. 路由器 RS/RA 处理原则

点击此处查看 ND 报文字段介绍

路由器发送 RS/RA：

1@：路由器以第 4.1. 章节介绍内容发送相应的 RA 报文。

在 options 中需要注意的是 Source Link-Layer Address option 在负载均衡的场景下又可能不携带。
如果接口的 AdvLinkMTU 为 0，则也不携带 MTU option。
Prefix option 则依据接口 AdvPrefixList 内容进行携带。

2@：非请求型 RA 的发送并不严格按照周期进行发送。该随机数取值 MinRtrAdvInterval 到 MaxRtrAdvInterval 之间。

需要说明的是该参数，为 RFC 所要求。HW 依照此要求执行，但其他厂家（例如，Cisco）有可能有独特规则。

3@：对于 RS 的响应 RA，可以选择单播也可以选择组播回应。

通常情况下的 RS/RA 报文交互过程有如下原则：

1@：任何情况下，路由器将在收到 RS 报文后的一个随机数时间延迟后回应 RA 报文。

随机数取值 0-MAX_RA_DELAY_TIME，该值为路由器常数 = 0.5s。也即系统随机启动一个 0-0.5s 的定时器，结束后对 RS 报文回应一个 RA 报文。
2@：发往所有节点组播地址 ff02::1 的 RA 报文速率，不得超过每MIN_DELAY_BETWEEN_RAS（该值为路由器常数，3s）时间间隔 1 个。
3@：（非请求型 RA 报文会周期发送，）如果系统计算的对 RS 回应 RA 的延时时间小于 RA 周期发送的剩余值，则以 RA 周期发送的剩余值为限发送 RA。
也即当周期性 / 非请求型 RA 和请求型 RA 都临近发送时，以定时器小的 RA 进行发送。

4@：涉及第 2 点的速率限制时：如果在上一个 3s 内发送了 RA 报文，则在发送非请求型 RA 时相应的时间上进行增加。这样可满足第 2 点的速率限制。

允许路由器发送请求回应型 RA，不受配置的 MinRtrAdvInterval (非请求回应型 RA 最小发送间隔) 限制以便频繁的相应 RS 报文。注意，但仍需要有第一条的随机延时时间。注意以上描述 RA 的限制，是请求回应型 RA 还是非请求型。

5@：源地址为未指定地址的 RS 不得更新路由器的 Neighbor Cache；非未指定地址的 RS 在适当情况下更新 Neighbor Cache，并将邻居状态置为 STALE。

1@@：如果收到 RS 的邻居已经创建了相应的 Neighbor Cache 条目而且 RS 中 Source Link-Layer Address option 字段与邻居 Neighbor Cache 条目中不同，此时更新相应的条目，并将其 Neighbor Cache 条目置为 STALE。
2@@：如果收到 RS 的邻居没有发送者的 Neighbor Cache 条目，路由器将创建一个，安装链接层地址，并将其可达性状态设置为 STALE。
3@@：如果收到 RS 的邻居没有发送者的 Neighbor Cache 条目而且没有 Source Link-Layer Address option 字段，邻居既可以单播又可组播回应 RA 消息。
4@@：无论 RS 是否有 Source Link-Layer Address option 字段，都将该 Neighbor Cache 的 IsRouter 标识置为 FALSE。

路由器 / 链路标识–link-local address：

link-local address 通常很少改变。节点在收到 ND 消息后使用 link-local address 地址作为发送者的标识。如果节点收到来自同一台路由器发送的具有两个不同 link-local address 的 RA 报文，将认为它们可能来自不同节点。

因此，当节点的 link-local address 改变时，节点应当以旧 link-local address 发送几个生存时间为 0 的 RA 报文。同时以新 link-local address 发送几个 RA 报文。

4.3. 主机 RS/RA 行为

主机行为：主机任何情况下不发送 RA 报文，并丢弃收到的 RS 报文。但可以发送 RS 报文。

尽管如此，主机还是需启动相应的内部程序对 RA 提供的参数做出相应调整。

在通过 RA 有效性检查后：

RA 源地址

1@：如果该 RA 源地址在主机的 Default Router List 中不存在且通告的 Router Lifetime 为非 0，则将在列表中创建一个新条目，并初始化其无效计时器值为 Router Lifetime 值。

2@：如果该 RA 源地址在主机的 Default Router List 中存在，则重置其无效计时器值为 Router Lifetime 值。

3@：如果该 RA 源地址在主机的 Default Router List 中存在且通告的 Router Lifetime 为 0，则立刻老化该条目。

RA 通用字段

4@：如果 RA 的 Cur Hop Limit value 非 0，主机将 CurHopLimit 填充该值。

5@：如果 RA 的 Reachable Time 非 0，主机将 BaseReachableTime 填充该值。如果收到最近的 2 次 RA 报文 Reachable Time 不同，则使用均一化算法进行调整。

Source Link-Layer Address Option

6@：如果 RA 包含 Source Link-Layer Address Option，将该邻居的 IsRouter 设置为 True。如果不包含该 Option 但有该 Neighbor Cache，也将该邻居的 IsRouter 设置为 True。

MTU Option

7@：如果 RA 的 MTU Option 非 0，主机将 LinkMTU 填充该值。前提该值必须大于规定的最小 MTU。

Prefix Option

8@：如果主机 Prefix List 中不存在前缀且 RA 的 Prefix Option 中 Valid Lifetime 为非 0，则为前缀创建一个新条目，并将其 invalidation timer 初始化为该值。

9@：如果主机 Prefix List 中存在前缀，将其 invalidation timer 初始化为 Valid Lifetime。

10@：如果主机 Prefix List 中存在前缀且 RA 的 Prefix Option 中 Valid Lifetime 为 0，则立刻老化相应条目。

有一些需要说明的是：
RA 报文中的未定义值并非表示让主机对相应的参数进行更改，而是保留上一个 RA 报文中对该参数的定义。具体的情况需要相应进行分析。
主机的 Default Router List 不一定全部存储所有路由器的地址，但至少需保存 2 个以便快速切换。

RS 报文的发送：

1@：接口初始化。包括系统初始化，或路由器切换为主机的情况。

2@：主机第一次连接到链路上。

3@：主机在分离一段时间后重新连接到链路上。

例如主机在第一次启动时为了快速接收 RA 报文，将在 0 至 MAX_RTR_SOLICITIONS (主机常数 1s) 之间产生随机数定时器，随后发送 RS 消息。每个消息至少间隔 RTR_SOLICITION_INTERVAL 秒 (主机常数 4s)。如果 DAD 检查已经经历过该时延，则可直接发送 RS 消息。
在某些情况下，例如移动 IPv6 的某些场景下，可以酌情省略该 MAX_RTR_SOLICITIONS_DELAY 延迟。

此外，如果主机发送 MAX_RTR_SOLICITATIONS (主机常数，3 次) 的第 3 次后的 MAX_RTR_SOLICITIONS_DELAY (主机常数，1s) 内没有收到 RA 消息，则认为链路上不存在路由器。

4@：一旦主机发送 RS 消息，并接收到具有非 0 的 Router Lifetime 的有效 RA，则主机必须停止在该接口上发送其他请求。

5.ND 协议的地址解析和邻居不可达检测 - NS/NA 报文

与 RS/RA 报文相同，NS/NA 报文也必须经过报文校验。通过校验的报文称为有效 NS/NA 报文。

5.1. 地址解析

地址解析是节点仅给定 IP 地址就可确定邻居的链路层地址的过程。地址解析仅在被确定为活动链路 (on-link) 上且发送方不知道相应链路层地址的地址上执行。从不对多播地址上执行地址解析。

5.1.1. 常用的 NS/NA 过程

地址解析的基本过程与 IPv4 的 ARP 请求过程非常类似，主要区别在于目标地址不再是广播 MAC 而是组播 IP 和组播 MAC。

在这里插入图片描述
地址解析的基本过程如下：

1@-AR1 发送 NS：

链路层：SMAC = 接口 MAC，DMAC = 组播 MAC (组播 IP 转发而来。转化规则见 1.1 章节)

IP 层：SIP = 接口 IP，DIP = 请求节点组播 IP (由被请求节点的单播 IP 转化而来。转化规则见 1.1 章节。这个单播 IP 也会填充在 NS 报文的 Target address 字段中)

ICMPv6：Target address 为请求目标的 IP，并携带 Source Link-layer Address Option 表明携带者的源地址。

2@-AR2 回应 NA：

链路层：SMAC = 接口 MAC，DMAC = 目标接口 MAC

IP 层：SIP = 接口 IP，DIP = 目标接口 IP

ICMPv6：Target address 为 NS 请求目标的 IP (也就是自己节点 IP)，并携带 Target Link-layer Address Option 表明 NS 请求目标的地址 (也就是自己节点 MAC)。

此外还通过 FLAG 字段的 R-bit、S-bit 和 O-bit 表明自己是路由器，该 NA 报文是对 NS 的回应，并且需要刷新 ND 条目。

IPv4 的一次 ARP 交互过程也类似：广播请求，单播回应！[在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/149999bcf244be381da7d76016579b33.png =700x)// 一次 ARP 交互过程。

在这里插入图片描述
//reset ipv6 neighbor 可用于清空 nd 缓存条目，类似于 reset arp 命令 用于清空 arp。

在这里插入图片描述
//display ipv6 neighbors 查看 nd 表项。

5.1.2.NS/NA 交互的详细判定

由于 IPv6 新增了不同地址的分类，并通过 TLV 的方式对协议进行扩展。因此有必要对不同情况进行说明。

1@NS 报文的发送：

普通的 NS/NA 交互：当需要将单播包发送给邻居但不知道邻居链路层地址时，就会进行 5.1.1. 章节的地址解析。此时会为该地址创建并维护一个 Neighbor Cache 条目 (详情可查看 1.3.2 章节有关介绍)。

交互详情不在说明，这里介绍下 RFC 有关说明：
1@：发往请求节点组播地址的 NS 报文，一般必须需要携带 Source Link-layer Address Option
2@：发往单播地址的 NS 报文，可以不携带 Source Link-layer Address Option。因为对端大概率已经保存了 Neighbor Cache 条目
3@：在地址解析时，程序需要为通信的数据包创建 queue 来存储数据包，在解析完成后传输
4@：NS 报文将每 Retrans_Timer (节点常数，1000ms) 重复发送，如果在 MAX_MULTICAST_SOLICIT (节点常数，3) 次以内没有收到 NA 回应，认为地址解析失败。(注意：要是 3 次的 Retrans_Timer (节点常数，1000ms) 之后才开始判定，这之后收到仍算失败。)
在这里插入图片描述
//NS 的重传间隔设置，默认 1000ms。

2@NS 报文的接收：

这里介绍下不同情况。
1@：NS 目标地址为 tentative 实验地址，则进行 SLAAC 配置。(无状态地址自动分配)
2@：NS 源地址不是非指定地址且携带 Source Link-layer Address Option，则进行相应 Neighbor Cache 条目的创建 / 更新。
3@：通过这种方式创建的 Neighbor Cache 条目中的 IsRouter 应标记为 FALSE。(如果不是第一次创建就不得更改为 FALSE)。因为 NS 报文不携带路由器标识，并且该标识可被流量刷新或者被后续的 NA 报文刷新。
在这里插入图片描述

3@：NS 源地址是非指定地址，则不得创建和更新 Neighbor Cache 条目。

3@NA 报文的发送：

1@：对于发往请求节点组播地址的 NS 报文，NA 的回应一般必须需要携带 Target Link-layer Address Option。且对于路由器，NA 还需将 R-bit 置位。
2@：对于发往单播地址的 NS 报文，NA 的回应可不携带 Target Link-layer Address Option。与 NS 报文的发送原则类似。
3@：对于发往任播地址和代理单播的 NS 报文，NA 的回应可不携带 Target Link-layer Address Option。并且 O-bit 需不置位，否则需要置位。
4@：对于发往任播地址的 NS 报文，NA 的回应应延迟一个随机数 (0 至节点常数 MAX_ANYCAST_DELAY_TIME 1s) 发送。
5@：对于源为未指定地址的 NS 报文，NA 的回应必须将 S-bit 不置位，且将 NA 发往 all-nodes address=ff02::1。否则 S-bit 置位并单播回应 NA。

4@NA 报文的接收：

如果本地未缓存 Target Address 的 Neighbor Cache 条目应丢弃该 NA 报文。并且不创建相应的 Neighbor Cache。这里讨论正常接收 NA 的情况。

本地 Neighbor Cache 状态为 INCOMPLETE 时有两种情况，

1@：链路层有地址并且不包含 Target Link-Layer Address option 时，丢弃该 NA 报文。
2@：否则，将链路层地址记录于 Neighbor Cache 中；如果 S-bit 置位将 Neighbor Cache 状态 INCOMPLETE 切换为 REACHABLE，否则切换为 STALE
3@：根据 R-bit 情况，将 Neighbor Cache 中 IsRouter 相应处理
4@：发送地址解析时队列中的数据包。
5@：忽略 NA 报文的 O-bit

本地 Neighbor Cache 状态高于 INCOMPLETE 时，
1@：O-bit 被清除且链路层地址与 Neighbor Cache 不同时，如果条目为 REACHABLE，将其转换为 STALE 并不更新条目。否则忽略 NA 报文不更新条目
2@：O-bit 被置位或链路层地址与 Neighbor Cache 相同或无 Target Link-Layer Address option 必须更新 Neighbor Cache 条目。
此时
1@@：根据 Target Link-Layer Address option 更新链路层地址
2@@：S-bit 置位时，Neighbor Cache 条目必须更新为 REACHABLE；S-bit 未置位且链路层地址与本地不同时，条目必须更新为 STALE。否则条目状态不改变。由于邻居不可达检测的存在，会对地址进行相应的检查。因此对于 S-bit 未置位时不更新条目
3@@：缓存条目中的 IsRouter 标志必须基于接收到的公告中的 R-bit 进行设置。如果 IsRouter 标志因该更新而从 TRUE 变为 FALSE，则节点必须从默认路由器列表中删除该路由器。

由于 IPv6 新增了不同地址的分类，并通过 TLV 的方式对协议进行扩展。因此有必要对其他 NS/NA 情况进行说明。

发送非请求型 NA 报文：

这种情况适用于链路层地址已经改变并且可能希望快速通知其邻居。

动作：此时进行 MAX_NEIGHBOR_ADVERTISEMENT (节点常数，3 次) 的组播 NA 发送，每次发送间隔 RetransTimer (节点常数，1000ms)。

报文：Target Address 字段设置为自己接口的 IP；S-bit 必须不置位；R-bit 根据情况置位；O-bit 置位时提示邻居更新链路层地址，但无论置位与否邻居都会将该条目缓存状态更新为 STALE。

其他：当节点是任播节点时，链路层地址的改变可以组播非请求型 NA 报文。当节点有多个地址时，发送每个地址的非请求型 NA 报文应当适当延迟以避免拥塞。

发送任播型 NA 报文：

通常情况下任播地址与单播地址完成相同，ND 协议对任播型 NA 报文处理原则也与对单播型 NA 处理基本相同。

不同之处在于:
1@：属于请求型 NA 报文的发送应延迟一个随机数时间发送。随机数取值 0-MAX_ANYCAST_DELAY_TIME（节点常数，1s）。
2@：NA 的 O-bit 应不置位。
关于启用代理时的 NS/NA 报文交互，此处不做介绍。感兴趣者可查阅相关资料。

5.2. 邻居不可达检测

邻居不可达检测（Neighbor Unreachability Detection，NUD）用于节点之间的路径可用性。当在运行了路由协议的路由节点等情况下，可不进行邻居不可达检测。

此外，仅对单播包的发送时进行邻居不可达检测而不检查组播包。

邻居可达的判断：

1@：上层协议通知。通常是指和邻居有报文交互。

2@：进行了 NS/NA 报文的交互。

NS/NA 报文的交互必须是一一对应的。非请求型 NA 报文不适用可达确认。
NS/NA 的交互是单方向的确认，邻居必须相互进行一次交互方可互相确认可达。因为邻居发送非请求型 NA 后，并不能确认该报文是否传递到了邻居

节点行为：

1@：邻居不可达性检测与向邻居发送数据包并行操作。如果没有向邻居发送流量，则不会发送探测。

2@：节点继续使用缓存的链路层地址向该邻居发送数据包。

3@：当收到邻居的最后一次可达性确认后已过了 ReachableTime 毫秒 (节点常数，30000ms) 时，Neighbor Cache 条目的状态将从 REACHABLE 更改为 STALE。

4@：向 Neighbor Cache 条目状态为 STALE 发送数据包时，发送方将状态更改为 DELAY，并将计时器设置为在 DELAY_first_PROBE_time 秒 (节点常数，5s) 内过期。如果计时器到期时条目仍处于 DELAY 状态，则条目的状态变为 PROBE。如果在这期间收到可达性确认，则条目的状态将更改为 REACHABLE。

5@：PROBE 状态下，节点使用缓存的链路层地址向邻居发送单播 NA 消息。每 Retrans_Timer 毫秒 (节点常数 1,000ms) 重新发送 NS，直到接收到可达性确认。如果在 MAX_MULTICAST_SOLICIT 次 (节点常数，3 次) 的 NS 消息后没有收到 NA 报文，也即地址解析失败。此时将会删除 Neighbor Cache。

6. 其他 IPv6 基础协议

首先需要介绍点关于地址的相关概念。

RFC4429 和 RFC4862 这样介绍：

Tentative Address：分配给接口之前，正在验证链接上唯一性的地址。此时不讲该地址视为分配给接口，并丢弃发往该地址的数据包。但接收与 ND 的 DAD 相关数据包。

Preferred address：分配给接口使用的地址，并完全不受限制。Preferred_LifeTime 时间内的地址，可被 RA 报文刷新。

Optimistic address：分配给接口使用的地址，但在链路上验证其唯一性时受到限制。可用但未进行完全的 DAD 检测。

Deprecated address：分配给接口地址，但不鼓励也不禁止使用。**该地址不得创建新的交流关系，只能被动接收连接和保持原有连接。

Valid_LifeTime 减去 Preferred_LifeTime 时间的地址获得该状态 (RA 的 Prefix Option 中携带)。

这个时间可用于地址前缀切换。超过 Valid_LifeTime 无法则启用该地址，也即 invalid address。**

//Optimistic address 是一种特殊地址，RFC4429 新引入。不能携带 Soure Option 的 RS，发送 NS 源地址必须为未指定地址且 NA 回应必须将 O-bit 不置位避免影响 Neighbor Cache，Optimistic address 为源发送的 NA 也必须将 O-bit 不置位，不能进行地址解析但可以将数据转发给链路的默认路由器。

valid address：一个 preferred 或者 deprecated address。

interface identifier：链路（至少）唯一的接口的链路相关标识符。用于和前缀一起完成地址自动生成。interface identifier 介绍可参考 RFC4291-IPv6 Addressing Architecture。如果这样产生的地址也无法保证唯一，有可能导致无法实现 SLAAC。

在这里插入图片描述

// 地址状态的相应关联。

6.1.Stateless Address Autoconfiguration

无状态地址自动配置 (Stateless Address Autoconfiguration，可简称为 SLLAC) 主要用于在不使用 DHCPv6 的条件下自动进行 IPv6 地址获取。主要通过 RS/RA 报文携带 Prefix Option 实现无状态下的地址的下发。

SLAAC 的原理：

1@：主机 / 呈现主机的路由器主动发起 RS 请求。

2@：其他节点收到 RS 请求后，忽视 RA 的周期 “立即” 发送主动进行一次 RA 的发送。

3@：节点根据 RA 消息中的 Prefix Option 选项，根据算法 (Prefix+interface identifier) 自动生成相应的子网。

4@：RA 周期发送，此时可刷新地址的 Valid_LifeTime 和 Preferred_LifeTime。

5@：考虑到 denial-of-service 攻击，RFC4862 还对地址的 Prefer_Timer 和 Valid_Timer 做出建议。这里不做介绍，感兴趣者可查阅原文。

详细的处理机制可阅读第 4 章节。

SLAAC 的配置示例：

在这里插入图片描述
此时：

在这里插入图片描述
// 支持链路本地地址和全球单播地址的 SLAAC。

注意：进行链路本地地址的 SLAAC 实际上不需要进行 RS/RA 交互，直接根据本地算法生成直接 DAD 检测即可。链路本地地址具有无穷大的 preferred and valid lifetime，并且不会超时老化。

ipv6 address auto global default

//default 的参数用于生成缺省路由。

在这里插入图片描述

相应的报文：

在这里插入图片描述

1@其他关于 RA 对 SLAAC 的参数设置

2@通过 SLAAC 有时可以实现默认路由的双活网关或负载分担，这一功能相当于 vrrp 的效果。主要通过 RA 报文的 Preference-bit 字段实现相应原理，这里不再做相应介绍。

3@SLAAC 一般适用于小型网络，满足即插即用的需求。并同时 SLAAC 和 DHCPv6 可以结合使用。实现的原理在于 RA 的 Prefix Option 的 FLAG 位。

6.2.Duplicate Address Detection

重复地址检测 (Duplicate Address Detection，DAD) 用于检测节点配置的 IP 是否被其他节点占用。

关于环路地址的 DAD 不做介绍，感兴趣者可查阅 RFC 或其他资料。

DAD 检测的原则：

1@：所有单播地址 (包括链路本地地址) 都需要进行 DAD 检测。而对任播地址不进行 DAD 检测。

2@：在进行 DAD 检测的地址是 tentative address，检测完成后方可过渡到 Preferred address。此时可不受限制的转发数据包。

一般在接口启用 IPv6 地址时，自动进行一次 DAD 检测。

在这里插入图片描述
// 默认自动进行 1 次 DAD 检测。

3@：进行 DAD 检测的参数有：

DupAddrDetectTransmits–进行 DAD 检测的次数，默认为 1；

RetransTimer：每次 DAD 检测的间隔时间，1000ms；

DAD 检测的过程：发送 NS 报文

1@：

链路层：SMAC = 接口 SMAC；DMAC = 组播 MAC

IP 层：SIP = 未指定地址 (也即:: )；DIP = 自己所进行检测 IPv6 单播地址的请求节点组播地址。

ICMPv6：发送 NS 类型 ICMPv6，Target Address 填充自己所进行检测 IPv6 单播地址并且不携带 Source Link-layer Address Option

发送的 NS 报文示例：
 在这里插入图片描述
//Type135=NS 消息。

2@：如果未有相应的 NA 报文回包，则证明该链路上该地址未被使用。

3@：如果回应了相应的 NA 报文，则将该地址为重复地址。

链路层：SMAC = 接口 SMAC；DMAC = 组播 MAC

IP 层：SIP = 其他接口的该单播地址；DIP = 所有节点组播地址 ff02::1。

ICMPv6：发送 NA 类型 ICMPv6，Target Address 填充 NS 发送者所进行检测 IPv6 单播地址并且携带 Target Link-layer Address Option

发送的 NA 报文以标识重复地址示例：
 在这里插入图片描述
// 已使用该地址的设备进行 NA 回应，用于表明该地址已被使用。

在这里插入图片描述
// 收到 NA 报文的设备，将该地址状态置位 DUPLICATE 以表明指定地址已被占用。此时也就完成了地址重复检测。

这一行为在 IPv4 中的实现主要通过 ARP：当接口启用一个 IPv4 地址时，进行通告一个免费 ARP，如果未收到 ARP 的 reply 则认为该地址未在链路上被使用。

在这里插入图片描述
// 如果有其他的接口进行该 ARP 的回应，将持续进行免费 ARP 的广播直到有一方更改地址。

via:

【科普系列】ICMPv6协议基础简介：ICMPv6的报文格式|ICMPv6报文分类（差错报文（Type 0-127），消息报文（Type 128-255）；）|ICMPv6的安全性
Polelink北汇信息的博客
12-04 2051
在科普介绍文章《IPv6协议—互联网通信协议第六版》中介绍了IPv6协议，这次的科普主题是ICMPv6（Internet Control Message Protocol version 6），它作为IPv6网络中的核心协议之一，是网络通信中不可或缺的一部分。ICMPv6的设计继承了IPv4中ICMPv4协议的基本功能，然而，它不仅仅是IPv6中错误报告和诊断工具，更在IPv6网络的运行中扮演了重要角色。
IPv6 地址格式及报文详解 | IPv4 与 IPv6 协议解析与报文对比
热门推荐
u013669912的博客
06-23 1万+
……
IPv6/ICMPv6-原理介绍+报文分析+配置示例
fengxingzhe008的博客
03-01 8773
IPv6/ICMPv6-RFC介绍+报文详解 邻居缓存（Neighbor Cache，NC） 邻居发现协议（Neighbor Discover Protocol） 地址解析（Address Resolution） 邻居不可达检测（Neighbor Unreachability Detection，NUD） 无状态地址自动配置（Stateless Address Autoconfiguration，SLLAC） 重复地址检测（Duplicate Address Detection，DAD）
IPv6 扩展头 | 格式 / 类型 / 扩展选项 / 分片头 | RFC 8200
u013669912的博客
05-22 3629
……
【协议详解】IPv6/ICMPv6/DHCPv6/SLAAC基本原理（2024最新/最全）
网洞的博客
06-09 5927
IPv6是英文“Internet Protocol Version 6”（互联网协议第6版）的缩写，是互联网工程任务组（IETF）设计的用于替代IPv4的下一代IP协议。IPv6出现是为了解决IPv4地址枯竭问题。
基于IPv6的OSPFv3/ISISv6-原理介绍+报文解析+配置示例
fengxingzhe008的博客
04-03 2255
IPv6动态路由协议：OSPFv3+ISISv6
DHCP / DHCPv6 原理 / 报文解析 / 配置示例
u013669912的博客
06-08 988
……
IPv6 | 地址解析 / 地址管理 / 邻居发现协议（NDP）/ 无状态自动配置（SLAAC）
u013669912的博客
06-20 861
IPv6 诞生背景IPv4 公网地址耗尽。Internet 用户快速增长。NAT 虽然可以解决私有地址空间与公网互访的问题，但破坏了端到端通信的完整性。IPv4 对移动性的支持不够理想。IETF 在 20 世纪 90 年代提出下一代互联网协议——IPv6，目前 IPv6 已成为公认的 IPv4 未来的升级版本。IPv6 技术特点地址空间巨大。精简报文结构。实现自动配置和重新编址。支持层次化网络编址。支持端到端安全。更好地支持 QoS 和移动特性。FF01::1。
VPWS/VPLS-虚拟专用网络原理介绍+报文分析+配置示例
fengxingzhe008的博客
08-05 3479
VPLS/VPWS 原理介绍，PW原理，VPLS/VPWS的BGP方案原理，VPLS/VPWS的LDP方案原理，VPLS/VPWS的LDP方案实例
ICMPv6协议、DHCPv6协议pcap数据包下载；ICMPv6协议、DHCPv6协议报文解析
03-24
ICMPv6协议、DHCPv6协议pcap数据包下载，支持抓包软件（如：wireshark）打开并学习ICMPv6协议、DHCPv6协议报文解析。需要其他协议，请查看我发布的其他资源。
IPv6专题系列：02 IPv6报文介绍
Jacob71的博客
03-25 1万+
介绍IPv6报文格式，对照IPv4报文格式说明两个版本的区别，介绍IPv6扩展报文头。
2022-09-13 网工进阶（三十一） ipv6-概述、地址结构、ICMPv6、DHCPv6、路由协议（OSPFv3、IS-IS IPv6、BGP4+）
x629242的博客
10-31 6390
当前世界上不同地区对部署IPv6的需求强烈程度不一，且当前IPv4网络仍然占主流地位，因此短时间内IPv6和IPv4将会共存。1 逐跳选项报头：该扩展头被每一跳处理，可包含多种选项，如路由器告警选项。2 目的选项报头：目的地处理， 可包含多种选项，如Mobile IPv6的家乡地址选项。3 路由报头：指定源路由，类似IPv4源路由选项，IPv6源节点用来指定信息报到达目的地的路径上所必须经过的中间节点。IPv6基本报头的目的地址不是分组的最终目的地址，而是路由扩展头中所列的第一个地址。
IPV6学习记录
头铁的伦的博客
01-10 1237
从广义上来看IPV6协议包含的内容很多:IPV6地址的生成与分配IPV6的报头的功能内容IPV4网络兼容IPV6的方案ICMPv6的功能(融合了arp和IGMP功能)IPV6的路由方式ipv6的诞生除了由于ipv4的地址枯竭外，很大程度上也是因为ipv4多年的发展产生了很多无法根治的缺陷：1.路由表冗长 - 冗长的路由表大大增加了数据的延迟和转发速度，对于中间路由的维护复杂度也大大提高2.广播的滥用 - ipv4的地址复杂导致arp广播高发，影响整个无线网的质量。
【大模型八股文面试】：强化学习在自然语言处理下的应用篇.pdf
07-04
大模型八股文面试题
功能测量显微镜点扩散函数（PSF）在z平面内沿着x和y方向的半高全宽，并且沿着z_x和z_y方向.zip
07-04
1.版本：matlab2014/2019a/2024a 2.附赠案例数据可直接运行。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
摄影网络营销策划方案.doc
07-04
摄影网络营销策划方案.doc
UG三维图怎么转CAD二维图(有图).doc
最新发布
07-04
UG三维图怎么转CAD二维图(有图).doc
C#实现数据库连接登录界面的简单示例
07-04
资源下载链接为： https://pan.quark.cn/s/f989b9092fc5
GPRS燃气SCADA系统解决方案.doc
07-04
GPRS燃气SCADA系统解决方案.doc
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值