IPv6 OSPFv3协议详解(上)

 IPv6 OSPFv3协议详解(上)

转载链接：http://www.h3c.com/cn/d_200911/655330_97665_0.htm

姓名：罗学元   学号：21181214375     学院：广州研究院

【嵌牛导读】IPV6 OSPFv3协议

【嵌牛鼻子】IPV6 OSPFv3协议

【嵌牛提问】IPV6 OSPFv3协议具体包含哪些部分

1   概述

本文基于RFC2740介绍了OSPFv3与OSPFv2的区别和实现，对继承OSPFV2的内容可以参考RFC2328，这里不再赘述。 OSPFV3是在原有      OSPF V2基础上开发的支持IPV6的协议，它使用的仍然是链路状态算法，OSPFV2的基本机制，如洪泛（flooding）、DR选举、区域划分、SPF算法保持不变。相对于OSPFV2，OSPFV3最大的变化就是对IPV6地址的支持，以及对IPv6体系架构的兼容。另外，OSPFv3在OSPFv2的基础上，对功能做了增强。

1.1   语义

IPv6中使用地址/前缀长度描述地址，而没有子网掩码的概念。IPv6中的链路（Link）就类似于IPv4中子网或网络。因此，本文中也使用链路（Link）表达类似的意思。

2    与Version2的差别

OSPFv3保留了OPSFv2的大部分机制。为了支持IPv6地址、IPv6报文结构和体系，OSPFv3主要做了以下修改：

2.1  从per-sub 到 per-link

    IPv6使用链路（link）表示节点赖以在链路层通信的媒介或工具。Interface连接到链路上。多个IPv6地址前缀可以分配到一个单独的链路上；对连接到链路上的两个节点，即使他们的IPv6地址前缀不同，也可以直接通信。

相应的，OSPFv3也是运行在链路上，而不象IPv4中是基于网段的。链路的概念取代了OSPFv2中的网络和子网。因此，我们说OSPF接口是连接到链路上而不是子网上。

这一变化影响了Hello报文的接收以及Hello报文和Network-LSA的内容。

2.2 地址

在OSPFv3中，OSPF协议报文头和大部分LSA中去掉了地址部分，从而与网络层协议无关。具体说来有以下方面：

1）  除了LSU报文中的LSA载荷包含IPv6地址信息外，其他的协议报文中都不含有地址字段；

2）   Router-LSA和Network-LSA中去掉了网段地址，用拓扑信息取而代之；

3）   OSPFv3中的Router ID、Area ID和Link State ID保留IPv4中的格式——32bit；

4）    在所有类型的网络中，包括广播和NBMA，都使用Router ID来识别邻居；

 2.3  洪泛范围

LSA的洪泛范围归纳为3类，放在LSA的LS类型域（field）。这三类是：

1）       本地链路范围：LSA只在本地链路上传播，这类LSA是Link-LSA；

2）     区域范围：LSA只在一个OSPF区域内部传播，这类LSA包括Router-LSA、Network-LSA、Inter-Area-Prefix-LSA、Inter-Area-Router-LSA和Intra-Area-Prefix-LSA；

3）   自治系统范围：LSA在整个自治系统内传播，这类LSA只有AS-external-LSA。

2.4 多实例

OSPFv3支持在单链路上运行多实例。这使得多个供应商在共享一台甚至多台网络设备的情况下，仍然可以保持各自网络的独立运行。在OSPFv2中，是通过设置不同的OSPF验证来实现的。

在单链路上运行多实例是通过在OSPF报文头和OSPF接口数据结构中包含实例号（Instance ID）做到的。实例号只影响OSPF报文接收。

2.5 使用link-local地址

IPv6中的本地链路地址用于单链路上的邻居发现，无状态自动配置等等。对于以本地链路地址作为源地址的报文，IPv6路由器不作转发。本地链路单播地址范围是FF80/10。

