doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc1587.txt b/doc/rfc/rfc1587.txt
new file mode 100644
index 0000000..6837290
--- /dev/null
+++ b/doc/rfc/rfc1587.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                          R. Coltun
+Request for Comments: 1587                  RainbowBridge Communications
+Category: Standards Track                                      V. Fuller
+                                                     Stanford University
+                                                              March 1994
+
+
+                          The OSPF 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.
+
+Table Of Contents
+
+   1.0 Abstract .................................................  1
+   2.0 Overview .................................................  2
+   2.1 Motivation ...............................................  2
+   2.2 Proposed Solution ........................................  3
+   3.0 Implementation Details ...................................  5
+   3.1 The N-bit ................................................  5
+   3.2 Type-7 Address Ranges ....................................  5
+   3.3 Type-7 LSAs ..............................................  5
+   3.4 Originating Type-7 LSAs ..................................  7
+   3.5 Calculating Type-7 AS External Routes ....................  8
+   3.6 Incremental Updates ...................................... 10
+   4.0 Originating Type-5 LSAs .................................. 10
+   4.1 Translating Type-7 LSAs .................................. 10
+   4.2 Flushing Translated Type-7 LSAs .......................... 13
+   5.0 Acknowledgements ......................................... 13
+   6.0 References ............................................... 13
+   7.0 Security Considerations .................................. 13
+   8.0 Authors' Addresses ....................................... 14
+   Appendix A: Type-7 LSA Packet Format ......................... 15
+   Appendix B: The Options Field ................................ 16
+   Appendix C: Configuration Parameters ......................... 17
+
+1.0  Abstract
+
+   This document describes a new optional type of OSPF area, 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.
+
+
+
+Coltun & Fuller                                                 [Page 1]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+2.0  Overview
+
+2.1  Motivation
+
+   Wide-area transit networks (such as the NSFNET regionals) 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, BARRNet has one site composed of a class-B network,
+   130.57.0.0, and a class-C network, 192.31.114.0.  From BARRNet's
+   perspective, this configuration looks something like this:
+
+                    192.31.114
+                        |
+                      (cloud)
+                  -------------- 130.57.4
+                        |
+                        |
+                     ------ 131.119.13 ------
+                     |BR18|------------|BR10|
+                     ------            ------
+                                          |
+                                          V
+                                  to BARRNet "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.
+
+
+
+Coltun & Fuller                                                 [Page 2]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+             4. The cloud can become, logically, a part of the transit
+                network's OSPF routing system.
+
+             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 [1] 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 system.  In order to run
+   OSPF out to BR18, BR18 must be a member of a non-stub area or the
+   OSPF backbone to import routes other than its directly-connected
+   network(s).  Since it is not acceptable for BR18 to maintain all of
+   BARRNet's external (type-5) routes, BARRNet is forced by OSPF's
+   topological limitations to run OSPF out to BR10 and to run RIP
+   between BR18 and BR10.
+
+2.2 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 spec), 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.
+
+   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) area 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
+
+
+
+Coltun & Fuller                                                 [Page 3]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+   Type-5 AS External LSAs with the obvious exception of the link-state
+   type (see section 3.2 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, NSSA's do not
+             receive or originate type-5 LSAs.
+
+          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 can be propagated into the backbone
+             area (see section 3.6).
+
+   In order to allow limited exchange of external information across an
+   NSSA area 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 area border routers may
+   be configured with address ranges so that several type-7 LSAs may be
+   represented by a single type-5 LSA.
+
+   In addition, an NSSA area border router can originate a default
+   type-7 LSA (IP address of 0.0.0.0) into the NSSA.  Default routes are
+   necessary because NSSAs do not receive full routing information and
+   must have a default route 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 area 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.
+
+   It should also be noted that unlike stub areas, all OSPF summary
+   routes (type-3 LSAs) must be imported into NSSAs.  This is to ensure
+   that OSPF internal routes are always chosen over OSPF external
+   (type-7) routes.
+
+   In our example topology 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 BARRNets external routes are hidden
+   from BR18; BR10 becomes an NSSA area 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 BARRNet's backbone.
+
+
+
+
+
+
+Coltun & Fuller                                                 [Page 4]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+3.0  Implementation Details
+
+3.1  The N-bit
+
+   The N-bit ensures that all members of a 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's) external LSA
+   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 receiving 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 in 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 area 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 in a single
+   address range (as advertised by a type-5 LSA), just as a subnetted
+   network is composed of many separate subnets.  Area 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.1 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 External route tag.
+
+3.3  Type-7 LSAs: NSSA External Link-State Advertisements
+
+   External routes are imported into NSSAs as type-7 LSAs by the NSSA's
+   AS boundary routers.  An NSSA AS boundary routers is a router which
+
+
+
+Coltun & Fuller                                                 [Page 5]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+   has an interface associated with the NSSA and is exchanging routing
+   information with routers belonging to another AS.  As with type-5
+   LSAs a separate type-7 LSA is originated for each destination
+   network.  To support NSSA areas, 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
+   (see  section  12.3.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 NSSA.
+         The flooding of type-7 LSAs follow the same rules
+         as the flooding of type 1-4 LSAs.
+
+      3. Type-7 LSAs are kept within the NSSA's LSDB (are
+         area specific) whereas because type-5 LSAs are
+         flooded to all type-5 capable areas, type-5 LSAs
+         global scope in the router's LSDB.
+
+      4. At the area border router, selected type-7 LSAs are
+         translated into type 5-LSAs and flooded into the
+         backbone.
+
+      5. Type 7 LSAs have a  propagate (P) bit which is
+         used to flag the area 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 in the following sections.
+
+      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
+         for the most part must contain a forwarding address.
+         The execption 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 will not contain a forwarding address
+         (see section 4.1 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 area
+         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 area 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
+
+
+
+Coltun & Fuller                                                 [Page 6]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+         route, the forwarding address should be the next hop
+         address as is currently done in type-5 LSAs, but unlike
+         type-5 LSAs 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.
+
+   Type-5 and type-7 metrics and path types are directly comparable.
+
+3.4  Originating Type-7 LSAs
+
+   NSSA AS boundary routers may originate type-7 LSAs.  All NSSA area
+   border routers must also be AS boundary routers since they all must
+   have the capability of translating a type-7 LSAs into a type-5 LSAs
+   (see section 3.6 routes for the translation algorithm).  NSSA area
+   border routers must set the E-bit (external bit) as well as the B-bit
+   (border bit) in its router (type-1) LSAs (both in the backbone and in
+   the NSSA area).
+
+   When an NSSA internal AS boundary router originates a type-7 LSA that
+   it wants to be translated into a type-5 LSA by the NSSA area border
+   router (and subsequently flooded into the backbone), it must set the
+   P-bit in the LS header's option field and add a valid forwarding
+   address in the type-7 LSA.
+
+   If a router is attached to another AS and is also an NSSA area border
+   router, it may originate a both a type-5 and a type-7 LSA for the
+   same network.  The type-5 LSA will be flooded to the backbone (and
+   all attached type-5 capable areas) and the type-7 will be flooded
+   into the NSSA.  If this is the case, the P-bit must be reset in the
+   type-7 NSSA so the type-7 LSA isn't again translated into a type-5
+   LSA by another NSSA area border router.
+
+   A type-7 default route (network 0.0.0.0) may be originated into the
+   NSSA by an NSSA area border router or by an NSSA AS boundary router
+   which is internal to the NSSA.  The type-7 default route originated
+   by the NSSA area border router must have the P-bit reset so that the
+   default route originated by the NSSA area border router will not find
+   its way out of the NSSA into the rest of the AS system via another
+   NSSA area border router.  The type-7 default route originated by an
+   NSSA AS boundary router which is not an NSSA area border router may
+   have the P-bit set.  Type-7 routes which are originated by the NSSA
+   area border router will not get added to other NSSA area border
+   router's routing table.
+
+   A default route must not be injected into the NSSA as a summary
+   (type-3) LSA as in the stub area case.  The reason for this is that
+   the preferred summary default route would be chosen over all more
+
+
+
+Coltun & Fuller                                                 [Page 7]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+   specific type-7 routes.  Because summary routes are preferred to
+   external routes and to ensure that summary routes are chosen over
+   external within the NSSA, all summary routes (unlike stub areas in
+   which this is optional) must be imported into an NSSA.
+
+3.5 Calculating Type-7 AS External Routes
+
+   This section is very similar to section 16.4 (Calculating AS external
+   routes) in the OSPF specification.  An NSSA area border router should
+   examine both type-5 LSAs and type-7 LSAs if either type-5 or type-7
+   routes need to be updated.  Type-7 LSAs should be examined after
+   type-5 LSAs.  An NSSA internal router should examine type-7 LSAs when
+   type-7 routes need to be recalculated.
+
+   In relation to the steps to calculate the routing table as presented
+   in the OSPF specification (chapter 16, "Calculation of the Routing
+   Table"), type-7 LSAs should be examined after step 5 where the routes
+   to external destinations are calculated.
+
+   Type-7 routes are calculated by examining type-7 LSAs.  Each of LSAs
+   are considered in turn. Most type-7 LSAs describe routes to specific
+   IP destinations.  A type-7 LSA can also describe a default route for
+   the NSSA (destination = DefaultDestination).  For each type-7 LSA:
+
+      1. If the metric specified by the LSA is LSInfinity, the
+         age of the LSA equals MaxAge or the advertising router
+         field is equal to this router's router ID, examine the
+         next advertisement.
+
+      2. Call the destination described by the LSA N. Look up the
+         routing table entry for the AS boundary router (ASBR) that
+         originated the LSA. If no entry exists for the ASBR
+         (i.e., ASBR is unreachable), do nothing with this LSA and
+         consider the next in the list.
+
+         If the destination is the default route (destination =
+         DefaultDestination) and if the originator of the LSA and
+         the calculating router are both NSSA area border routers
+         do nothing with this LSA and consider the next in the list.
+
+         Else, this LSA describes an AS external path to destination
+         N. If the forwarding address (as specified in the forwarding
+         address field of the LSA) is 0.0.0.0, the packets routed
+         to the external destination N will be routed to the
+         originating ASBR. If the forwarding address is not 0.0.0.0,
+         look up the forwarding address in the routing table. Packets
+         routed to the external destination N will be routed within
+         the NSSA to this forwarding address. An intra-area path
+
+
+
+Coltun & Fuller                                                 [Page 8]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+         must therefore exist to the forwarding address. If no such
+         path exists, do nothing with the LSA and consider the next
+         in the list.
+
+         Call the routing table distance to the forwarding address
+         (or the distance to the originating ASBR if the forwarding
+         address is 0.0.0.0) X, and the cost specified in the type-7
+         LSA Y. X is in terms of the link-state metric, and Y is a
+         Type-1 or Type-2 external metric.
+
+      3. Now, look up the routing table entry for the destination
+         N. If no entries exist for N, install the AS external path
+         to N, with the next hop equal to the list of next hops to
+         the forwarding address/ASBR, and the 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.
+
+      4. Else, if the paths present in the table are not Type-1 or
+         Type-2 external paths, do nothing (AS external paths have
+         the lowest priority).
+
+      5. Otherwise, compare the cost of this new AS external path
+         to the ones present in the table. Note that type-5 and
+         type-7 routes are directly comparable. Type-1 external
+         paths are always shorter than Type-2 external paths.
+         Type-1 external paths are compared by looking at the sum
+         of the distance to the forwarding address/ASBR and the
+         advertised Type-1 paths (X+Y). Type-2 external paths are
+         compared by looking at the advertised Type-2 metrics,
+         and then if necessary, the distance to the forwarding
+         address/ASBR.
+
+         When a type-5 LSA and a type-7 LSA are found to have the
+         same type and an equal distance, the following priorities
+         apply (listed from highest to lowest) for breaking the tie.
+
+                 a. Any type 5 LSA.
+                 b. A type-7 LSA with the P-bit set and the forwarding
+                    address non-zero.
+                 c. Any other type-7 LSA.
+
+         If the new path is shorter, it replaces the present paths
+         in the routing table entry. If the new path is the same
+         cost, it is added to the routing table entry's list of
+         paths.
+
+
+
+Coltun & Fuller                                                 [Page 9]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+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.
+
+4.0 Originating Type-5 LSAs
+
+4.1 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 not an area border router this translation
+   algorithm should be skipped.  All reachable area border routers in
+   the NSSA should now be examined noting the one with the highest
+   router ID.  If this router has the highest router ID, it will be the
+   one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
+   the translation algorithm should not be performed.
+
+   All type-7 routes that have been added to the routing table should be
+   examined.  If the type-7 LSA (associated with the route being
+   examined) has the P-bit set and a non-zero forwarding address, the
+   following steps should be taken.
+
+      The translation procedure must first check for a configured type-7
+      address range.  Recall that an type-7 address range consists of an
+      [address,mask] pair and a status indication of either Advertise or
+      DoNotAdvertise.  At most a single type-5 LSA is made for each
+      range.  If the route being examined falls within the type-7
+      address range, (the [address,mask] pair of the route equal to or a
+      more specific instance of the [address,mask] pair of the type-7
+      address range), one of following three actions may take place.
+
+         1. When the range's status indicates Advertise and the
+            route's address and mask are equal to the address
+            and mask of the type-7 range 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,
+
+
+
+
+
+Coltun & Fuller                                                [Page 10]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+            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 area border router.
+
+         2. When the range's status indicates Advertise and the
+            route's address or mask indicates a more specific
+            route (i.e., the route's address is subsumed by the
+            range or the route has a longer mask), a type-5 LSA
+            is generated with link-state ID equal to the range's
+            address (if necessary, the link-state ID can also have
+            one or more of the range's "host" bits set; see
+            Appendix F of the OSPF specification for details),
+            the network mask, external route tag and
+            path type will be set to the configured type-7 range
+            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 should always be set to the highest
+            path type that is subsumed by the net range.
+            The metric for the type-5 LSA will be set as follows:
+
+            o if the path type is externl type 2, the type-5
+              metric should be set to the largest type-7 metric
+              subsumed by this net range + 1.
+
+            o if the path type is external type 1, the type-5
+              metric should be set to the largest metric.
+
+            For example, given a net range of [10.0.0.0, 255.0.0.0]
+            for an area that has type-7 routes of:
+
+                    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 of 6.
+
+
+
+
+
+Coltun & Fuller                                                [Page 11]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+             As another example, given a net range of
+             [10.0.0.0, 255.0.0.0] for an area that has
+             type-7 routes of:
+
+                    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 of 11.
+
+             These metric and path type rules will avoid routing
+             loops in the event that path type 1 and 2 are both
+             used within the area.
+
+         3. When the range's status indicates DoNotAdvertise,
+            the type-5 LSA is suppressed and the component networks
+            remain hidden from the rest of the AS.
+
+            By default (given that the P-bit is set and the LSA has a
+            non-zero forwarding address) if a network is not contained
+            in any explicitly configured address range, a type-7 to
+            type-5 LSA translation will occur.
+
+            A new instance of a type-5 LSA should be originated and
+            flooded to all attached type-5 capable areas if one of the
+            following is true.
+
+            1. There currently is no type-5 LSA originated from this
+               router corresponding to the type-7 LSA.
+
+            2. The path type or the metric in the corresponding
+               type-5 LSA is different from the type-7 LSA.
+
+            3. The forwarding address in the corresponding
+               type-5 LSA is different from the type-7 LSA.
+
+            The newly originated type-5 LSAs 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.
+            The advertising router field will be the router ID of this
+            area border router.
+
+            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.
+
+
+
+
+Coltun & Fuller                                                [Page 12]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+4.2 Flushing Translated Type-7 LSAs
+
+   If an NSSA area border router has translated a type-7 LSA to a type-5
+   LSA that should no longer be translated, the type-5 LSA should be
+   flushed (set to MaxAge and flooded).  The translated type-5 LSA
+   should be flushed whenever the routing table entry that caused the
+   translation changes so that either the routing table entry is
+   unreachable or the entry's associated LSA is not a type-7 with the
+   P-bit set and a non-zero forwarding address.
+
+5.0 Acknowledgements
+
+   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
+                  John Moy           Proteon, Inc.
+                  Doug Williams      IBM
+
+6.0 References
+
+   [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
+
+   [2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
+       Proteon, Inc., March 1994.
+
+7.0 Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coltun & Fuller                                                [Page 13]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+8.0 Authors' Addresses
+
+   Rob Coltun
+   RainbowBridge Communications
+
+   Phone: (301) 340-9416
+   EMail: rcoltun@rainbow-bridge.com
+
+
+   Vince Fuller
+   BARRNet
+   Stanford University
+   Pine Hall 115
+   Stanford, CA, 94305-4122
+
+   Phone: (415) 723-6860
+   EMail: vaf@Valinor.Stanford.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coltun & Fuller                                                [Page 14]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+Appendix A: Type-7 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coltun & Fuller                                                [Page 15]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+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 the OSPF specification for a description of option field.
+
+                   ------------------------------------
+                   | * | * | * | * | N/P | MC | E | T |
+                   ------------------------------------
+
+                       The Type-7 LSA options field
+
+
+             T-bit:  The T-bit describes the router's TOS capability.
+
+             E-bit:  Type-5 AS external link advertisements are not
+                     flooded into/through OSPF stub and NSSA areas.
+                     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 packets. When the
+                     E-bit is reset in the Hello packet sent out a
+                     particular interface, it means that the router
+                     will neither send nor receive type-5 AS external
+                     link state advertisements on that interface (in
+                     other words, the interface connects to a stub
+                     area). Two routers will not become neighbors
+                     unless they agree on the state of the E-bit.
+
+             MC-bit: The MC-bit describes the multicast capability of
+                     the various pieces of the OSPF routing domain
+                     [2].
+
+             N-bit:  The N-bit describes the 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 reset in the Hello packet sent out a
+                     particular interface, it means that the router
+                     will neither send nor 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 reset.
+
+             P-bit:  The P-bit is used only in the type-7 LSA header.
+                     It flags the NSSA area border router to translate
+                     the type-7 LSA into a type-5 LSA.
+
+
+
+
+Coltun & Fuller                                                [Page 16]
+
+RFC 1587                    OSPF NSSA Option                  March 1994
+
+
+Appendix C:  Configuration Parameters
+
+   Appendix C.2 in the OSPF specification lists the area parameters.
+   The area ID, list of address ranges for type-3 summary routes and
+   authentication type remain unchanged.  Section 3.2 of this document
+   lists the configuration parameters for type-7 address ranges.
+
+   For NSSAs the external capabilities of the area must be set to accept
+   type-7 external routes.  Additionally there must be a way of
+   configuring the NSSA area border router to send a default route into
+   the NSSA using a specific metric (type-1 or type-2 and the actual
+   cost).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Coltun & Fuller                                                [Page 17]
+