RFC 7503

OSPFv3 Autoconfiguration

📅 published April 2015, from ietf

RFC 7503: OSPFv3 Autoconfiguration (Part 1 of 3) 🎀

Internet Engineering Task Force (IETF) 💖 This one is from April 2015, bestie. It's a Standards Track doc, so it's an actual official spec and not just an idea someone had. It's by A. Lindem from Cisco Systems and J. Arkko from Ericsson, and the ISSN is 2070-1721. It updates RFC 5340, which is the base OSPFv3 spec, so this doc is basically a glow-up for it ✨

Abstract ✨

OSPFv3 is a strong candidate for places where autoconfiguration is a must, like the home IPv6 network 🏠 The dream is that people just plug in a router and it starts using OSPFv3 for intra-domain routing on its own, no fuss 🫶 This doc lays out the mechanisms OSPFv3 needs to become self-configuring. It also updates RFC 5340 in two ways: it relaxes the HelloInterval/RouterDeadInterval checking during OSPFv3 adjacency formation, and it adds hysteresis to how self-originated Link State Advertisements (LSAs) get updated 💅

Status of This Memo 🧾

This is an Internet Standards Track document. 💜

It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on. It went through public review and the Internet Engineering Steering Group (IESG) approved it for publication. You can read more about Internet Standards in Section 2 of RFC 5741 📚

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7503 🌸

Copyright (c) 2015 IETF Trust and the people listed as the document authors. All rights reserved. ©️

This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info. Those rules are the ones in effect on the publication date, so please actually read them, because they explain your rights and restrictions for this document 🧐

If you pull Code Components out of this document, they must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, just like the Simplified BSD License says 🔥

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
2.  OSPFv3 Default Configuration  . . . . . . . . . . . . . . . .   4
3.  OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . .   5
  3.1.  Wait Timer Reduction  . . . . . . . . . . . . . . . . . .   5
4.  OSPFv3 Minimal Authentication Configuration . . . . . . . . .   5
5.  OSPFv3 Router ID Selection  . . . . . . . . . . . . . . . . .   5
6.  OSPFv3 Adjacency Formation  . . . . . . . . . . . . . . . . .   6
7.  OSPFv3 Duplicate Router ID Detection and Resolution . . . . .   6
  7.1.  Duplicate Router ID Detection for Neighbors . . . . . . .   6
  7.2.  Duplicate Router ID Detection for Non-neighbors . . . . .   7
    7.2.1.  OSPFv3 Router Autoconfiguration LSA . . . . . . . . .   7
    7.2.2.  Router-Hardware-Fingerprint TLV . . . . . . . . . . .   9
  7.3.  Duplicate Router ID Resolution  . . . . . . . . . . . . .   9
  7.4.  Change to RFC 2328, Section 13.4 ("Receiving
        Self-Originated LSAs")  . . . . . . . . . . . . . . . . .  10
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
9.  Management Considerations . . . . . . . . . . . . . . . . . .  11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
  11.2.  Informative References . . . . . . . . . . . . . . . . .  13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction 🦋

OSPFv3 [OSPFV3] is a strong candidate for places where autoconfiguration is required, so this doc describes the extensions that let it work in those environments 🌷 In this mode, the protocol stays mostly the same as the base OSPFv3 spec [OSPFV3] 🙌

Real talk: autoconfiguration and security can totally clash, so operators and network admins should think hard about their security needs before deploying what's in this doc. See Section 8 for more 🔒

Here's what this doc covers for OSPFv3 autoconfiguration:

  1. Default OSPFv3 Configuration
  2. HelloInterval/RouterDeadInterval Flexibility
  3. OSPFv3 Minimal Authentication Configuration
  4. Unique OSPFv3 Router ID Generation
  5. OSPFv3 Adjacency Formation
  6. Duplicate OSPFv3 Router ID Resolution
  7. Self-Originated LSA Processing

OSPFv3 [OSPFV3] gets an upgrade: OSPFv3 adjacencies can now form between routers with different HelloIntervals or RouterDeadIntervals (see Section 3) 💅 There's also hysteresis added to how stale self-originated LSAs get processed, which helps cut down on the flooding overhead a duplicate OSPFv3 Router ID causes in the routing domain (see Section 7.4) ✨ Both updates are fully backward compatible, so no drama 🫶

1.1. Requirements Notation 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS] 🧠

2. OSPFv3 Default Configuration 🎀

