From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6987.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6987.txt (limited to 'doc/rfc/rfc6987.txt') 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] + -- cgit v1.2.3