1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc6987.txt b/doc/rfc/rfc6987.txt
new file mode 100644
index 0000000..6ce0718
--- /dev/null
+++ b/doc/rfc/rfc6987.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Retana
+Request for Comments: 6987                                     L. Nguyen
+Obsoletes: 3137                                      Cisco Systems, Inc.
+Category: Informational                                         A. Zinin
+ISSN: 2070-1721                                          Cinarra Systems
+                                                                R. White
+
+                                                            D. McPherson
+                                                          Verisign, Inc.
+                                                          September 2013
+
+
+                     OSPF Stub Router Advertisement
+
+Abstract
+
+   This document describes a backward-compatible technique that may be
+   used by OSPF (Open Shortest Path First) implementations to advertise
+   a router's unavailability to forward transit traffic or to lower the
+   preference level for the paths through such a router.
+
+   This document obsoletes RFC 3137.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 1]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.1.  OSPFv3-Only Solution  . . . . . . . . . . . . . . . . . .   3
+   3.  Maximum Link Metric . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
+   Appendix A.  Changes from RFC 3137  . . . . . . . . . . . . . . .   6
+
+1.  Introduction
+
+   In some situations, it may be advantageous to inform routers in a
+   network not to use a specific router as a transit point but to still
+   route to it.  Possible situations include the following:
+
+   o  The router is in a critical condition (for example, has a very
+      high CPU load or does not have enough memory to store all Link
+      State Advertisements (LSAs) or build the routing table).
+
+   o  Graceful introduction and removal of the router to/from the
+      network.
+
+   o  Other (administrative or traffic engineering) reasons.
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 2]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+   Note that the solution introduced in this document does not remove
+   the router from the topology view of the network (as could be done by
+   just flushing that router's router-LSA) but discourages other routers
+   from using it for transit routing, while still routing packets to the
+   router's own IP addresses, i.e., the router is announced as a stub.
+
+   It must be emphasized that the solution provides real benefits in
+   networks designed with at least some level of redundancy, so that
+   traffic can be routed around the stub router.  Otherwise, traffic
+   destined for the networks and reachable through such a stub router
+   may still be routed through it.
+
+2.  Solutions
+
+   The solution introduced in this document solves two challenges
+   associated with the outlined problem.  In the description below,
+   router X is the router announcing itself as a stub.  The challenges
+   are
+
+   1) Making other routers prefer routes around router X while
+      performing the Dijkstra calculation.
+
+   2) Allowing other routers to reach IP prefixes directly connected to
+      router X.
+
+   Note that it would be easy to address issue 1) alone by just flushing
+   router X's router-LSA from the domain.  However, it does not solve
+   problem 2), since other routers will not be able to use links to
+   router X in Dijkstra (no back link), and because router X will not
+   have links to its neighbors.
+
+   To address both problems, router X announces its router-LSA to the
+   neighbors with the cost of all non-stub links (links of the types
+   other than 3) being set to MaxLinkMetric (defined in Section 3).
+
+   The solution above applies to both OSPFv2 [RFC2328] and OSPFv3
+   [RFC5340].
+
+2.1.  OSPFv3-Only Solution
+
+   OSPFv3 [RFC5340] introduces additional options to provide similar
+   control of the forwarding topology; the R-bit provides an indication
+   of whether a router is active and should be used for transit traffic.
+
+   It is left to network operators to decide which technique to use in
+   their network.  See Section 4 for more details.
+
+
+
+
+
+Retana, et al.                Informational                     [Page 3]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+3.  Maximum Link Metric
+
+   Section 2 refers to the cost of all non-stub links as MaxLinkMetric,
+   which is a new fixed architectural value introduced in this document.
+
+   MaxLinkMetric
+      The metric value indicating that a router-LSA link (see Section 2)
+      should not be used for transit traffic.  It is defined to be the
+      16-bit binary value of all ones: 0xffff.
+
+4.  Deployment Considerations
+
+   When using MaxLinkMetric, some inconsistency may be seen if the
+   network is constructed of routers that perform an intra-area Dijkstra
+   calculation as specified in [RFC1247] (discarding link records in
+   router-LSAs that have a MaxLinkMetric cost value) and routers that
+   perform it as specified in [RFC1583] and higher (do not treat links
+   with MaxLinkMetric cost as unreachable).  Note that this
+   inconsistency will not lead to routing loops, because if there are
+   some alternate paths in the network, both types of routers will agree
+   on using them rather than the path through the stub router.  If the
+   path through the stub router is the only one, the routers of the
+   first type will not use the stub router for transit (which is the
+   desired behavior), while the routers of the second type will still
+   use this path.
+
+   On the other hand, clearing the R-bit will consistently result in the
+   router not being used for transit.
+
+   The use of MaxLinkMetric or the R-bit in a network depends on the
+   objectives of the operator.  One of the possible considerations for
+   selecting one or the other is in the desired behavior if the path
+   through the stub router is the only one available.  Using
+   MaxLinkMetric allows for that path to be used while the R-bit
+   doesn't.
+
+5.  Security Considerations
+
+   The technique described in this document does not introduce any new
+   security issues into the OSPF protocol.
+
+
+
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 4]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+6.  Acknowledgements
+
+   The authors of this document do not make any claims on the
+   originality of the ideas described.  Among other people, we would
+   like to acknowledge Henk Smit for being part of one of the initial
+   discussions around this topic.
+
+   We would like to thank Shishio Tsuchiya, Gunter Van de Velde,
+   Tomohiro Yamagata, Faraz Shamim, and Acee Lindem who provided
+   significant input for the latest draft version of this document.
+   Dave Cridland and Tom Yu also provided valuable comments.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, July 2008.
+
+7.2.  Informative References
+
+   [RFC1247]  Moy, J., "OSPF Version 2", RFC 1247, July 1991.
+
+   [RFC1583]  Moy, J., "OSPF Version 2", RFC 1583, March 1994.
+
+   [RFC3137]  Retana, A., Nguyen, L., White, R., Zinin, A., and D.
+              McPherson, "OSPF Stub Router Advertisement", RFC 3137,
+              June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 5]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+Appendix A.  Changes from RFC 3137
+
+   This document obsoletes [RFC3137].
+
+   In addition to editorial updates, this document defines a new
+   architectural constant (MaxLinkMetric in Section 3) to eliminate any
+   confusion about the interpretation of LSInfinity.  It also
+   incorporates and explains the use of the R-bit [RFC5340] as a
+   solution to the problem addressed in the text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 6]
+
+RFC 6987             OSPF Stub Router Advertisement       September 2013
+
+
+Authors' Addresses
+
+   Alvaro Retana
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC  27709
+   USA
+
+   EMail: aretana@cisco.com
+
+
+   Liem Nguyen
+   Cisco Systems, Inc.
+   3750 Cisco Way
+   San Jose, CA  95134
+   USA
+
+   EMail: lhnguyen@cisco.com
+
+   Alex Zinin
+   Cinarra Systems
+   Menlo Park, CA
+   USA
+
+   EMail: alex.zinin@gmail.com
+
+
+   Russ White
+   1500 N. Greenville Avenue
+   Suite 1100
+   Richardson, TX  75081
+   USA
+
+   EMail: Russ.White@vce.com
+
+
+   Danny McPherson
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA  20190
+   USA
+
+   EMail: dmcpherson@verisign.com
+
+
+
+
+
+
+
+
+Retana, et al.                Informational                     [Page 7]
+