OSPFv3：支持IPv6的路由协议 - CSDN文库

需积分: 10 104 浏览量更新于2024-07-09 收藏 103KB PDF 举报

"OSPF（Open Shortest Path First）是一种由IETF开发的基于链路状态的内部网关协议，用于在自治系统内部实现路由信息的交换。OSPF V2适用于IPv4，而OSPF V3则专为IPv6设计，以适应其扩展的地址空间和协议特性。此文档（RFC2740）定义了OSPF V3的标准，并对支持IPv6的OSPF进行了详细说明。" OSPF V3的设计与IPv4版的OSPF主要在以下几个方面存在差异： 1. **地址处理**：由于IPv6的地址长度从IPv4的32位增加到128位，OSPF V3不再包含具体的地址信息在协议包中。相反，它使用接口ID来识别网络，这允许OSPF V3支持任意数量的IPv6前缀在同一链路上。 2. **多播地址使用**：OSPF V3不再依赖于IP广播地址进行通信，而是利用IPv6的组播地址进行数据包的发送，从而减少网络流量并提高效率。 3. **路由选择**：尽管基本的最短路径优先（SPF）算法保持不变，但OSPF V3需要考虑IPv6的路由前缀而不是单个主机地址。这意味着路由表项现在是基于前缀的，而非单个地址。 4. **无类型域间路由（Typeless Inter-Domain Routing, LSA类型）**：在OSPF V3中，LSA（Link State Advertisement）不再携带IPv4的网络掩码，而是直接携带IPv6的前缀信息，以适应IPv6的地址结构。 5. **协议独立性**：OSPF V3设计时考虑到了协议的独立性，使其不再直接依赖IPv4的某些特性，如子网掩码或网络类别的概念，以确保与未来可能的IP版本兼容。 6. **安全增强**：OSPF V3引入了更强大的安全机制，包括使用认证头（AH）和封装安全负载（ESP）来保护路由信息的完整性和机密性。 7. **扩展性**：OSPF V3支持更大的路由表，以及更大的网络规模，这是由于IPv6地址空间的扩展所驱动的。 8. **配置简化**：由于IPv6的地址自动配置能力，OSPF V3的配置过程相对简化，减少了手动配置的需求。 OSPF V3是在IPv6环境中实现高效、可靠路由的关键组件，其设计考虑了IPv6的特性和需求，同时保留了OSPF的基本优势，如快速收敛和精确的路由计算。理解这些变化对于网络管理员和工程师来说至关重要，因为它们直接影响到网络的规划、部署和维护。

RFC 2740 OSPF for IPv6 December 1999

3.1.1. The Area Data structure

The IPv6 area data structure contains all elements defined for IPv4

areas in Section 6 of [Ref1]. In addition, all LSAs of known type

which have area flooding scope are contained in the IPv6 area data

structure. This always includes the following LSA types: router-LSAs,

network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs and

intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1

(flood even when unrecognized) and area scope also appear in the area

data structure. IPv6 routers implementing MOSPF add group-

membership-LSAs to the area data structure. Type-7-LSAs belong to an

NSSA area’s data structure.

3.1.2. The Interface Data structure

In OSPF for IPv6, an interface connects a router to a link. The IPv6

interface structure modifies the IPv4 interface structure (as defined

in Section 9 of [Ref1]) as follows:

Interface ID

Every interface is assigned an Interface ID, which uniquely

identifies the interface with the router. For example, some

implementations may be able to use the MIB-II IfIndex ([Ref3]) as

Interface ID. The Interface ID appears in Hello packets sent out

the interface, the link-local-LSA originated by router for the

attached link, and the router-LSA originated by the router-LSA for

the associated area. It will also serve as the Link State ID for

the network-LSA that the router will originate for the link if the

router is elected Designated Router.

Instance ID

Every interface is assigned an Instance ID. This should default to

0, and is only necessary to assign differently on those links that

will contain multiple separate communities of OSPF Routers. For

example, suppose that there are two communities of routers on a

given ethernet segment that you wish to keep separate.

The first community is given an Instance ID of 0, by assigning 0

as the Instance ID of all its routers’ interfaces to the ethernet.

An Instance ID of 1 is assigned to the other routers’ interfaces

to the ethernet. The OSPF transmit and receive processing (see

Section 3.2) will then keep the two communities separate.

