Network Working Group R. Coltun Internet Draft FORE Systems Expiration Date: April 2000 V. Fuller File name: draft-ietf-ospf-nssa-update-08.txt BBN Planet P. Murphy US Geological Survey October 1999 The OSPF NSSA Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 (US East Coast), or ftp.isi.edu (US West Coast). Coltun, Fuller, Murphy [Page i]
Internet Draft OSPF NSSA Option October 1999 Table Of Contents 1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Motivation - transit networks ............................ 2 2.2 Motivation - corporate networks .......................... 3 2.3 Proposed Solution ........................................ 4 3.0 NSSA Intra-area Implementation Details ................... 6 3.1 The N-bit ................................................ 6 3.2 Type-7 Address Ranges .................................... 7 3.3 Type-7 LSAs .............................................. 7 3.4 Originating Type-7 LSAs .................................. 9 3.5 Calculating Type-7 AS External Routes .................... 10 3.6 Incremental Updates ...................................... 13 3.7 Optionally Importing Summary LSAs ........................ 13 4.0 Intra-AS implementation Details .......................... 14 4.1 Type-7 Translator Election ............................... 14 4.2 Translating Type-7 LSAs into Type-5 LSAs ................. 15 4.3 Flushing Translated Type-7 LSAs .......................... 18 5.0 Security Considerations .................................. 19 6.0 Acknowledgments .......................................... 21 7.0 References ............................................... 21 8.0 Authors' Addresses ....................................... 22 Appendix A: Type-7 LSA Packet Format ......................... 23 Appendix B: The Options Field ................................ 24 Appendix C: Router-LSAs ...................................... 25 Appendix D: Configuration Parameters ......................... 27 Appendix E: The P-bit Policy Paradox ......................... 28 Appendix F: Differences from RFC 1587 ........................ 30 1.0 Abstract This memo documents an optional type of OSPF area which 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. Please send comments to ospf@discuss.microsoft.com. Coltun, Fuller, Murphy [Page 1]
Internet Draft OSPF NSSA Option October 1999 2.0 Overview 2.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 this: 192.31.114 | (cloud) -------------- 130.57.4 | | ------ 131.119.13 ------ |BR18|------------|BR10| ------ ------ | V to BBN Planet "core" OSPF system 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. Topologically, this cloud looks very much like an OSPF stub area. The advantages of running the cloud as an OSPF stub area are: 1. Type-5 routes (OSPF external link state advertisements (LSAs)) are not advertised beyond the router labeled "BR10". This is advantageous because the link between BR10 and BR18 may be a low-speed link or the router BR18 may have limited resources. 2. The transit network is abstracted to the "leaf" router BR18 by advertising only a default route across the link between BR10 and BR18. 3. The cloud becomes a single, manageable "leaf" with respect to the transit network. 4. The cloud can become, logically, a part of the transit network's OSPF routing system. Coltun, Fuller, Murphy [Page 2]
Internet Draft OSPF NSSA Option October 1999 5. Translated type-5 LSAs that are sent into the backbone from the cloud (which is a separate stub area) may be considered "leaf" nodes when performing the Dijkstra calculation. However, the current definition of the OSPF protocol [OSPF] imposes topological limitations which restrict simple cloud topologies from becoming OSPF stub areas. In particular, it is illegal for a stub area to import routes external to OSPF; it is not possible for routers BR18 and BR10 to both be members of the stub area and to import the routes learned from RIP or other IP routing protocols as type-5 (OSPF external LSAs) into the OSPF routing domain. In order to run OSPF out to BR18, BR18 must be a member of a non-stub area or the OSPF backbone before it can import routes other than its directly-connected network(s). Since it is not acceptable for BR18 to maintain all of BBN Planet's external (type-5) routes, BBN Planet is forced by OSPF's topological limitations to only run OSPF out to BR10 and to run RIP between BR18 and BR10. 2.2 Motivation - corporate networks In a corporate network which supports a large corporate infrastructure it is not uncommon for OSPF area 0 to have a large non-zero area infrastructure which injects large routing tables into area 0. Organizations within the corporate infrastructure may routinely multi-home their non-0 OSPF areas to strategically located backbone area 0 routers, either to provide backbone redundancy or to increase backbone connectivity or both. Because of these large routing tables, OSPF aggregation via summarization is routinely used and recommended. Stub areas are also recommended to keep the size of the non-zero routing tables small. Organizations within the corporation are administratively autonomous and compete for corporate backbone resources. They also want isolation from each other in order to protect their own network resources within the organization. Consider a typical backbone connection, as shown on the next page, where routers A1, B1 and A2, B2 are connected to area 1 and area 2 respectively, and where routers A0 and B0 are border routers which connect to both area 1 and area 2. Assume the 192.243.192/20 and 192.243.208/22 clouds are subnetted with a protocol foreign to the corporate OSPF process. These processes could be RIP, IGRP, or second and third OSPF processes separate from the corporate OSPF backbone process. As a matter of policy, the corporate network administrators want 192.243.192/20 and 192.243.208/22 aggregated to the backbone. This policy conflicts with both Area 1 and Area 2's desire to see the subnetted infrastructures learned from Area 1's internal routers, A1 and B1, and Area 2's internal routers, A2 and B2, aggregated in such Coltun, Fuller, Murphy [Page 3]
Internet Draft OSPF NSSA Option October 1999 +---A0------Area 0 cloud------B0---+ | | | | | | | | | |T1 56kbs| | 56kbs| | | |T1 | | | | | | Area 1 cloud | | | A1-----192.243.192/20-----B1 | | | +---A2 B2---+ | | | Area 2 cloud | +------192.243.208/22-----+ a way that A0 and B0 can make efficient routing decisions. The current standard OSPF stub area has no mechanism to support the redistribution of routes for 192.243.192/20 and 192.243.208/22 subnets within their respective areas. If one assumes that both the Area 1 and Area 2 clouds are extremely large with internally very large routing tables originating from a complex OSPF link state topology and subnetting scheme, neither Area 1 or Area 2 wants to be at the mercy of the other area's summary LSAs or external LSAs, which a standard OSPF area setting would force them to carry. Any solution to this dilemma must honor Area 1's path of choice through A0 with redundancy through B0 while at the same time honoring Area 2's path of choice through B0 with redundancy through A0. Furthermore, such a solution must support the aggregation of the externally learned subnetted routing subdomains. 2.3 Proposed Solution This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA), which has the capability of importing external routes in a limited fashion. The OSPF specification defines two general classes of area configuration. The first allows type-5 LSAs to be flooded throughout the area. In this configuration, type-5 LSAs may be originated by routers internal to the area or flooded into the area by area border routers. These areas, referred to herein as type-5 capable areas (or just plain areas in the OSPF specification), are distinguished by the fact that they can carry transit traffic. The backbone is always a type-5 capable area. The second type of area configuration, called stub, allows no type-5 LSAs to be propagated into/throughout the area and instead depends on default routing to external destinations. Coltun, Fuller, Murphy [Page 4]
Internet Draft OSPF NSSA Option October 1999 NSSAs are defined in much the same manner as existing stub areas. To support NSSAs, a new option bit (the "N" bit) and a new type of LSA (type-7) are defined. The "N" bit ensures that routers belonging to an NSSA agree on its configuration. Similar to the stub area's use of the "E" bit, both NSSA neighbors must agree on the setting of the "N" bit or the OSPF neighbor adjacency will not form. Type-7 LSAs provide for carrying external route information within an NSSA. Type-7 AS External LSAs have virtually the same syntax as the Type-5 AS External LSAs with the obvious exception of the link-state type (see section 3.3 for more details). There are two major semantic differences between type-5 and type-7 LSAs. o Type-7 LSAs may be originated by and advertised throughout an NSSA; as with stub areas, type-5 LSAs are not flooded into NSSAs and do not originate there, except on NSSA border routers. o Type-7 LSAs are advertised only within a single NSSA; they are not flooded into the backbone area or any other area by border routers, though the information which they contain may be propagated into the backbone area (see section 4.2). In order to allow limited exchange of external information across an NSSA border, NSSA border routers will translate selected type-7 LSAs received from the NSSA into type-5 LSAs. These type-5 LSAs will be flooded to all type-5 capable areas. NSSA border routers may be configured with address ranges so that several type-7 LSAs may be represented by a single type-5 LSA. The NSSA border routers which perform translation are configurable thus creating efficient forwarding via type-5 LSAs originating from aggregated type-7 LSAs. In addition, an NSSA border router may originate a default type-7 LSA (IP address of 0.0.0.0) into the NSSA, and must if no NSSA internal type-7 default route exists. Note this also insures compatibility with RFC 1587 which does not have a type-3 summary default. Default routes are necessary because NSSAs do not receive full routing information and must have a default route in order to route to AS- external destinations. Like stub areas, NSSAs may be connected to the backbone at more than one area border router, but may not be used as a transit area. Note that the default route originated by an NSSA border router is never translated into a type-5 LSA, however, a default route originated by an NSSA internal AS boundary router (one that is not also an area border router) may be translated into a type-5 LSA. Like stub areas, the importing of OSPF summary routes (type-3 LSAs) into NSSAs is a configuration option. However particular care should be taken to ensure that OSPF internal routes are always chosen over Coltun, Fuller, Murphy [Page 5]
Internet Draft OSPF NSSA Option October 1999 OSPF external (type-7) routes. This may happen when other IGPs, like RIP and ISIS, leak routing information between an OSPF NSSA and another OSPF area. In these cases, all OSPF summary routes should be imported into the effected NSSAs. The recommended default behavior is to import OSPF summary routes into NSSAs. When summary routes are not imported, a type-3 summary LSA for the default route should originate from NSSA border routers. The type-3 summary default route insures intra-AS connectivity to the rest of the OSPF domain, as it takes precedence over any type-7 external default route which might originate on an NSSA internal router. This type-3 summary default route prevents the OSPF domain's internal traffic, which is normally forwarded by OSPF summary routes, from exiting the AS via any NSSA type-7 external default route originated by an NSSA internal router. Type-7 external defaults generated on NSSA internal routers and the no-summary option are mutually exclusive. When summary routes are imported into the NSSA, only type-7 default routes (as opposed to type-3) originate into the NSSA from NSSA border routers. One final note, NSSA border routers never generate type-4 summary LSAs for their NSSA ASBRs as their type-7 external advertisements are never flooded beyond the NSSA's borders. In our transit topology examples the subnets of 130.57 and network 192.31.114 will still be learned by RIP on router BR18 but now both BR10 and BR18 can be in an NSSA and all of BBN Planet's external routes are hidden from BR18; BR10 becomes an NSSA border router and BR18 becomes an AS boundary router internal to the NSSA. BR18 will import the subnets of 130.57 and network 192.31.114 as type-7 LSAs into the NSSA. BR10 then translates these routes into type-5 LSAs and floods them into BBN Planet's backbone. In our corporate example, the subnets of 192.243.192/20 and 192.243.208/22 are learned via their respective routing process, redistributed throughout NSSAs 1 and 2, and then aggregated during the translation process into a single Type-5 LSA which is flooded into Area 0. Area 1 may configure A0 to perform translation with B0 standing by as a backup translator, while Area 2 configures B0 as its translator with A0 its backup. 3.0 NSSA Intra-area Implementation Details 3.1 The N-bit The N-bit ensures that all members of an NSSA agree on the area's configuration. Together, the N-bit and E-bit reflect an interface's (and consequently the interface's associated area) external LSA Coltun, Fuller, Murphy [Page 6]
Internet Draft OSPF NSSA Option October 1999 flooding capability. As explained in section 10.5 of the OSPF specification, if type-5 LSAs are not flooded into/throughout the area, the E-bit must be clear in the option field of the received Hello packets. Interfaces associated with an NSSA will not send or receive type-5 LSAs on that interface but may send and receive type-7 LSAs. Therefore, if the N-bit is set in the options field, the E-bit must be cleared. To support the NSSA option an additional check must be made in the function that handles the receiving of the Hello packet to verify that both the N-bit and the E-bit found in the Hello packet's option field match the value of the options that have been configured for the receiving interface. A mismatch in the options causes processing of the received Hello packet to stop and the packet to be dropped. 3.2 Type-7 Address Ranges NSSA border routers may be configured with type-7 address ranges. Each address range is defined as an [address,mask] pair. Many separate type-7 networks may then be represented by a single address range, just as a subnetted network is composed of many separate subnets. NSSA border routers may then summarize type-7 routes by advertising a single type-5 route for each type-7 address range. The type-5 route, resulting from a type-7 address range match will be distributed to all type-5 capable areas. Section 4.2 gives the details of generating type-5 routes from type-7 address ranges. A type-7 address range includes the following configurable items. o An [address,mask] pair. o A status indication of either Advertise or DoNotAdvertise. o An external route tag. 3.3 Type-7 LSAs: NSSA External Link State Advertisements External routes are imported into NSSAs as type-7 LSAs by NSSA AS boundary routers. An NSSA AS boundary router (ASBR) is a router which has an interface associated with the NSSA and is exchanging routing information with routers belonging to another AS. Like OSPF ASBRs, an NSSA router indicates it is an NSSA ASBR by setting the E- bit in its router-LSA. As with type-5 LSAs a separate type-7 LSA is originated for each destination network. To support NSSAs, the link-state database must therefore be expanded to contain a type-7 LSA. Type-7 LSAs are identical to type-5 LSAs except for the following Coltun, Fuller, Murphy [Page 7]
Internet Draft OSPF NSSA Option October 1999 (see section 12.4.4 "AS external links" in the OSPF specification). 1. The type field in the LSA header is 7. 2. Type-7 LSAs are only flooded within the originating NSSA. The flooding of type-7 LSAs follows the same rules as the flooding of type-1 and type-2 LSAs. 3. Type-7 LSAs are only listed within the OSPF area data structures of their respective NSSAs, making them area specific. Type-5 LSAs, which are flooded to all type-5 capable areas, have global scope and are listed in the OSPF protocol data structure. 4. At the NSSA border router, selected type-7 LSAs are translated into type 5-LSAs and flooded into the OSPF domain's transit topology. 5. Type-7 LSAs have a propagate (P) bit which, when set, tells an NSSA border router to translate the type-7 LSA into a type-5 LSA. Examples of how the P-bit is used for loop avoidance are described in section 4.2. 6. Those type-7 LSAs that are to be translated into type-5 LSAs must have their forwarding address set. Type-5 LSAs that have been translated from type-7 LSAs normally contain a forwarding address. The exception to this is if the translation to a type-5 LSA is the result of an address range match, in which case the type-5 LSA may not contain a forwarding address (see section 4.2 for details). The forwarding address contained in type-5 LSAs will result in more efficient routing to the AS external networks when there are multiple NSSA border routers. Having the forwarding address in the type-7 LSAs will ease the translation of type-7 into type-5 LSAs as the NSSA border router will not be required to compute the forwarding address. If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route, the forwarding address should be the next hop address as is currently done in type-5 LSAs. If the intervening network is not advertised into OSPF as an internal OSPF route and the type-7 LSA's P-bit is set, a generic forwarding address should be selected from one of the router's active OSPF interface addresses which belong to the NSSA. If no such addresses exist, then no type-7 LSAs with the P-bit set should originate for the NSSA from this router. When a router is forced to pick a generic forwarding address, Coltun, Fuller, Murphy [Page 8]
Internet Draft OSPF NSSA Option October 1999 precedence should be given first to the router's internal addresses (provided internal addressing is supported). If an internal address is not used and the selected forwarding address's interface transitions to a Down state (see OSPF Section 9.3), one must select a new generic forwarding address for any type-7 LSAs which reference the previously selected forwarding address and then re-originate these type-7 LSAs. If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. If the router must chose a transit network address, then NSSA routers on the other side of the transit network are viewed as neighboring the adjacent AS, and parts of the AS may incur an extra hop in reaching the adjacent AS. Type-5 and type-7 metrics and path types are directly comparable. 3.4 Originating Type-7 LSAs NSSA AS boundary routers may only originate type-7 LSAs. All NSSA border routers must have the capability of translating type-7 LSAs into type-5 LSAs as described in Section 4.2. NSSA border routers must set bit E (external bit) in their router (type-1) LSAs to their directly attached transit areas and NSSAs. An NSSA internal AS boundary router must set the P-bit in the LSA header's option field of any type-7 LSA whose path it wants advertised into the OSPF domain's full transit topology. The LSAs of these networks must have a valid non-zero forwarding address. If the P-bit is clear the LSA is not translated into a type-5 LSA by NSSA border routers. When an NSSA border router originates both a type-5 and a type-7 LSA for the same network, the P-bit must be clear in the type-7 NSSA so that the type-7 LSA isn't again translated into a type-5 LSA by another NSSA border router. If the border router only originates a type-7 LSA, it may set the P-bit, thus allowing the network to be aggregated/propagated during type-7 translation. If an NSSA originates a type-5 LSA with a forwarding address which is part of the NSSA, it should also originate a type-7 LSA into the NSSA. A type-7 default route (network 0.0.0.0) may be originated into the NSSA by any NSSA router. The type-7 default route originated by the NSSA border router must have the P-bit clear. The type-7 default route originated by an NSSA ASBR which is not an NSSA border router may have the P-bit set. A type-7 default route may be installed by NSSA border routers if and only if its P-bit is set (see Appendix E). An LSA for the default destination must be originated by all the NSSA's border routers in order to support intra-AS routing and Coltun, Fuller, Murphy [Page 9]
Internet Draft OSPF NSSA Option October 1999 inter-AS routing. This default destination is advertised in either a type-3 or type-7 LSA, as described in the Section 3.7. 3.5 Calculating Type-7 AS External Routes This calculation must be run when type-7 LSAs are processed during the AS external route calculation. This calculation may process type-5 LSAs, but is written that way only for comparison sake. It emphasizes that NSSA ASBR routing table entries are to be used only for the address calculation of type-7 LSAs originating from the same NSSA, and not for the ASBR address calculation of type-7 LSAs originating from a different NSSA or any type-5 LSA. In addition, type-5 LSAs with a forwarding address pointing into a directly attached NSSA are skipped during the AS external route calculation as their installation status is triggered by the type-7 LSAs from which they were translated. Non-default type-7 LSAs with the P-bit clear may be installed in the OSPF routing table of NSSA border routers. Since these LSAs are not propagated throughout the OSPF domain, traffic which originates external to an NSSA and which passes through one of the NSSA's border routers may be unexpectedly diverted into the NSSA by a route installed from the processing of a type-7 LSA with the P-bit clear. (See Appendix E). An NSSA border router should examine both type-5 LSAs and type-7 LSAs if either type-5 or type-7 routes need to be updated or recalculated. This is done as part of the AS external route calculation. An NSSA internal router should examine type-7 LSAs when type-7 routes need to be recalculated. What follows is only a modest modification of the OSPF Version 2 Specification Section 16.4. Original text is suffixed with [OSPF]. NSSA specific text is suffixed with [NSSA]. AS external routes are calculated by examining AS-external-LSAs, be they type-5 or type-7. Each of the AS-external-LSAs is considered in turn. Most AS-external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA [~OSPF]: (1) If the metric specified by the LSA is LSInfinity, or if the age of the LSA equals MaxAge, then examine the next LSA. [OSPF] (2) If the LSA was originated by the calculating router itself, examine the next LSA. [OSPF] Coltun, Fuller, Murphy [Page 10]
Internet Draft OSPF NSSA Option October 1999 (3) Call the destination described by the LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. Look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If no entries exist for the ASBR (i.e. the ASBR is unreachable), do nothing with this LSA and consider the next in the list. [OSPF] Else if the destination is a type-7 default route (destination ID = DefaultDestination) and one of the following is true, then do nothing with this LSA and consider the next in the list: o The calculating router is a border router and the LSA has its P-bit clear. Appendix E describes technique for border router type-7 default installation without propagation. [NSSA] o The calculating router is suppressing the import of summary (type-3) LSAs. Else, this LSA describes an AS external path to destination N. Examine the forwarding address specified in the AS-external- LSA. This indicates the IP address to which packets for the destination should be forwarded. [OSPF] If the forwarding address is set to 0.0.0.0 then packets should be sent to the ASBR itself. If the LSA is type-5, from among the multiple non-NSSA routing table entries for the ASBR (both NSSA and non-NSSA ASBR entries might exists on an NSSA border router), select the preferred entry as follows [~OSPF]: If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in OSPF Section 16.4.1. In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen. [OSPF] Note that preference is well defined for NSSA ASBRs since their routing table entries are always non-backbone intra- area. Furthermore, since type-7 LSAs only have areawide flooding scope, ASBR path preference must be restricted to the NSSA where the type-7 originated. [NSSA] Coltun, Fuller, Murphy [Page 11]
Internet Draft OSPF NSSA Option October 1999 If the forwarding address is non-zero look up the forwarding address in the routing table. The matching routing table entry must specify an intra-area or inter-area path; if no such path exists then do nothing with this LSA and consider the next in the list. [OSPF] (4) Let X be the cost specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric. [OSPF] (5) Now, look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with the next hop equal to the list of next hops to the ASBR/forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to Type-1 external and the cost is equal to X + Y. If the external metric type is 2, the path-type is set to Type-2 external, the link-state component of the route's cost is X, and the type 2 cost is Y. [OSPF] (6) Otherwise compare the AS external path described by the LSA with the existing paths in N's routing table entry. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal preference, it is added to N's routing table entry's list of paths. [OSPF] Preference is defined as follows: (a) Intra-area and inter-area paths are always preferred over AS external paths. [OSPF] (b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred. [OSPF] (c) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1. Here intra-NSSA paths are equivalent to intra-area paths with non-backbone regular OSPF areas. [NSSA] (d) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, select the preferred path based on a least cost comparison. Type Coltun, Fuller, Murphy [Page 12]
Internet Draft OSPF NSSA Option October 1999 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the forwarding addresses. [OSPF] (e) If the new paths are still indistinguishable the following priorities apply (listed from highest to lowest) for breaking the tie. a. A type-7 LSA with the P-bit set and the forwarding address non-zero. b. Any other type-5 or type-7 LSA. [NSSA] 3.6 Incremental Updates Incremental updates for type-7 LSAs should be treated the same as incremental updates for type-5 LSAs (see section 16.6 of the OSPF specification). That is, if a new instance of a type-7 LSA is received it is not necessary to recalculate the entire routing table. If there is already an OSPF internal route to the destination represented by the type-7 LSA, no recalculation is necessary. Otherwise, the procedure in the proceeding section will have to be performed but only for the external routes (type-5 and type-7) whose networks describe the same networks as the newly received LSA. 3.7 Optionally Importing Summary LSAs In order for backbone summary internal routes to be preferred over external type-7 routes, all implementations must support the optional import of summary LSAs from the backbone into an NSSA. The default behavior is to import type-3 summary LSAs. A new area configuration parameter, ImportSummaries, has been added. When set to enabled, type-3 summary routes are imported. When set to disabled, summary routes are not imported. The default setting is enabled. If type-3 summary LSAs are not imported into the NSSA, a type-3 summary LSA for the default route must be originated by NSSA border routers. This protects the NSSA from routing intra-AS traffic out the AS via a type-7 external default route originating from an internal NSSA router. Unlike the stub area case, when summary routes are imported into the NSSA, a type-3 summary default route must not be injected into the NSSA, otherwise the type-3 summary default route would be chosen over all and potentially more preferred type-7 default routes. Coltun, Fuller, Murphy [Page 13]
Internet Draft OSPF NSSA Option October 1999 4.0 Intra-AS implementation Details 4.1 Type-7 Translator Election It is not recommended that multiple NSSA border routers perform the translation unless the efficient routing of packets through area 0 to an NSSA partitioned by aggregation requires it. It is normally sufficient to have only one NSSA border router perform the translation. Excessive numbers of type-7 translators unnecessarily increase the size of the OSPF link state data base. A new area configuration parameter, NSSATranslatorRole, is defined in Appendix D. It specifies whether or not an NSSA router will unconditionally translate type-7 LSAs to type-5 LSAs when acting as an NSSA border router. When set to Always, type-7 LSAs are always translated regardless of the translator state of other NSSA border routers. When set to Candidate and acting as an NSSA border router, an NSSA router will participate in the translator election process described below. A new bit called Nt is added to the router-LSA. NSSA border routers, which are configured to unconditionally translate type-7 LSAs into type-5 LSAs, set bit Nt in their NSSA router-LSA. All other routers clear bit Nt in their NSSA router-LSAs. A new area parameter called the NSSATranslatorState is maintained in the OSPF area data structure. By default all NSSA routers initialize NSSATranslatorState to disabled. When an NSSA router attains border router status and has its NSSATranslatorRole set to Always, it sets NSSATranslatorState to enabled and begins the unconditional translation of Type-7 LSAs into Type-5 LSAs for the NSSA. When an NSSA border router loses its border router status, NSSATranslatorState is always reset to disabled and the Nt bit is cleared in a new router LSA. If an NSSA border router has its NSSATranslatorState set to disabled and, from the subset of NSSA border routers which are reachable over the NSSA and reachable as ASBRs over the AS's transit topology, no such router exists either with bit Nt set in its router-LSA or with higher router ID, then this router begins to perform the translation of type-7 LSAs into type-5 LSAs for the NSSA and it sets NSSATranslatorState to elected. The Nt bit of an elected translator is always clear. These conditions may result in more than one elected translator for the NSSA, should one of the NSSA border routers lose connectivity to area 0. All NSSA border routers must set the E-bit in their router-LSA to directly attached transit areas and NSSAs even when they are not Coltun, Fuller, Murphy [Page 14]
Internet Draft OSPF NSSA Option October 1999 translating. This allows other NSSA border routers to see their ASBR status across the AS's transit topology. Failure to do so may cause the election algorithm to elect unnecessary translators. Every NSSA border router is a potential translator. An elected translator will continue to perform translation duties until supplanted by a reachable NSSA border router whose Nt bit is set to true or whose router ID is greater. Such an event might be triggered by the manual setting of the NSSATranslatorState to enabled in one of the NSSA border routers or a topological rejoining of a partitioned NSSA. Any change in the membership of the reachable NSSA border router set, both over the NSSA and as ASBRs over the AS's transit topology, or the appropriate change in a reachable NSSA border router Nt bit setting resulting from a updated router-LSAs should force an NSSA border router to recheck its type-7 translation status. If an elected translator determines its services are no longer required, it should continue to perform its translation duties for the additional time interval defined by a new area configuration parameter, TranslatorStabilityInterval. This minimizes excessive flushing of translated type-7s and provides for a more stable translator transition. The default value for the TranslatorStabilityInterval parameter has been defined as 40 seconds (see Appendix D). Note that during the translation of type-7 LSAs into aggregated type-5 LSAs, the highest router ID is not necessarily the best choice for an advertising router, as all packets which are forwarded by a type-5 LSA routing table entry originating from aggregated type-7 LSAs during translation are sent to the translator (Note, as described below, the forwarding address is not set in type-5 LSAs which originate from aggregated type-7 LSAs). The NSSATranslatorRole parameter allows the network designer to configure the most preferred route to the NSSA's type-5 LSAs which originate from aggregation during the translation of type-7 LSAs. In cases of aggregate partitioning of the NSSA, multiple translators may be required to effect efficient routing. Indeed, all NSSA border routers could be configured to perform translation, if required. 4.2 Translating Type-7 LSAs into Type-5 LSAs This step is performed as part of the NSSA's Dijkstra calculation after type-5 and type-7 routes have been calculated. If the calculating router is currently not an NSSA border router translator, then this translation algorithm should be skipped. All installed type-7 LSA's should be examined including those type-7s originated by the router itself (a set which may differ between NSSA border routers of the same NSSA). This allows NSSA border routers to propagate and/or aggregate locally originated type-7s during the translation. Coltun, Fuller, Murphy [Page 15]
Internet Draft OSPF NSSA Option October 1999 Note that translating all installed type-7s with the same [address,mask] pair by utilizing the available host bits to generate link state IDs may result in host bit exhaustion, as is always the case when there are multiple installed paths for a type-7 host route. Implementations may simply choose to pick for translation a single installed type-7 for each routable [address,mask] pair. Unfortunately, when there are multiple ABRs, routing inefficiencies can occur which may necessitate the configuration of additional translators. The translation of multiple installed type-7s with the same [address,mask] pair is beyond the scope of this specification. If a type-7 LSA is contained in a type-7 address range, (i.e., the [address,mask] pair of the LSA's network is equal to or a more specific instance of the [address,mask] pair of the type-7 address range) and the LSA is not contained in any more specific type-7 range, then the containing range will be called the parent range and this type-7 LSA is said to be an offspring of the range. A type-7 range's descendant type-7 LSAs are offspring of type-7 ranges subsumed by the range. For each installed type-7 LSA perform the following: (1) If the type-7 LSA has the P-bit clear, or its forwarding address is set to 0.0.0.0, or it is the offspring of a parent type-7 range with DoNotAdvertise status then do nothing with this type-7 LSA and consider the next one in the list. (2) Else if the type-7 LSA is not contained in any explicitly configured type-7 address range, or it is and the type-7 parent range's [address,mask] pair is the same as the [address,mask] pair of the type-7 LSA's network plus the type-7 parent range has no installed type-7 LSA offspring whose networks are strictly subsumed by its [address,mask] pair, then a type-5 LSA should be originated if o there currently is no type-5 LSA originated from this router corresponding to the type-7 LSA, or there is and o the path type or the metric in the corresponding type-5 LSA is different from the type-7 LSA or o the forwarding address in the corresponding type-5 LSA is different from the type-7 LSA. The newly originated type-5 LSA will describe the same network and have the same network mask, metrics, forwarding address, external route tag and path type as the type-7 LSA. However, the advertising router field will be the router ID of this Coltun, Fuller, Murphy [Page 16]
Internet Draft OSPF NSSA Option October 1999 area border router. The link-state ID is equal to the LSA's network address (in the case of multiple installed type-7s with the same network address, the link-state ID can also have one or more of the range's "host" bits set). (3) Else the installed type-7 LSA must be aggregated by its containing type-7 parent range. The parent type-7 range's path type is always set to the highest path type of those installed type-7 LSAs which are its offspring. The metric for the type-7 parent range is assigned as follows: o if the path type is external type 2, the type-7 parent range's metric should be set to the largest type-7 metric + 1 of the its installed type-7 offspring LSAs, including those with equal mask. o if the path type is external type 1, the type-7 parent range's metric should be set to the largest metric of its installed type-7 offspring LSAs, including those with equal mask. A type-5 LSA is generated from the type-7 parent range provided o there currently is no type-5 LSA originated from this router corresponding to the type-7 parent range, or there is and o the path type or the metric in the corresponding type-5 LSA is different from the currently computed path type or metric of the type-7 parent range. The newly generated type-5 LSA will have link-state ID equal to the type-7 parent range's address (if necessary, the link-state ID can also have one or more of the range's "host" bits set), the network mask, external route tag will be set to the type-7 parent range's configured values. The advertising router field will be the router ID of this area border router. The forwarding address will not be set. The path type and metric are set to the type-7 parent range's path type and metric as defined above. Further processing of installed type-7 LSAs which are offspring of the type-7 parent range is suppressed. Thus at most a single type-5 LSA is made for each type-7 parent range with installed type-7 offspring LSAs which it strictly subsumes. For example, given a parent range of [10.0.0.0, 255.0.0.0] for an Coltun, Fuller, Murphy [Page 17]
Internet Draft OSPF NSSA Option October 1999 area which has the following type-7 offspring routes: 10.1.0.0 path type 1, metric 10 10.2.0.0 path type 1, metric 11 10.3.0.0 path type 2, metric 5 a type-5 LSA will be generated with a path type of 2 and a metric 6. Given a parent range of [10.0.0.0, 255.0.0.0] for an area which has the following type-7 offspring routes: 10.1.0.0 path type 1, metric 10 10.2.0.0 path type 1, metric 11 10.3.0.0 path type 1, metric 5 a type-5 LSA will be generated with a path type of 1 and a metric 11. These type-7 range metric and path type rules will avoid routing loops in the event that path types 1 and 2 are both used within the area. As with all newly originated type-5 LSAs, a type-5 LSA that is the result of a type-7 to type-5 translation (type-7 range or default case) is flooded to all attached type-5 capable areas. Like type-3 ranges, a type-7 range performs the dual function of setting propagation policy via its Advertise/DoNotAdvertise parameter and aggregation via its network address and mask pair. Unlike type-3 summary links, type-5 translation may result in more efficient routing when the forwarding address is set, as is done during step (2) of the translation procedure. Another important feature of this translation process is that it allows a parent type-7 range to apply different properties (aggregation, forwarding address, and Advertise/DoNotAdvertise status) for its offspring routes from those assigned to its descendant routes by type-7 ranges it subsumes. 4.3 Flushing Translated Type-7 LSAs If an NSSA border router has translated an installed type-7 LSA into a type-5 LSA which should no longer be translated, the type-5 LSA should be flushed, i.e. set to MaxAge and flooded (See Section 4.2 Step (2)). Similarly, if an NSSA border router has advertised a type-7 address range which no longer needs advertising, its appropriate type-5 LSA should also be flushed. (See Section 4.2 Step (3)). Coltun, Fuller, Murphy [Page 18]
Internet Draft OSPF NSSA Option October 1999 If an NSSA border router is translating type-7 LSA's into type-5 LSA's with NSSATranslatorState = elected and the NSSA border router has determined that its translator election status has been deposed by another NSSA border router, then, as soon as the TranslatorStabilityInterval has expired without the router reelecting itself as a translator, type-5 LSAs generated by translating type-7 address ranges are flushed. Conversely Type-5 LSAs generated by translating type-7 LSAs are not immediately flushed, but are allowed to remain in the OSPF routing domain as if the border router's translator state was still elected. This minimizes the impact on translators which are flapping in and out of elected translator status and minimizes the attendant flooding of translated type-5 LSAs. 5.0 Security Considerations There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial of service attacks resulting from repetitive origination of the same router advertisement or origination of a large number of distinct advertisements resulting in database overflow. Note that both of these concerns exist independently of a router's support for the NSSA option. The OSPF protocol addresses authentication concerns by authenticating OSPF protocol exchanges. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provides significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and the received digest to verify that each received OSPF packet is authentic. The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key. None of the standard OSPF Coltun, Fuller, Murphy [Page 19]
Internet Draft OSPF NSSA Option October 1999 authentication types provide confidentiality. Nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF]. [DIGI] describes the extensions to OSPF required to add digital signature authentication to Link State data and to provide a certification mechanism for router data. [DIGI] also describes the added LSA processing and key management as well as a method for migration from or co-existence with standard OSPF V2. Repetitive origination of advertisements are addressed by OSPF by mandating a limit on the frequency that new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be originated is set to once every MinLSInterval seconds, whose value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]). Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link state database. However, when the size of the link state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; this is termed "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows. Coltun, Fuller, Murphy [Page 20]
Internet Draft OSPF NSSA Option October 1999 6.0 Acknowledgments This document was produced by the OSPF Working Group, chaired by John Moy. In addition, the comments of the following individuals are also acknowledged: Phani Jajjarvarpu cisco Dino Farinacci cisco Jeff Honig Cornell University Acee Lindem IBM John Moy Sycamore Networks, Inc. Doug Williams IBM 7.0 References [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures", RFC 2154, Trusted Information Systems, June 1997. [MUEX] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade Communications Corp., April 1998. [OPAQUE] Coltun, Rob, "The OSPF Opaque LSA Option", RFC 2370, FORE Systems, July 1998. [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, Cascade, March 1995. Coltun, Fuller, Murphy [Page 21]
Internet Draft OSPF NSSA Option October 1999 8.0 Authors' Addresses This update uses much of the original text from RFC 1587 authored by Rob Coltun Fore Systems 1595 Sprint Hill Road, 5th Floor Vienna, VA 22182 Phone: (703) 245-4543 EMail: rcoltun@fore.com Vince Fuller GTE Internetworking 3801 East Bayshore Road Palo Alto, California 94303 Phone: (415) 528-7227 EMail: vaf@BBNPlanet.com New sections, edits and revisions have been added by Pat Murphy US Geological Survey 345 Middlefield Road Menlo Park, California 94560 Phone: (415) 329-4044 EMail: pmurphy@noc.doi.net Coltun, Fuller, Murphy [Page 22]
Internet Draft OSPF NSSA Option October 1999 Appendix A: Type-7 LSA Packet Format 0 32 ----------------------------------- | | OPTS | 7 | | ------------------ | Link-State Header | | | ----------------------------------- | Network Mask | ----------------------------------- ______ |E| TOS | metric | . ----------------------------------- . repeated for each TOS | Forwarding Address | . ----------------------------------- . | External Route Tag | ______ ----------------------------------- The definitions of the link-state ID, network mask, metrics and external route tag are the same as the definitions for the type-5 LSAs (see A.4.5 in the OSPF specification) except for the forwarding address. If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route, the forwarding address should be the next hop address, but if the intervening network is not advertised into OSPF as an internal OSPF route, the forwarding address should be any one of the router's active OSPF interface addresses (see Section 3.3). Coltun, Fuller, Murphy [Page 23]
Internet Draft OSPF NSSA Option October 1999 Appendix B: The Options Field The OSPF options field is present in OSPF Hello packets, Database Description packets and all link state advertisements. See appendix A.2 in [OSPF] and [OPAQUE] for a description of the options field. Six bits are assigned but only two (the E-bit and the N/P bit) are described completely in this section. -------------------------------------- | * | O | DC | EA | N/P | MC | E | * | -------------------------------------- The Type-7 LSA options field E-bit: Type-5 AS external LSAs are not flooded into/through OSPF stub areas and NSSAs. The E-bit ensures that all members of a stub area agree on that area configuration. The E- bit is meaningful only in OSPF Hello and Database Description packets. When the E-bit is clear in the Hello packet sent out a particular interface, it means that the router will neither send nor receive type-5 AS external LSAs on that interface (in other words, the interface connects to a stub area or NSSA). Two routers will not become neighbors unless they agree on the state of the E- bit. N-bit: The N-bit describes the router's NSSA capability. The N- bit is used only in Hello packets and ensures that all members of an NSSA agree on that area's configuration. When the N-bit is set in the Hello packet and sent out a particular interface, it means that the router will send and receive type-7 LSAs on that interface. Two routers will not form an adjacency unless they agree on the state of the N-bit. If the N-bit is set in the options field, the E-bit must be clear. P-bit: The P-bit is used only in the type-7 LSA header. It flags the NSSA border router to translate the type-7 LSA into a type-5 LSA. The default setting for the P-bit is clear. Coltun, Fuller, Murphy [Page 24]
Internet Draft OSPF NSSA Option October 1999 Appendix C: Router-LSAs Router-LSAs are the Type-1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA. For details concerning the construction of router-LSAs, see the OSPF Specification, Section 12.4.1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 Nt|W|V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | TOS 0 metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | In router-LSAs, the Link State ID field is set to the router's OSPF Router ID. The T-bit is set in the LSA's Option field if and only if the router is able to calculate a separate set of routes for each IP TOS. Router-LSAs are flooded throughout a single area only. Coltun, Fuller, Murphy [Page 25]
Internet Draft OSPF NSSA Option October 1999 bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint). bit E When set, the router is an AS boundary router (E is for external). ALL NSSA border routers must set bit E in the router-LSAs to directly attached transit areas and NSSAs. (See Section 4.1 for details). bit B When set, the router is an area border router (B is for border). bit W When set, the router is a wild-card multicast receiver (W is for wild). bit Nt When set, the router is an NSSA border router which is unconditionally translating type-7 LSAs into type-5 LSAs (Nt is for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always (See Appendix D and Section 4.1). The remainder of the router links specification is as defined in the OSPF Specification, Section A.4.2. Coltun, Fuller, Murphy [Page 26]
Internet Draft OSPF NSSA Option October 1999 Appendix D: Configuration Parameters Appendix C.2 in the OSPF specification lists the area configuration parameters. The area ID and the list of address ranges for type-3 summary routes remain unchanged. Section 3.2 of this document lists the configuration parameters for type-7 address ranges. The following area configuration parameters have been added: NSSATranslatorRole Specifies whether or not the router will unconditionally translate type-7 LSAs to type-5 LSAs when acting as an NSSA border router. When set to Always, type-7 LSAs are always translated regardless of the translator state of other NSSA border routers. When set to Candidate and acting as an NSSA border router, it participates in the translator election process described in Section 4.1. The default setting is Candidate. TranslatorStabilityInterval Defines the length of time an elected type-7 translator will continue to perform its translator duties once it has determined that translator status has been deposed by another NSSA border router translator as described in Section 4.1 and 4.3. The default setting is 40 seconds. ImportSummaries When set to enabled, type-3 summary LSAs are imported into the NSSA. When set to disabled, type-3 summary LSAs are not imported into the NSSA. The default setting is enabled. Implementations must provide a vehicle for setting the P-bit of external routes imported into the NSSA as type-7 LSAs. Without configuration, the default setting of the P-bit is clear (see Section 3.3 and Appendix B). For NSSAs the ExternalRoutingCapability area configuration parameter must be set to accept type-7 external routes. Additionally there must be a way of configuring an NSSA border router to advertise a default route into the NSSA with configurable metric type (1 or 2) and cost. Coltun, Fuller, Murphy [Page 27]
Internet Draft OSPF NSSA Option October 1999 Appendix E: The P-bit Policy Paradox. Type-7 LSAs with the P-bit clear may be installed in the OSPF routing table of NSSA border routers (see Section 3.5). These LSAs are not propagated throughout the OSPF domain as translated type-5 LSAs (see Section 4.2). Thus traffic which is external to an NSSA and which passes through one of the NSSA's border routers may be hijacked into the NSSA by a route installed from the processing of a type-7 LSA with the P-bit clear. This may be contrary to the expected path at the source of the traffic. It may also violate the routing policy intended by the type-7 LSA's clear P-bit. Depending on how strongly the NSSA enforces its clear P-bit policy, packet forwarding success is unpredictable. This paradox is best illustrated by the following example. Consider an OSPF domain (AS 1842) with connections for default Internet routing and to the external AS 4156. OSPF 1842 NSSA 1 and OSPF Area 2 are partially defined in the following diagram: AS 4156 | Area 2 | | A2 A0 Area 0 C0-----Internet Default | | | | | | | | | +-----------------B0---------------+ /\ / \ / \ Internet------------A1 B1------AS 4156 (P-bit clear) Default (P-bit clear) NSSA 1 Here A0, B0, and C0 are Area 0 routers, A1 and B1 are NSSA 1 routers, and A2 is an Area 2 router. B0 is a border router for both NSSA 1 and Area 2. NSSA 1 would like its routes for AS 4156 installed on B0 so that the NSSA 1 tree below A1 can take advantage of it. If access through NSSA 1 is protected by a policy filter, then neither the area 2 subtree below router A2 or the entire AS 1842 subtree behind C0 can see AS 4156 over the expected path through A0. Moreover, should NSSA 1's Internet default through A1 be installed on Coltun, Fuller, Murphy [Page 28]
Internet Draft OSPF NSSA Option October 1999 B0, then source based outgoing ISP filters block A2's Internet bound traffic in addition to limits placed by NSSA 1's policy filters. Section 3.5 handles this obvious shortcoming by not installing any type-7 default route with a clear P-bit on any NSSA border router. All implementations should support some form of OSPF NSSA type-7 route filtering at the borders. The setting of the type-7 address range status to either Advertise or DoNotAdvertise is manually configurable as discussed in Section 3.3. Defining a type-7 address range with DoNotAdvertise status will allow the routing table installation of a default type-7 LSA with the P-bit set without translation and propagation (see Section 4.2). Note that these basic tools are limited in scope and do not provide a complete solution to this paradox. Coltun, Fuller, Murphy [Page 29]
Internet Draft OSPF NSSA Option October 1999 Appendix F: Differences from RFC 1587 This section documents the differences between this memo and RFC 1587. All differences are backward-compatible. Implementations of this memo and of RFC 1587 will interoperate. F.1 Enhancements to OSPF summary LSAs. . The flooding of backbone summary LSAs (type-3 LSAs) into the NSSA is now optional. In RFC 1587 the flooding of backbone summary LSAs was mandated in order to guarantee inter-area routes are preferred over external routes. The current recommended default behavior is to flood summary LSAs. When summary routes are not imported, a type-3 summary default route (as opposed to type-7) is originated into the NSSA by its border routers. See Sections 2.2 and 3.4 for details. F.2 Changes to type-7 LSAs. The setting of the forwarding address in Type-7 LSAs has been further refined. See Section 3.3 for details. F.3 Changes to the type-7 AS external routing calculation. The type-7 external route calculation has been revised. Most notably: o The path preference defined in OSPF Section 16.4.1 has been included. o A type-7 default route with the P-bit clear will not be installed on an NSSA border router. This protects the default routing of other OSPF Areas. (See Appendix E.) See Section 3.5 for details. F.4 Changes to translating type-7 LSAs into type-5 LSAs The translator election algorithm of RFC 1587 has been updated to close a bug which results when the translator with the highest router ID loses connectivity to the AS's transit topology. The default translator election process occurs only in the absence of a translator amongst the reachable NSSA border router set. NSSA border routers which perform the translation are now Coltun, Fuller, Murphy [Page 30]
Internet Draft OSPF NSSA Option October 1999 optionally configurable, with more than one allowed. This allows the network designer to choose the most cost effective intra-AS route for NSSA type-7 aggregates propagated into the AS. Furthermore, since different NSSA border routers may install different sets of type-7 LSA routes, the cost effectiveness of non-aggregated type-7 propagation may also be maximized. All installed type-7 LSA's plus those originated by the NSSA border router are processed for translation. This allows the NSSA border router to propagate and/or aggregate locally originated type-7s utilizing the type-5 translation process. NSSA RFC 1587 required locally originated type-7 LSAs be paired with locally originated type-5 LSAs for the external path to be seen by the AS (Note that locally originated type-7s are skipped during the external route calculation). The translation process has been strengthened to close some of the weak points of RFC 1587. See Sections 4.1 and 4.2 for details. F.5 Changes to flushing translated type-7 LSAs An NSSA border router, which was elected by the augmented RFC 1587 translator selection process defined in Section 4.1 and has been deposed from translation duties by another NSSA border router, flushes from the AS type-5 LSAs that resulted from the aggregation of translated type-7 LSAs. This prevents these obsolete translations from short circuiting the preferred path through the new translator(s) during the MaxAge cycle. A deposed translator continues to perform its flushing duties on the non- aggregated translated type-7s until they age out normally. This minimizes the amount of flushing required during the translation ascension cycle. See Section 4.3 for details. F.6 P-bit additions The P-bit default has been defined as clear. RFC 1587 had no default setting. See Appendix C. A discussion on the packet forwarding impact of installing type-7 LSAs with the P-bit clear on NSSA border routers has been added as Appendix E. Coltun, Fuller, Murphy [Page 31]
