The OSPF Not-So-Stubby Area (NSSA) Option
RFC 3101
Document | Type |
RFC - Proposed Standard
(January 2003; No errata)
Obsoletes RFC 1587
|
|
---|---|---|---|
Author | Patrick Murphy | ||
Last updated | 2020-07-29 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3101 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Bill Fenner | ||
Send notices to | <rohit@utstar.com>, <john.moy@sycamorenet.com> |
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 | | ------ 131.119.13 ------ |BR18|------------|BR10| ------ ------ | V to BBN Planet "core" OSPF systemShow full document text