About This Network Configuration Example

OSPF version 2, introduced as RFC 2328 in 1998, has been one of the most widely deployed interior gateway protocols (IGPs) for intradomain routing. The protocol is extended in version 3 (RFC 2740) to support OSPF in IPv6 networks. Most of the functionality of OSPFv2 carries over into OSPFv3, but there are some significant changes to explore.

OSPFv3 adds support for IPv6 in the Open Shortest Path First (OSPF) routing protocol, as detailed in RFC 2740. Most configuration and operational commands function essentially the same as in OSPFv2:

• All OSPFv3 operational and configuration commands include the identifier ospf3 in place of the familiar ospf option. For example, show ospf database in OSPFv2 becomes show ospf3 database in OSPFv3.

• OSPFv3 Router IDs, Area IDs, and LSA link-state IDs remain at the OSPFv2 IPv4 size of 32 bits.

• All the optional capabilities in OSPFv2 for IPv4, such as not-so-stubby areas (NSSA), are supported in OSPFv3 for IPv6.

However, there are many significant changes to note about OSPFv3 for IPv6:

• Router link-state advertisements (LSAs) and Network LSAs no longer carry prefix information. In OSPFv3, these LSAs only carry topology information.

  Note:

  Because addressing information in the LSA header, Router LSA, and Network LSA (Type 2) has been removed, the OSPFv3 protocol is designed to be network protocol independent.

• New and modified LSAs have been created to handle the flow of IPv6 addresses and prefixes in an OSPFv3 network. As a result, some show command output appears in a different format for OSPFv3. The LSAs that have been modified are:

  • Interarea-Prefix LSA—This replaces the Network Summary or Type 3 LSA.

  • Interarea Router LSA—This replaces the Autonomous System Boundary Router (ASBR) Summary or Type 4 LSA.

  New LSAs introduced in OSPFv3 are:

  • Link LSA—This LSA has local scope and does not extend beyond the link it is associated with. The purpose of a link LSA is to provide the router’s IPv6 link-local address to neighbors, inform other routers of the associated IPv6 prefixes available on the link, and provide information to the Network LSA. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface’s link-local address as the source address.

  Note:

  A link-local address is an IPv6 address that starts with the first 10 bits set to 1111111010. This is often displayed in hexadecimal as fe80.

  Juniper Networks M Series Multiservice Edge Routers, Juniper Networks MX Series Ethernet Services Routers, and Juniper Networks T Series Core Routers automatically generate link-local addresses when IPv6 is enabled. The routing platform selects one interface MAC address (derived from the available interfaces) and appends this to the fe80 prefix with some additional bit stuffing. For more information about link-local addresses, see RFC 2373.

  • Intra-Area-Prefix LSA—This carries all IPv6 prefix information to all OSPFv3 routers within an area (this information in IPv4 is carried by the Router and Network LSAs).

• OSPFv3 now runs on a per-link basis, instead of on a per-IP-subnet basis.

• IPv6 link-local addresses are used for OSPFv3 neighbor exchanges (except over virtual links).

• The flooding scope for LSAs has been generalized into three categories for OSPFv3:

  • Link-local scope—The OSPFv3 packet is flooded to the members of a link.

  • Area scope—The OSPFv3 packet is flooded to all members of an OSPFv3 area.

  • AS scope—The OSPFv3 packet is flooded to all members of an AS.

• Authentication has been removed from the OSPFv3 protocol itself and relies on the authentication header (AH) and Encapsulating Security Payload (ESP) portions of the IP Security (IPsec) protocol for all authentication tasks in IPv6. For more information about configuring IPsec, see the Junos IPsec Feature Guide.

• Label-switched paths (LSPs) and traffic engineering are not supported in OSPFv3.

• Neighboring routers are always identified by the 32-bit router ID in OSPFv3.