OSPFv3假定每个路由器的物理接口都分配了本地链路单播地址。除了虚连接以外，所有的OSPFv3接口都使用本地链路单播地址作为报文的源地址。路由器从链路上学到其他路由器的本地链路单播地址，再使用这些地址作为转发报文的下一跳。

虚连接使用全球范围地址或本地站点地址作为OSPF报文源地址。

本地链路地址只出现在Link-LSA中，其他OSPF LSA不使用本地链路地址。Inter-area-prefix-LSA、AS-external-LSA和intra-area-prefix-LSA中决不能携带本地链路地址。

2.6 认证

OSPFv3本身没有认证（Authentication）功能。因此，OSPFv3报文头中去掉了AuType和Authentication字段。相应的，所有的OSPF区域和接口数据结构都去掉了认证相关域（field）。

OSPFv3的认证依赖于IPv6报文的认证头和IP封装安全有效载荷报头。OSPFv3通过这些IP报文头来确保路由交换的完整性和认证/保密。

OSPFv3报文利用IPv6标准的16位完整校验和防止报文数据的随机错误。该校验和覆盖了整个OSPF报文和伪IPv6头。

2.7 报文格式

OSPFv3报文直接封装在IPv6报文中。OSPFv3报文头中去除了素有的地址相关字段，做到与网络协议无关。所有的地址信息都放在各种LSA中。OSPFv3报文的具体变化有（分别见图一——图三）：

1）SPF版本变为3；

2） Hello报文和DD报文的Option字段扩展到24位；

3）PF报文头除去了Authentication和AuType字段；

4） Hello报文不含有任何地址信息，包含Interface ID。发送路由器为链路上的接口分配Interface ID，并用Interface ID唯一的标识这些接口。在Network-LSA中，使用DR的Interface ID作为Link State ID。

5）在报文Option字段增加了’R-bit’和’V6-bit’。在SPF运算处理Router-LSA时会用到这两个参数。若’R-bit’为空则路由器可以在OSPF拓扑分发时不转发transit流量；this can be used in multi-homed hosts that want to participate in the routing protocol。’V6-bit’对’R-bit’作出了更详细的规定：若’V6-bit’为空，则路由器可以在OSPF拓扑分发时不转发IPv6报文。若设置了’R-bit’但’V6-bit’为空，路由器不转发IPv6报文，但可能转发其他协议体系的报文。

6）OSPFv3支持在单个链路上运行多个OSPF协议实例（OSPF protocol instance）。在OSPFv3报文头中增加了’Instance ID’字段。

2.7.1OSPFv3报文头格式

OSPFv3的报文头如下图所示：

                                                                                                      图1  OSPF for IPv6报文头

Version：3

Type:：报文类型, 1---Hello, 2---DD, 3---LSR, 4---LSU, 5---LSAck

Packet length：包括标准OSPF报文头的OSPF报文长度，长度单位Byte。

Router ID：每个OSPFv3进程的唯一标识

Area ID：区域标识符

Checksum：包括IPv6 pseudo-header的OSPF报文校验和

Instance ID：VPN实例号。

OSPFv3中，LSR和LSAck报文的发送保持不变。Hello，DD和LSU报文的发送有所不同。

 2.7.2  Hello报文格式

                                                                                                      图2 Hello报文格式

OSPFv3 Header: 参见OSPFv3报文头格式

Interface ID: 接口标识, 在路由器上唯一标识接口

Rtr Priority: 路由器优先级

HelloInterval: 发送Hello 报文的间隔

RouterDeadInterval: 此计时器超时后, 邻居Down掉

Neighbor ID: 邻居的Router ID

Options: V6：为0时, 不参加路由计算

        E ---- 在Hello报文中, 此位为0时, 表示此区域不传播AS-External-LSA

        MC -- 是否多播

        N ---  Type-7 LSA 处理相关

        R ---  为0时, 表明产生此条LSA的路由器状态down掉了

        DC--  环回相关

                                                                                                   图3 Option选项

2.7.3DD报文格式

                                                                                                           图4 DD报文格式