List of LSAs with link-local scope

All LSAs with link-local scope and which were originated/flooded

on the link belong to the interface structure which connects to

the link. This includes the collection of the link’s link-LSAs.

Coltun, et al. Standards Track [Page 13]

RFC 2740 OSPF for IPv6 December 1999

List of LSAs with unknown LS type

All LSAs with unknown LS type and U-bit set to 0 (if unrecognized,

treat the LSA as if it had link-local flooding scope) are kept in

the data structure for the interface that received the LSA.

IP interface address

For IPv6, the IPv6 address appearing in the source of OSPF packets

sent out the interface is almost always a link-local address. The

one exception is for virtual links, which must use one of the

router’s own site-local or global IPv6 addresses as IP interface

address.

List of link prefixes

A list of IPv6 prefixes can be configured for the attached link.

These will be advertised by the router in link-LSAs, so that they

can be advertised by the link’s Designated Router in intra-area-

prefix-LSAs.

In OSPF for IPv6, each router interface has a single metric,

representing the cost of sending packets out the interface. In

addition, OSPF for IPv6 relies on the IP Authentication Header (see

[Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to

ensure integrity and authentication/confidentiality of routing

exchanges. For that reason, AuType and Authentication key are not

associated with IPv6 OSPF interfaces.

Interface states, events, and the interface state machine remain

unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3

of [Ref1] respectively. The Designated Router and Backup Designated

Router election algorithm also remains unchanged from the IPv4

election in Section 9.4 of [Ref1].

3.1.3. The Neighbor Data Structure

The neighbor structure performs the same function in both IPv6 and

IPv4. Namely, it collects all information required to form an

adjacency between two routers, if an adjacency becomes necessary.

Each neighbor structure is bound to a single OSPF interface. The

differences between the IPv6 neighbor structure and the neighbor

structure defined for IPv4 in Section 10 of [Ref1] are:

Neighbor’s Interface ID

The Interface ID that the neighbor advertises in its Hello Packets

must be recorded in the neighbor structure. The router will

include the neighbor’s Interface ID in the router’s router-LSA

when either a) advertising a point-to-point link to the neighbor

or b) advertising a link to a network where the neighbor has

become Designated Router.

Coltun, et al. Standards Track [Page 14]

RFC 2740 OSPF for IPv6 December 1999

Router ID

The identity of the router itself (who is originating the packet).

Area ID

The OSPF area that the packet is being sent into.

Instance ID

The OSPF Instance ID associated with the interface that the packet

is being sent out of.

Checksum

The standard IPv6 16-bit one’s complement checksum, covering the

entire OSPF packet and prepended IPv6 pseudo-header (see Section

A.3.1).

Selection of OSPF routing protocol packets’ IPv6 source and

destination addresses is performed identically to the IPv4 logic in

Section 8.1 of [Ref1]. The IPv6 destination address is chosen from

among the addresses AllSPFRouters, AllDRouters and the Neighbor IP

address associated with the other end of the adjacency (which in

IPv6, for all links except virtual links, is an IPv6 link-local

address).

The sending of Link State Request Packets and Link State

Acknowledgment Packets remains unchanged from the IPv4 procedures

documented in Sections 10.9 and 13.5 of [Ref1] respectively. Sending

Hello Packets is documented in Section 3.2.1.1, and the sending of

Database Description Packets in Section 3.2.1.2. The sending of Link

State Update Packets is documented in Section 3.5.2.

3.2.1.1. Sending Hello packets

IPv6 changes the way OSPF Hello packets are sent in the following

ways (compare to Section 9.5 of [Ref1]):

o Before the Hello Packet is sent out an interface, the interface’s

Interface ID must be copied into the Hello Packet.

o The Hello Packet no longer contains an IP network mask, as OSPF

for IPv6 runs per-link instead of per-subnet.

o The choice of Designated Router and Backup Designated Router are

now indicated within Hellos by their Router IDs, instead of by

their IP interface addresses. Advertising the Designated

Router (or Backup Designated Router) as 0.0.0.0 indicates that the

Designated Router (or Backup Designated Router) has not yet been

chosen.

Coltun, et al. Standards Track [Page 16]

剩余79页未读，继续阅读

ttood

粉丝: 31
资源: 15

最新资源