The OSPF Not-So-Stubby Area (NSSA) Option
RFC 3101

Network Working Group                                          P. Murphy
Request for Comments: 3101                          US Geological Survey
Obsoletes: 1587                                             January 2003
Category: Standards Track

               The OSPF Not-So-Stubby Area (NSSA) Option

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo documents an optional type of Open Shortest Path First
   (OSPF) area that is somewhat humorously referred to as a "not-so-
   stubby" area (or NSSA).  NSSAs are similar to the existing OSPF stub
   area configuration option but have the additional capability of
   importing AS external routes in a limited fashion.

   The OSPF NSSA Option was originally defined in RFC 1587.  The
   functional differences between this memo and RFC 1587 are explained
   in Appendix F.  All differences, while expanding capability, are
   backward-compatible in nature.  Implementations of this memo and of
   RFC 1587 will interoperate.

Murphy                      Standards Track                     [Page 1]
RFC 3101       The OSPF Not-So-Stubby Area (NSSA) Option    January 2003

Table Of Contents

   1.0 Overview .................................................  2
      1.1 Motivation - Transit Networks .........................  2
      1.2 Motivation - Corporate Networks .......................  4
      1.3 Proposed Solution .....................................  5
   2.0 NSSA Intra-Area Implementation Details ...................  7
      2.1 The N-bit .............................................  7
      2.2 Type-7 Address Ranges .................................  7
      2.3 Type-7 LSAs ...........................................  8
      2.4 Originating Type-7 LSAs ...............................  9
      2.5 Calculating Type-7 AS External Routes ................. 10
      2.6 Incremental Updates ................................... 14
      2.7 Optionally Importing Summary Routes ................... 14
   3.0 Intra-AS Implementation Details .......................... 15
      3.1 Type-7 Translator Election ............................ 15
      3.2 Translating Type-7 LSAs into Type-5 LSAs .............. 16
      3.3 Flushing Translated Type-7 LSAs ....................... 19
   4.0 Security Considerations .................................. 20
   5.0 Acknowledgements ......................................... 21
   6.0 Contributors ............................................. 22
   7.0 References ............................................... 22
   Appendix A: The Options Field ................................ 23
   Appendix B: Router-LSAs ...................................... 24
   Appendix C: Type-7 LSA Packet Format ......................... 26
   Appendix D: Configuration Parameters ......................... 27
   Appendix E: The P-bit Policy Paradox ......................... 28
   Appendix F: Differences from RFC 1587 ........................ 30
   Author's Addresses ........................................... 32
   Full Copyright Statement ..................................... 33

1.0  Overview

1.1  Motivation - Transit Networks

   Wide-area transit networks often have connections to moderately
   complex "leaf" sites.  A leaf site may have multiple IP network
   numbers assigned to it.  Typically, one of the leaf site's networks
   is directly connected to a router provided and administered by the
   transit network while the others are distributed throughout and
   administered by the site.  From the transit network's perspective,
   all of the network numbers associated with the site make up a single
   "stub" entity.  For example, BBN Planet has one site composed of a
   class-B network, 130.57.0.0, and a class-C network, 192.31.114.0.
   From BBN Planet's perspective, this configuration looks something
   like the diagram on the next page, where the "cloud" consists of the
   subnets of 130.57 and network 192.31.114, all of which are learned by
   RIP on router BR18.

Murphy                      Standards Track                     [Page 2]
RFC 3101       The OSPF Not-So-Stubby Area (NSSA) Option    January 2003

                  192.31.114
                      |
                    (cloud)
                -------------- 130.57.4
                      |