Options: 与Hello报文中的Options相同

Interface MTU: 本地接口的MTU值

I: Initial，初始化位, 为1时表明是第一个DD报文

M: More，表明接下来还有DD报文

MS: 主/从位 (Master/Slave), 为1时, 表明为主(Master)

DD sequence number: DD报文的序列号

List of LSA Header: LSA头部的集合, 用于接受方检查LS数据库

2.7.4   LSR报文

  LSR (LS Request) 请求所需的LSA

                                                                                                       图5 LSR报文格式

Link State ID: LSA的标识

LS Type: 参考LSA格式部分

2.7.5    LSU报文

LSU (LS Update) 回复所请求的LSA

                                                                                               图6 LSU报文格式

# LSAs: 报文里包含的LSA数目

2.7.6   LSAck报文

确认收到的LSA

                                                                                                          图7 LSAck报文格式

2.8  LSA格式

LSA头和Router-LSA、Network-LSA中去掉了所有的地址内容。Router-LSA和Network-LSA描述了路由域的拓扑结构，而该结构与具体的网络层协议无关。增加了新的LSA用来分发IPv6地址信息和下一跳信息。一些IPv4中的LSA名称改变了，以保持所有LSA意思的一致性。LSA的具体变化有：

1) Option字段从LSA头中拿走放到了Router-LSA、Network-LSA、Inter-Area-Router-LSA和Link-LSA中。同时，Option字段扩展到24bit；

2) LSA类型字段扩展到16bit（占据了原来Option与LSA Type的位置），最高的3位表示洪泛范围和对未知类型LSA的处理；

3)LSA中的地址格式为：[前缀，前缀长度]取代过去的[地址，掩码]。缺省路由的前缀长度为0；

4) Router-LSA和Network-LSA不包含地址信息，即完全独立于具体的网络层协议；

5)完整的路由器接口信息可能分布在多个Router LSA中，接收路由器在进行SPF运算时需要综合同一路由器发出的多个Router-LSA；

6)出现一类新的LSA：Link-LSA。这类LSA只在本地链路上传播，不能被扩散到链路以外的范围。增加Link-LSA有三个目的：

7)为连接到同一链路上的其他路由器提供本设备的本地链路地址；

8) 向连接到同一链路上的其他路由器通告本链路的IPv6前缀列表；

9) 声明本链路上生成的Network-LSA的Options字段集；

在IPv4中，router-LSA携带了路由器的IPv4接口地址，该地址与IPv6中的本地链路地址相当。只在OSPF计算路由的下一条时会用到这些地址信息，因此，Router-LSA中的这些地址信息不需要传播到本地链路以外的区域。IPv6中使用Link-LSA分发这些地址更为有效。而仅仅通过接收Hello报文，路由器是无法学到本地链路地址的：在NBMA网络上，路由器和下一条路由器不一定会交互Hello报文，他们是通过DR来感知对方的存在。

1)the Option field in the Network LSA is set to the logical OR of the Options that each router on the link advertises in its Link-LSA.路由器将它的Link-LSA中的本链路路由器的Option字段值相与，得到自己的Options字段值。

2) 3类Summary-LSA更名为’Inter-Area-Prefix-LSA’；

4类Summary-LSA更名为’Inter-Area-Router-LSA’；

3）  Inter-Area-Prefix-LSA、Inter-Area-Router-LSA和AS-external-LSA中的Link State ID失去了原来的地址意义，只用来标识链路状态数据库中的一项。过去用Link State ID来标识的地址信息和Router ID被放在LSA体中。

4）唯有Network-LSA和Link-LSA的Link State ID带有附加意义：Link State ID也是本链路上发送路由器的Interface ID。因此，这两类LSA也是目前唯一对长度不作限定的LSA：Network-LSA必须包含本链路上的所有路由器；Link-LSA必须包含本链路上的所有路由器的本地链路地址。

5）添加了一类新的LSA：Intra-Area-Prefix-LSA。这类LSA携带了所有的IPv6地址前缀信息。