For full autoconfiguration, OSPFv3 needs to pick some sensible defaults. These include:

  1. Area 0 Only - All autoconfigured OSPFv3 interfaces MUST be in area 0. 🌳
  2. OSPFv3 SHOULD be autoconfigured on all IPv6-capable interfaces on the router. An interface MAY be excluded if it's clear that running OSPFv3 on it isn't needed. For example, if manual config or some other condition shows that an interface connects to an Internet Service Provider (ISP), there's usually no reason to run OSPFv3 there. Honestly, [IPv6-CPE] specifically says IPv6 Customer Premise Equipment (CPE) routers should not start any dynamic routing protocol by default on the router's WAN interface, which means the ISP-facing one 🙅‍♀️ In home networks, an interface where no OSPFv3 neighbors show up but a DHCP IPv6 prefix can be acquired may count as ISP-facing, and running OSPFv3 there is unnecessary 💀
  3. OSPFv3 interfaces will be autoconfigured to an interface type that matches their Layer 2 capability. For example, Ethernet interfaces and Wi-Fi interfaces will be autoconfigured as OSPFv3 broadcast networks, and Point-to-Point Protocol (PPP) interfaces will be autoconfigured as OSPFv3 Point-to-Point interfaces. Most existing OSPFv3 implementations already do this. Autoconfigured operation over wireless networks that need a point-to-multipoint (P2MP) topology and dynamic metrics based on wireless feedback is not in scope for this doc. However, autoconfiguration is not ruled out in these environments 📡
  4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and RouterDeadInterval as specified in Section 3. Of course, an identical HelloInterval and RouterDeadInterval will still be required to form an adjacency with an OSPFv3 router that doesn't support autoconfiguration [OSPFV3]. 🤝
  5. All OSPFv3 interfaces SHOULD be autoconfigured to use an Interface Instance ID of 0, which matches the base IPv6 unicast address family instance ID defined in [OSPFV3-AF] 🔢 Similarly, if IPv4 unicast addresses are advertised in a separate autoconfigured OSPFv3 instance, the base IPv4 unicast address family instance ID value, which is 64, SHOULD be autoconfigured as the Interface Instance ID for all interfaces that belong to the IPv4 unicast OSPFv3 instance [OSPFV3-AF] 🌈

3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 💫

Autoconfigured OSPFv3 routers won't need an identical HelloInterval and RouterDeadInterval to form adjacencies. Instead, the received HelloInterval gets ignored, and the received RouterDeadInterval is used to decide OSPFv3 liveliness with the sending router. In other words, the Neighbor Inactivity Timer (Section 10 of [OSPFV2]) for each neighbor reflects that neighbor's advertised RouterDeadInterval, and it MAY differ from other OSPFv3 routers on the link without affecting adjacency formation 🧚 A similar mechanism that needs extra signaling is proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO] 👀

3.1. Wait Timer Reduction ⏱️

In lots of situations, autoconfigured OSPFv3 routers get deployed where back-to-back ethernet connections are used. When that happens, an OSPFv3 broadcast interface won't come up until the other OSPFv3 router is connected, and the routers would wait RouterDeadInterval seconds before forming an adjacency [OSPFV2] 😩 To cut down on that delay, an autoconfigured OSPFv3 router MAY reduce the wait interval to a value no less than (HelloInterval + 1). Lowering it does slightly increase the chance the Designated Router (DR) flaps, but that's way better than a long adjacency formation delay 🙌 Note that this value is not included in OSPFv3 Hello packets and does not affect interoperability ✨

4. OSPFv3 Minimal Authentication Configuration 🔐

In a lot of deployments, the need for OSPFv3 authentication beats the goal of total OSPFv3 autoconfiguration 😤 So it is RECOMMENDED that OSPFv3 routers supporting this spec at least offer an option to explicitly configure a single password for HMAC-SHA authentication, as described in [OSPFV3-AUTH-TRAILER] 💜 It is RECOMMENDED that the password be entered as ASCII hexadecimal digits, and that 32 or more digits be accepted so people can make a password with a high degree of entropy 🗝️ When it's configured, the password gets used on all autoconfigured interfaces with the Security Association Identifier (SA ID) set to 1, and HMAC-SHA-256 is the authentication algorithm 🦋

5. OSPFv3 Router ID Selection 🆔

An OSPFv3 router requires a unique Router ID within the OSPFv3 routing domain for correct protocol operation. Okay, the old Router ID selection algorithms (Appendix C.1 in [OSPFV2] and [OSPFV3]) aren't viable here, because they depend on a unique IPv4 interface address that's probably not available in autoconfigured deployments 🙈 So an OSPFv3 router implementing this spec picks a Router ID that has a high probability of being unique. A pseudorandom number SHOULD be used for the OSPFv3 Router ID 🎲 The generation SHOULD be seeded with a variable that's likely to be unique in the applicable OSPFv3 router deployment. A good seed choice would be some portion or hash of the Router-Hardware-Fingerprint, which is described in Section 7.2.2 🧩

