Securing Your OSPF Network

Table of Contents

Teamwork: “If everyone is moving forward together, then the success takes care of itself.”—Successories

Network designers and engineers must continually strive to understand, and in many cases disseminate, new technologies. These new technologies can vary from the newest hardware, to changes in network management, to how routing protocols evolve in response to the changing face of internetworking. This chapter deals with the fundamental question; “What does the future hold for OSPF and my network?” This question can be best answered by tracking the Internet Engineering Task Force’s (IETF) working drafts. These documents are the true measurement of how the OSPF Working Group, a section of the IETF, is keeping up with the increasing demands of the internetworking community. A prime example of its work is altering the operation of OSPF to meet the new IPv6 requirements.

The following sections cover what OSPF might be if these Internet Drafts become Request for Comments (RFCs). These drafts are working documents of the IETF, its areas, and its working groups and have the following characteristics:

• Documents are always subject to change

• Documents are valid for a maximum of six months

• Documents are subject to being replaced, updated, or made obsolete at any time

These drafts are always considered works in progress, but at this point, they are the best source of information by which to understand the direction in which OSPF is evolving.

To learn the current status of any Internet Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (U.S. East Coast), or ftp.isi.edu (U.S. West Coast).

Notes:
The 1id-abstracts.txt document, which provides a status on Internet Drafts, only contains a brief summary of each draft. There are no statements within it that says how close it is to becoming an RFC or if it is being reviewed by a working group, and so forth.

The following sections cover each current Internet Draft dealing with OSPF. The basic facts regarding each draft include: date published, author(s), expiration date, and the file name in case further reading is required. Each Draft’s abstract is included, and then a brief summary of the Draft’s scope is provided. If further information on any of the previously listed items is required, then you should consult the Internet Draft.

OSPF Standardization Report

Date Published: September 1998

Author: Moy

Expiration Date: March 1998

File Name: draft-ietf-ospf-stdreport-04.txt

In understanding the “core” evolution of OSPF, every network designer should refer to this document. This memo documents how the requirements have been met for advancing OSPF to a Full Standard (that is, an RFC), as set out in RFC 1264, Internet Routing Protocol Standardization Criteria. This document is also very useful if the reader is interested in tracing the modifications to OSPF since it held Internet Draft status.

OSPF for IPv6

Date Published: November 1997

Author: Coltun, Ferguson, Moy

Expiration Date: May 1998

File Name: draft-ietf-OSPF-ospfv6-05.txt

Abstract

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6 or simply to handle the increased address size of IPv6.

Changes between OSPF for IPv4 and this document include addressing semantics that have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6’s Authentication Header and Encapsulating Security Payload.

Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field and packet size limitations present in OSPF for IPv4 have been relaxed.

In addition, option handling has been made more flexible. All of OSPF for IPv4’s optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6.

Draft Summary

This draft deals with the conversion of the existing OSPF standard to support the requirements for IPv6. The fundamental operation is essentially unchanged, but IPv6 has some specific requirements, such as increased address size, that must be taken into consideration.

This draft is divided up into two sections that cover all the new requirements. The first section describes the differences between OSPF for IPv4 and OSPF for IPv6. Some very interesting changes have taken place; these changes are detailed as follows:

• Protocol processing per-link, not per-subnet

• Removal of addressing semantics

• Addition of Flooding scope

• Explicit support for multiple instances per link

• Use of link-local addresses

• Authentication changes

• Packet format changes

• Link-state advertisements (LSA) format changes

• Handling unknown LSA types

The second section provides details on how OSPF should be implemented as a result of these changes. Some very interesting changes have taken place; these changes are detailed as follows:

• Protocol data structures

• Protocol Packet Processing

• The Routing table Structure

• LSAs

• Definition of self-originated LSAs

• Flooding

• Multiple interfaces to a single link

OSPF Address Resolution Advertisement Option

Date Published: March 1998

Author: Coltun & Heinanen