6）AS-external-LSA中有两个字段是可选的：forwarding address和external route tag。此外，为了包含额外的OSPF自治系统外路由属性AS-external-LSA可以引用其他的LSA；

2.9  处理未知类型LSA

OSPFv3能够处理未知类型的LSA。对于未知类型的LSA，可以只在本地链路范围发送，也可以把它当作一种已知的类型洪泛。具体的处理方式取决于link state header中的LS Type字段的定义。

在IPv6中，需要路由器在单个链路上提供对报文的多种处理。IPv4中对未知类型报文直接丢弃的做法已经不适用了。当DR比链路上其他路由器支持的Option类型少时，直接丢弃报文会产生问题。

2.10   Stub区域

在IPv4中设置Stub区域减小了区域内部路由器的链路数据库和路由表规模。这使得在大规模OSPF路由域内的路由器只占用了很少的资源。

OSPFv3保留了Stub区域的概念，类似的，Stub区域内只有router-LSA、network-LSA、Inter-Area-Prefix-LSA、Link-LSA和Intra-Area-Prefix-LSA。

与上一版本不同的是，OSPFv3允许不能识别类型的LSA被当作已知类型洪泛。无节制的加入未知类型LSA可能导致Stub区域的链路状态数据库超过路由器的处理能力。

为防止这种现象的发生，必须同时满足下列两个条件的LSA才可以在Stub区域内洪泛：

1)    LSA的洪泛范围为区域（area）或本地链路范围；

2)        LSA的’U-bit’置为0。

2.11   识别邻居

在OSPFv2中，对p2p，Virtual link上的邻居用他们的Router ID来识别；对broadcast，NBMA，p2mp上的邻居用他们的IPv4接口地址来识别。在OSPFv3中，所有链路上的邻居路由器是由他们的Router ID来识别的。这样的变化使得OSPF报文的接收、邻居发现有了相应的变化。

0.0.0.0的Router ID是保留未用的。Router ID决不能设为0.0.0.0。

3.实现细节

从IPv4到IPv6，基本的OSPF机制保持不变。详细内容请参加RFC2328 Section4。归纳起来，两者的共性主要体现在以下几个方面：

1）  都维护链路状态数据库；

2）构成数据库的基本单位LSA需要在邻居间同步；

3） 首次同步是通过交换DD报文，LSR报文和LSAck报文来完成的；此后链路状态数据库的维护是通过洪泛，发送LSU报文和LSAck报文来实现的；

4）  使用Hello报文来发现和维护邻居关系；

5） 只在broadcast和NBMA链路上选举DR和BDR；

6） 邻接关系的建立；

7） 区域内路由和用ASE标识引入的区域外部路由的思想；

8） 各种路由的计算。

特别的，OSPFv3完全继承了RFC2328中描述的OSPFv2的下列机制：

1）  2328 Section4.3描述的OSPF报文，包括Hello报文，DD报文，LSR报文，LSU报文，LSAck报文。尽管有些报文的格式有一些变动，但这些报文的用法是完全不变的；

2）  对运行OSPF的系统要求不变，只是OSPFv3要求系统必须运行在IPv6的协议栈下；

3）  邻居关系的发现和维持机制，邻接关系的建立，包括RFC2328的Section 7，7.1-7.5；

4） OSPF支持的链路类型（或者叫接口类型）不变，有：p2p，broadcast，NBMA，p2mp和虚连接；

5）   接口状态机，包括接口状态和事件列表，DR、BDR选举机制保持不变，可参见RFC2328 Section 9.1-9.4；

6）   邻居状态机，包括OSPF邻居状态和事件，可参见RFC2328 Section 10.1-10.4；

7）   链路状态数据库老化机制、LSA的域内传播和提前老化处理，可参见RFC2328 Section 14和14.1；

在保留大部分OSPFv2机制的同时，部分机制有了变化。后续将继续描述OPSFv3的具体实现方法