RFC 6987

RFC 6987: OSPF Stub Router Advertisement 🎀

okay bestie, let's talk about RFC 6987 💖 It's an IETF document from September 2013, written by Alvaro Retana, Liem Nguyen, Alex Zinin, Russ White, and Danny McPherson. Retana and Nguyen were at Cisco Systems, Inc., Zinin was at Cinarra Systems, and McPherson was at Verisign, Inc. White's affiliation isn't listed in the header. It's Informational in category, not a Standards Track spec 🧚 ISSN 2070-1721. It obsoletes RFC 3137 and doesn't update anything. ✨

Abstract ✨

This doc describes a backward-compatible trick OSPF (Open Shortest Path First) implementations can use to announce that a router shouldn't be forwarding transit traffic, or to lower how preferred the paths through that router are. 🦋

This document obsoletes RFC 3137. 💅

Status of This Memo 🌸

Not an Internet Standards Track spec, just published for info purposes, so no pressure 🙈

This is an IETF product and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

For the latest on this doc's status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6987. 🍓

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) as in effect on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 🦋

Sometimes it's useful to tell the other routers in a network "don't use this one as a transit point, but you can still route TO it." 💅 Some situations where that's handy:

• The router is in a critical condition (for example, it has a very high CPU load or doesn't have enough memory to store all Link State Advertisements (LSAs) or build the routing table). 😭
• Graceful introduction and removal of the router to/from the network. 🌈
• Other (administrative or traffic engineering) reasons. 🧚

Here's the vibe: the solution in this doc does not remove the router from the network's topology view, which is what you'd get by just flushing that router's router-LSA. Instead, it discourages other routers from using it for transit routing, while still routing packets to the router's own IP addresses. So the router gets announced as a stub. 🎀

It must be emphasized that the solution really pays off in networks with at least some redundancy, so traffic can be routed around the stub router. Otherwise, traffic bound for networks reachable through a stub router may still get routed through it. ⚠️

Redundancy is the whole point here, bestie. Without it, the stub router can still end up carrying your traffic. 💀

2. Solutions 💖

This solution tackles two challenges. 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.

Here's the tea: you could handle issue 1) alone by just flushing router X's router-LSA from the domain. But that doesn't solve problem 2), because other routers can't use links to router X in Dijkstra (no back link), and router X won't have links to its neighbors. 😭

To fix 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) 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] adds extra options that give similar control over the forwarding topology. The R-bit tells you whether a router is active and should be used for transit traffic. 🦋

Network operators get to pick which technique to use in their network. See Section 4 for more details. 🫶

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 🌈

Using MaxLinkMetric can cause some inconsistency if your network mixes two kinds of routers. One kind performs the intra-area Dijkstra calculation as specified in [RFC1247], discarding link records in router-LSAs that have a MaxLinkMetric cost value. The other kind performs it as specified in [RFC1583] and higher, and doesn't treat links with MaxLinkMetric cost as unreachable. 🙈

Good news though: this inconsistency won't lead to routing loops. If there are alternate paths in the network, both types of routers agree to use them instead of the path through the stub router. If the path through the stub router is the only one, the first type won't use the stub router for transit (which is the desired behavior), while the second type will still use that path. 💅

On the other hand, clearing the R-bit consistently results in the router not being used for transit. 🎀

Whether to use MaxLinkMetric or the R-bit depends on what the operator is going for. One thing to weigh is what should happen if the path through the stub router is the only one available. MaxLinkMetric lets that path 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. 🛡️

6. Acknowledgements 🫶

The authors don't make any claims on the originality of the ideas described. Among other people, they'd like to acknowledge Henk Smit for being part of one of the initial discussions around this topic. 🌸

They'd also 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 left 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.

Appendix A. Changes from RFC 3137 🎀

This document obsoletes [RFC3137]. ✨

Besides editorial updates, this document defines a new architectural constant (MaxLinkMetric in Section 3) to clear up any confusion about how LSInfinity gets interpreted. It also incorporates and explains the use of the R-bit [RFC5340] as a solution to the problem addressed in the text. 🦋

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

---

That's the whole doc, bestie! 🌈💖 Stub routers, MaxLinkMetric, and the R-bit, all wrapped up. Iconic. 👑✨