Since a Router ID collision is possible, duplicate Router ID detection and resolution are required, as described in Sections 7 and 7.3 🚨 OSPFv3 routers SHOULD keep the last successfully chosen Router ID in nonvolatile storage, so they avoid collisions after an autoconfigured OSPFv3 router is first added to the OSPFv3 routing domain 💾🌸

  1. OSPFv3 Adjacency Formation ✨

Okay so, OSPFv3 uses IPv6 link-local addresses for basically every protocol message, except the ones sent over virtual links (which don't really apply to autoconfiguration anyway 💅). That means adjacency formation can kick off as soon as a Router ID has been picked AND the link-local address has passed Duplicate Address Detection (DAD) as described in IPv6 Stateless Address Autoconfiguration [SLAAC]. 🦋 Otherwise, the only changes to the OSPFv3 base spec are the HelloInterval/RouterDeadInterval flexibility from Section 3 and the duplicate Router ID detection and resolution from Sections 7 and 7.3. It's giving teamwork 🫶

  1. OSPFv3 Duplicate Router ID Detection and Resolution 🔥

Bestie, there are two ways a duplicate OSPFv3 Router ID can show up. Either the router with the duplicate is directly connected to you, or it isn't. Either way, the fix is the same: one of the routers has to pick a brand new Router ID. Main character energy for whoever gets the reroll 🎀

7.1. Duplicate Router ID Detection for Neighbors 🌸

So in this case, a duplicate is detected if any valid OSPFv3 packet shows up with the same Router ID but a different IPv6 link-local source address. Once that happens, the router with the numerically smaller IPv6 link-local address is the one that needs to pick a new Router ID (see Section 7.3) 🥺. Also, being a neighbor on a non-virtual interface already means the router is directly connected, so no mystery there ✨. An OSPFv3 router implementing this spec should make sure that accidentally plugging several router interfaces into the same physical link doesn't get misread as a neighbor with a duplicate Router ID. Not that deep, but it's important 💀

7.2. Duplicate Router ID Detection for Non-neighbors 🍓

OSPFv3 routers doing autoconfiguration, as specified here, MUST originate an Autoconfiguration (AC) Link State Advertisement (LSA) that includes the Router-Hardware-Fingerprint Type-Length-Value (TLV). The fingerprint is a variable-length value with a very high probability of uniquely identifying the advertising router, so it's basically a hardware ID card 🪪. An OSPFv3 router implementing this spec MUST detect received Autoconfiguration LSAs that have its own Router ID in the LSA header. Those LSAs count as self-originated (see Section 4.6 of [OSPFV3]) 👑. In these received AC LSAs, the Router-Hardware-Fingerprint TLV gets compared to the router's own hardware fingerprint. If they don't match, there's a duplicate Router ID conflict, and the router with the numerically smaller router hardware fingerprint MUST select a new Router ID as described in Section 7.3 💅.

This new LSA is for information about OSPFv3 autoconfiguration. In the future it could also carry other autoconfiguration info, like global IPv6 prefixes, but that's out of scope for this doc 🌈.

7.2.1. OSPFv3 Router Autoconfiguration LSA 🧚

The OSPFv3 Autoconfiguration (AC) LSA has a function code of 15, and the S2/S1 bits are set to 01, which means Area Flooding Scope 🦋. The U bit gets set so the AC LSA is flooded even if it isn't understood (very generous of it, honestly 🫶). The Link State ID (LSID) is an integer index used to tell apart multiple AC LSAs from the same router. This spec only describes the contents of an AC LSA with an LSID of 0.

        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             |1|0|1|           15            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Link State ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Advertising Router                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       LS sequence number                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        LS checksum            |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                            TLVs                             -+
       |                             ...                               |

                     OSPFv3 Autoconfiguration (AC) LSA

The TLVs inside an AC LSA use the same format as the Traffic Engineering Extensions to OSPFv2 [TE]. The LSA payload is one or more nested TLV triplets. Each TLV looks like this:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                TLV Format

The Length field is the length of the value portion in octets (so a TLV with no value has a length of 0). Each TLV is padded to 4-octet alignment, and the padding doesn't count in the length field. That means a 3-octet value has a length of 3, but the whole TLV takes up 8 octets. Nested TLVs are 32-bit aligned too. For example, a 1-byte value has its length field set to 1, plus 3 octets of padding at the end of the value portion. Unrecognized types are ignored 🙈.

The new LSA is for information about OSPFv3 autoconfiguration and, in the future, can be used for other autoconfiguration info too 🌸.

7.2.2. Router-Hardware-Fingerprint TLV 💖

The Router-Hardware-Fingerprint TLV is the first TLV defined for the OSPFv3 Autoconfiguration (AC) LSA. It has type 1 and MUST be advertised in the OSPFv3 AC LSA with an LSID of 0. It SHOULD occur at most once, and if there are multiple instances, the first one wins 🥇. The length of the Router-Hardware-Fingerprint is variable but MUST be 32 octets or greater. Hmm, careful here: the text says "must be", so it's a firm rule 🙈. If the Router-Hardware-Fingerprint TLV isn't the first TLV, the AC LSA is considered malformed and gets ignored for duplicate Router ID detection. The event SHOULD be logged 📝.

The contents of the hardware fingerprint MUST have an extremely high probability of uniqueness. It SHOULD be built by concatenating a bunch of local values that are each pretty likely to be unique, like Media Access Control (MAC) addresses, CPU IDs, or serial numbers 🔥. It is RECOMMENDED that one or more available universal tokens (for example IEEE 802 48-bit MAC addresses or IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be included in the fingerprint ✨. It MUST be based on hardware attributes that don't change across hard and soft restarts 💅.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              1                |             >32               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Router Hardware Fingerprint                |
                                      o
                                      o
                                      o
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Router-Hardware-Fingerprint TLV Format

7.3. Duplicate Router ID Resolution 🦋

The OSPFv3 router picked to resolve the duplicate Router ID condition MUST select a new OSPFv3 Router ID. Before committing, the router SHOULD reduce the chance of another collision by checking the Link State Database (LSDB) for an OSPFv3 Autoconfiguration LSA with the newly selected Router ID and a different Router-Hardware-Fingerprint. If it finds one, it SHOULD select a new Router ID without going through the resolution process (Section 7) again 🔄. After picking the new Router ID, all self-originated LSAs MUST be reoriginated, and any OSPFv3 neighbor adjacencies MUST be reestablished 🫶. The router that keeps the conflicting Router ID will reoriginate or flush any stale self-originated LSAs, as described in Section 13.4 of [OSPFV2] 🧹.

7.4. Change to RFC 2328, Section 13.4 ("Receiving Self-Originated LSAs") 🌈

RFC 2328 [OSPFV2], Section 13.4, covers how received self-originated LSAs get processed. If the received LSA doesn't exist, the receiving router flushes it from the OSPF routing domain. If the LSA is newer than the version in the LSDB, the receiving router originates a newer version by advancing the LSA sequence number and reoriginating. Since an autoconfigured OSPFv3 router could end up choosing a duplicate Router ID, routers implementing this spec SHOULD detect when multiple instances of the same self-originated LSA get flushed or reoriginated. That's a sign of a duplicate Router ID in the routing domain 🚨. When this happens, the router SHOULD delay self-originated LSA processing for LSAs that were recently flushed or reoriginated. This spec recommends 10 seconds as the window for "recent" self-originated LSA processing, and an exponential back-off of 1 to 8 seconds for the processing delay ⏳. That extra delay gives the mechanisms in Section 7 time to sort out the duplicate Router ID conflict 💖.

This mechanism is useful for cutting down the flooding overhead caused by an OSPFv3 router with a duplicate Router ID getting introduced into the routing domain, whether that's by accident or on purpose. So it MAY be deployed outside of autoconfigured deployments too 👑. Detecting a self-originated LSA that keeps getting reoriginated or flushed SHOULD be logged 📝✨.

8. Security Considerations 🔒

okay bestie, security is where things get SPICY 🌶️ because autoconfiguration and security are kinda in tension, ngl. if nobody sets up any explicit security, then any new device you plug in just gets adopted into the network automatically 🫣. BUT you can pair autoconfig with password configuration (see Section 4), or with future extensions for automatic pairing between devices, and then you get a network that's autoconfigured AND securely routed 💅✨ iconic.

If your deployment needs a different authentication algorithm or encryption (or different per-interface keys), then OSPFv3 IPsec [OSPFV3-IPSEC] or alternate OSPFv3 Authentication Trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used, but it costs you some extra configuration 🎀. How to configure and run those setups is out of scope for this doc, sorry not sorry 🙈. Also, a deployment can always fall back to explicit configuration as described in Section 9 for things like IPsec, per-interface keys, or alternate authentication algorithms 🧚.

⚠️ bestie, read this part twice. The introduction of an OSPFv3 router with a duplicate Router ID is an attack point for OSPFv3 routing domains, whether it's malicious or accidental 😭. The reason is that OSPFv3 routers will interpret LSAs advertised by the router with the same Router ID as their own self-originated LSAs, and then they'll try to flush them out of the routing domain 💀. The mechanisms in Section 7.4 will mitigate the effects of duplication 🛡️.

9. Management Considerations 🎛️

okay so here's the vibe for management. It is RECOMMENDED that OSPFv3 routers supporting this specification also support explicit configuration of OSPFv3 parameters as specified in Appendix C of [OSPFV3] 🍓. This lets you explicitly override autoconfigured parameters when you need to, like if your deployment requires multiple OSPFv3 areas. This is in addition to the authentication key configuration recommended in Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers supporting this specification allow autoconfiguration to be completely disabled 🙌.

Since there's a small possibility of OSPFv3 Router ID collisions, manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 routing domains where route convergence due to a Router ID change is intolerable 🥺.

OSPFv3 routers supporting this specification MUST augment the mechanisms for displaying or otherwise conveying OSPFv3 operational state, so they indicate whether or not the OSPFv3 router was autoconfigured and whether or not its OSPFv3 interfaces have been autoconfigured 👑. Non-negotiable, periodt 💅.

10. IANA Considerations 📚

this spec defines an OSPFv3 LSA Type for the OSPFv3 Autoconfiguration (AC) LSA, as described in Section 7.2.1 ✨. The value 15 has been allocated from the existing "OSPFv3 LSA Function Codes" registry for the OSPFv3 Autoconfiguration (AC) LSA 🦋.

It also creates a registry for OSPFv3 Autoconfiguration (AC) LSA TLVs 🌈. That registry lives inside the existing OSPFv3 IANA registry, and new values get allocated via IETF Review or, under exceptional circumstances, IESG Approval [IANA-GUIDELINES].

Three initial values are allocated:

  • 0 is marked as Reserved.
  • 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2).
  • 65535 is an Autoconfiguration-Experiment-TLV, a common value that can be used for experimental purposes 🧪.

11. References 📖

11.1. Normative References

11.2. Informative References

Acknowledgments 🫶

this spec was inspired by the work presented at the HOMENET working group meeting in October 2011 in Philadelphia, Pennsylvania 🏙️. Big thanks to Fred Baker, Lorenzo Colitti, Ole Troan, Mark Townsley, and Michael Richardson 💜.

Arthur Dimitrelis and Aidan Williams did prior work on OSPFv3 autoconfiguration in the expired Internet-Draft titled "Autoconfiguration of routers using a link state routing protocol". There are lots of similarities between the concepts and techniques in this document, so they get love too ✨.

Thanks to Abhay Roy and Manav Bhatia for comments on duplicate Router ID processing 🙏.

Thanks to Alvaro Retana and Michael Barnes for comments on OSPFv3 Instance ID autoconfiguration 🧠.

Thanks to Faraz Shamim for review and comments 🌸.

Thanks to Mark Smith for the requirement to reduce the adjacency formation delay in the back-to-back ethernet topologies that are prevalent in home networks 🏠.

Thanks to Les Ginsberg for document review and recommendations on OSPFv3 hardware fingerprint content 🔍.

Thanks to Curtis Villamizar for document review and analysis of duplicate Router ID resolution nuances 🤓.

Thanks to Uma Chunduri for comments during OSPF WG last call 📣.

Thanks to Martin Vigoureux for Routing Area Directorate review and comments 🧭.

Thanks to Adam Montville for Security Area Directorate review and comments 🔐.

Thanks to Qin Wu for Operations & Management Area Directorate review and comments 🛠️.

Thanks to Robert Sparks for General Area (GEN-ART) review and comments 🌿.

Thanks to Rama Darbha for review and comments 🎀.

Special thanks to Adrian Farrel for his in-depth review, copious comments, and suggested text 👑.

Special thanks go to Markus Stenberg for his implementation of this specification in Bird 🐦.

Special thanks also go to David Lamparter for his implementation of this specification in Quagga 🌟.

This document was initially produced using the xml2rfc tool 🧚.

Authors' Addresses 📮

Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC  27513
United States

EMail: acee@cisco.com


Jari Arkko
Ericsson
Jorvas, 02420
Finland

EMail: jari.arkko@piuha.net
📦 where this page comes from