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/rfc7503.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc7503.txt (limited to 'doc/rfc/rfc7503.txt') diff --git a/doc/rfc/rfc7503.txt b/doc/rfc/rfc7503.txt new file mode 100644 index 0000000..75742a8 --- /dev/null +++ b/doc/rfc/rfc7503.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Lindem +Request for Comments: 7503 Cisco Systems +Updates: 5340 J. Arkko +Category: Standards Track Ericsson +ISSN: 2070-1721 April 2015 + + + OSPFv3 Autoconfiguration + +Abstract + + OSPFv3 is a candidate for deployments in environments where + autoconfiguration is a requirement. One such environment is the IPv6 + home network where users expect to simply plug in a router and have + it automatically use OSPFv3 for intra-domain routing. This document + describes the necessary mechanisms for OSPFv3 to be self-configuring. + This document updates RFC 5340 by relaxing the HelloInterval/ + RouterDeadInterval checking during OSPFv3 adjacency formation and + adding hysteresis to the update of self-originated Link State + Advertisements (LSAs). + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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/rfc7503. + + + + + + + + + + + + + + + + + +Lindem & Arkko Standards Track [Page 1] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +Copyright Notice + + Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 + + + + + + + + + + +Lindem & Arkko Standards Track [Page 2] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +1. Introduction + + OSPFv3 [OSPFV3] is a candidate for deployments in environments where + autoconfiguration is a requirement. This document describes + extensions to OSPFv3 to enable it to operate in these environments. + In this mode of operation, the protocol is largely unchanged from the + base OSPFv3 protocol specification [OSPFV3]. Since the goals of + autoconfiguration and security can be conflicting, operators and + network administrators should carefully consider their security + requirements before deploying the solution described in this + document. Refer to Section 8 for more information. + + The following aspects of OSPFv3 autoconfiguration are described in + this document: + + 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] is updated by allowing OSPFv3 adjacencies to be + formed between OSPFv3 routers with differing HelloIntervals or + RouterDeadIntervals (refer to Section 3). Additionally, hysteresis + has been added to the processing of stale self-originated LSAs to + mitigate the flooding overhead created by an OSPFv3 Router with a + duplicate OSPFv3 Router ID in the OSPFv3 routing domain (refer to + Section 7.4). Both updates are fully backward compatible. + +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]. + + + + + + + + + +Lindem & Arkko Standards Track [Page 3] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +2. OSPFv3 Default Configuration + + For complete autoconfiguration, OSPFv3 will need to choose suitable + configuration 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 is clear that + running OSPFv3 on the interface is not required. For example, if + manual configuration or another condition indicates that an + interface is connected to an Internet Service Provider (ISP), + there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] + specifically requires that IPv6 Customer Premise Equipment (CPE) + routers not initiate any dynamic routing protocol by default on + the router's WAN, i.e., ISP-facing, interface. In home + networking environments, an interface where no OSPFv3 neighbors + are found, but a DHCP IPv6 prefix can be acquired, may be + considered an ISP-facing interface, and running OSPFv3 is + unnecessary. + + 3. OSPFv3 interfaces will be autoconfigured to an interface type + corresponding to 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 + extant OSPFv3 implementations do this already. autoconfigured + operation over wireless networks requiring a point-to-multipoint + (P2MP) topology and dynamic metrics based on wireless feedback is + not within the scope of this document. However, + autoconfiguration is not precluded 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 not + supporting autoconfiguration [OSPFV3]. + + 5. All OSPFv3 interfaces SHOULD be autoconfigured to use an + Interface Instance ID of 0 that corresponds to the base IPv6 + unicast address family instance ID as 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, i.e., 64, SHOULD be autoconfigured as + the Interface Instance ID for all interfaces corresponding to the + IPv4 unicast OSPFv3 instance [OSPFV3-AF]. + + + + +Lindem & Arkko Standards Track [Page 4] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility + + autoconfigured OSPFv3 routers will not require an identical + HelloInterval and RouterDeadInterval to form adjacencies. Rather, + the received HelloInterval will be ignored and the received + RouterDeadInterval will be used to determine OSPFv3 liveliness with + the sending router. In other words, the Neighbor Inactivity Timer + (Section 10 of [OSPFV2]) for each neighbor will reflect that + neighbor's advertised RouterDeadInterval and MAY be different from + other OSPFv3 routers on the link without impacting adjacency + formation. A similar mechanism requiring additional signaling is + proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. + +3.1. Wait Timer Reduction + + In many situations, autoconfigured OSPFv3 routers will be deployed in + environments where back-to-back ethernet connections are utilized. + When this is the case, an OSPFv3 broadcast interface will not come up + until the other OSPFv3 router is connected, and the routers will wait + RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In + order to reduce this delay, an autoconfigured OSPFv3 router MAY + reduce the wait interval to a value no less than (HelloInterval + 1). + Reducing the setting will slightly increase the likelihood of the + Designated Router (DR) flapping but is preferable to the long + adjacency formation delay. Note that this value is not included in + OSPFv3 Hello packets and does not impact interoperability. + +4. OSPFv3 Minimal Authentication Configuration + + In many deployments, the requirement for OSPFv3 authentication + overrides the goal of complete OSPFv3 autoconfiguration. Therefore, + it is RECOMMENDED that OSPFv3 routers supporting this specification + minimally 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 to facilitate a + password with a high degree of entropy. When configured, the + password will be used on all autoconfigured interfaces with the + Security Association Identifier (SA ID) set to 1 and HMAC-SHA-256 + used as 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. Existing Router ID + selection algorithms (Appendix C.1 in [OSPFV2] and [OSPFV3]) are not + viable since they are dependent on a unique IPv4 interface address + that is not likely to be available in autoconfigured deployments. An + + + +Lindem & Arkko Standards Track [Page 5] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + OSPFv3 router implementing this specification will select a Router ID + that has a high probability of uniqueness. A pseudorandom number + SHOULD be used for the OSPFv3 Router ID. The generation SHOULD be + seeded with a variable that is likely to be unique in the applicable + OSPFv3 router deployment. A good choice of seed would be some + portion or hash of the Router-Hardware-Fingerprint as described in + Section 7.2.2. + + Since there is a possibility of a Router ID collision, duplicate + Router ID detection and resolution are required as described in + Sections 7 and 7.3. OSPFv3 routers SHOULD maintain the last + successfully chosen Router ID in nonvolatile storage to avoid + collisions subsequent to when an autoconfigured OSPFv3 router is + first added to the OSPFv3 routing domain. + +6. OSPFv3 Adjacency Formation + + Since OSPFv3 uses IPv6 link-local addresses for all protocol messages + other than messages sent on virtual links (which are not applicable + to autoconfiguration), OSPFv3 adjacency formation can proceed as soon + as a Router ID has been selected and the IPv6 link-local address has + completed Duplicate Address Detection (DAD) as specified in IPv6 + Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only + changes to the OSPFv3 base specification are supporting + HelloInterval/RouterDeadInterval flexibility as described in + Section 3 and duplicate Router ID detection and resolution as + described in Sections 7 and 7.3. + +7. OSPFv3 Duplicate Router ID Detection and Resolution + + There are two cases of duplicate OSPFv3 Router ID detection. One + where the OSPFv3 router with the duplicate Router ID is directly + connected and one where it is not. In both cases, the duplicate + resolution is for one of the routers to select a new OSPFv3 Router + ID. + +7.1. Duplicate Router ID Detection for Neighbors + + In this case, a duplicate Router ID is detected if any valid OSPFv3 + packet is received with the same OSPFv3 Router ID but a different + IPv6 link-local source address. Once this occurs, the OSPFv3 router + with the numerically smaller IPv6 link-local address will need to + select a new Router ID as described in Section 7.3. Note that the + fact that the OSPFv3 router is a neighbor on a non-virtual interface + implies that the router is directly connected. An OSPFv3 router + implementing this specification should ensure that the inadvertent + + + + + +Lindem & Arkko Standards Track [Page 6] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + connection of multiple router interfaces to the same physical link is + not misconstrued as detection of an OSPFv3 neighbor with a duplicate + Router ID. + +7.2. Duplicate Router ID Detection for Non-neighbors + + OSPFv3 routers implementing autoconfiguration, as specified herein, + MUST originate an Autoconfiguration (AC) Link State Advertisement + (LSA) including the Router-Hardware-Fingerprint Type-Length-Value + (TLV). The Router-Hardware-Fingerprint TLV contains a variable- + length value that has a very high probability of uniquely identifying + the advertising OSPFv3 router. An OSPFv3 router implementing this + specification MUST detect received Autoconfiguration LSAs with its + Router ID specified in the LSA header. LSAs received with the local + OSPFv3 Router's Router ID in the LSA header are perceived as self- + originated (see Section 4.6 of [OSPFV3]). In these received + Autoconfiguration LSAs, the Router-Hardware-Fingerprint TLV is + compared against the OSPFv3 Router's own router hardware fingerprint. + If the fingerprints are not equal, there is a duplicate Router ID + conflict and the OSPFv3 router with the numerically smaller router + hardware fingerprint MUST select a new Router ID as described in + Section 7.3. + + This new LSA is designated for information related to OSPFv3 + autoconfiguration and, in the future, could be used for other + autoconfiguration information, e.g., global IPv6 prefixes. However, + this is beyond the scope of this document. + +7.2.1. OSPFv3 Router Autoconfiguration LSA + + The OSPFv3 Autoconfiguration (AC) LSA has a function code of 15 and + the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit + will be set indicating that the OSPFv3 AC LSA should be flooded even + if it is not understood. The Link State ID (LSID) value will be an + integer index used to discriminate between multiple AC LSAs + originated by the same OSPFv3 router. This specification only + describes the contents of an AC LSA with an LSID of 0. + + + + + + + + + + + + + + +Lindem & Arkko Standards Track [Page 7] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + 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 format of the TLVs within the body of an AC LSA is the same as + the format used by the Traffic Engineering Extensions to OSPFv2 [TE]. + The LSA payload consists of one or more nested TLV triplets. The + format of each TLV is: + + 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 defines the length of the value portion in octets + (thus a TLV with no value portion would have a length of 0). The TLV + is padded to 4-octet alignment; padding is not included in the length + field (so a 3-octet value would have a length of 3, but the total + size of the TLV would be 8 octets). Nested TLVs are also 32-bit + aligned. For example, a 1-byte value would have the length field set + to 1, and 3 octets of padding would be added to the end of the value + portion of the TLV. Unrecognized types are ignored. + + The new LSA is designated for information related to OSPFv3 + autoconfiguration and, in the future, can be used other + autoconfiguration information. + + + + + +Lindem & Arkko Standards Track [Page 8] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +7.2.2. Router-Hardware-Fingerprint TLV + + The Router-Hardware-Fingerprint TLV is the first TLV defined for the + OSPFv3 Autoconfiguration (AC) LSA. It will have type 1 and MUST be + advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD + occur, at most, once and the first instance of the TLV will take + precedence over subsequent TLV instances. The length of the Router- + Hardware-Fingerprint is variable but must be 32 octets or greater. + If the Router-Hardware-Fingerprint TLV is not present as the first + TLV, the AC LSA is considered malformed and is ignored for the + purposes of duplicate Router ID detection. Additionally, the event + SHOULD be logged. + + The contents of the hardware fingerprint MUST have an extremely high + probability of uniqueness. It SHOULD be constructed from the + concatenation of a number of local values that themselves have a high + likelihood of uniqueness, such as Media Access Control (MAC) + addresses, CPU ID, or serial numbers. It is RECOMMENDED that one or + more available universal tokens (e.g., IEEE 802 48-bit MAC addresses + or IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router + be included in the hardware fingerprint. It MUST be based on + hardware attributes that will not 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 selected to resolve the duplicate OSPFv3 Router ID + condition must select a new OSPFv3 Router ID. The OSPFv3 router + SHOULD reduce the possibility of a subsequent Router ID 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 one is detected, a new + Router ID should be selected without going through the resolution + process (Section 7). After selecting a new Router ID, all self- + + + +Lindem & Arkko Standards Track [Page 9] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + originated LSAs MUST be reoriginated, and any OSPFv3 neighbor + adjacencies MUST be reestablished. The OSPFv3 router retaining the + Router ID causing the conflict 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, describes the processing of received + self-originated LSAs. If the received LSA doesn't exist, the + receiving router will flush it from the OSPF routing domain. If the + LSA is newer than the version in the LSDB, the receiving router will + originate a newer version by advancing the LSA sequence number and + reoriginating. Since it is possible for an autoconfigured OSPFv3 + router to choose a duplicate OSPFv3 Router ID, OSPFv3 routers + implementing this specification should detect when multiple instances + of the same self-originated LSA are flushed or reoriginated since + this is indicative of an OSPFv3 router with a duplicate Router ID in + the OSPFv3 routing domain. When this condition is detected, the + OSPFv3 router SHOULD delay self-originated LSA processing for LSAs + that have recently been flushed or reoriginated. This specification + recommends 10 seconds as the interval defining recent self-originated + LSA processing and an exponential back-off of 1 to 8 seconds for the + processing delay. This additional delay should allow for the + mechanisms described in Section 7 to resolve the duplicate OSPFv3 + Router ID conflict. + + Since this mechanism is useful in mitigating the flooding overhead + associated with the inadvertent or malicious introduction of an + OSPFv3 router with a duplicate Router ID into an OSPFv3 routing + domain, it MAY be deployed outside of autoconfigured deployments. + The detection of a self-originated LSA that is being repeatedly + reoriginated or flushed SHOULD be logged. + +8. Security Considerations + + The goals of security and complete OSPFv3 autoconfiguration are + somewhat contradictory. When no explicit security configuration + takes place, autoconfiguration implies that additional devices placed + in the network are automatically adopted as a part of the network. + However, autoconfiguration can also be combined with password + configuration (see Section 4) or future extensions for automatic + pairing between devices. These mechanisms can help provide an + automatically configured, securely routed network. + + In deployments where a different authentication algorithm or + encryption is required (or different per-interface keys are + required), OSPFv3 IPsec [OSPFV3-IPSEC] or alternate OSPFv3 + + + +Lindem & Arkko Standards Track [Page 10] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + Authentication Trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used + at the expense of additional configuration. The configuration and + operational description of such deployments are beyond the scope of + this document. However, a deployment could always revert to explicit + configuration as described in Section 9 for features such as IPsec, + per-interface keys, or alternate authentication algorithms. + + The introduction, either malicious or accidental, of an OSPFv3 router + with a duplicate Router ID is an attack point for OSPFv3 routing + domains. This is due to the fact that OSPFv3 routers will interpret + LSAs advertised by the router with the same Router ID as self- + originated LSAs and attempt to flush them from the routing domain. + The mechanisms in Section 7.4 will mitigate the effects of + duplication. + +9. Management Considerations + + It is RECOMMENDED that OSPFv3 routers supporting this specification + also support explicit configuration of OSPFv3 parameters as specified + in Appendix C of [OSPFV3]. This would allow explicit override of + autoconfigured parameters in situations where it is required (e.g., + if the 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 is 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 mechanisms + for displaying or otherwise conveying OSPFv3 operational state to + indicate whether or not the OSPFv3 router was autoconfigured and + whether or not its OSPFv3 interfaces have been autoconfigured. + +10. IANA Considerations + + This specification 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. + + + + + + + + +Lindem & Arkko Standards Track [Page 11] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + This specification also creates a registry for OSPFv3 + Autoconfiguration (AC) LSA TLVs. This registry has been placed in + the existing OSPFv3 IANA registry, and new values will be allocated + via IETF Review or, under exceptional circumstances, IESG Approval. + [IANA-GUIDELINES] + + Three initial values are allocated: + + o 0 is marked as Reserved. + + o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). + + o 65535 is an Autoconfiguration-Experiment-TLV, a common value that + can be used for experimental purposes. + +11. References + +11.1. Normative References + + [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, + . + + [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008, + . + + [OSPFV3-AF] + Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and + R. Aggarwal, "Support of Address Families in OSPFv3", RFC + 5838, April 2010, + . + + [OSPFV3-AUTH-TRAILER] + Bhatia, M., Manral, V., and A. Lindem, "Supporting + Authentication Trailer for OSPFv3", RFC 7166, March 2014, + . + + [RFC-KEYWORDS] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007, + . + + + + + + +Lindem & Arkko Standards Track [Page 12] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + [TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, September + 2003, . + +11.2. Informative References + + [ASYNC-HELLO] + Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold + Timer", Work in Progress, draft-madhukar-ospf-agr- + asymmetric-01, June 2013. + + [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", + Registration Authority Tutorial, March 1997, + . + + [IANA-GUIDELINES] + Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [IPv6-CPE] + Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + November 2013, . + + [OSPFV3-IPSEC] + Gupta, M. and N. Melam, "Authentication/Confidentiality + for OSPFv3", RFC 4552, June 2006, + . + +Acknowledgments + + This specification was inspired by the work presented in the HOMENET + working group meeting in October 2011 in Philadelphia, Pennsylvania. + In particular, we would like to thank Fred Baker, Lorenzo Colitti, + Ole Troan, Mark Townsley, and Michael Richardson. + + Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 + autoconfiguration in the expired Internet-Draft titled + "Autoconfiguration of routers using a link state routing protocol". + There are many similarities between the concepts and techniques in + this document. + + Thanks for Abhay Roy and Manav Bhatia for comments regarding + duplicate Router ID processing. + + + + + +Lindem & Arkko Standards Track [Page 13] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + + Thanks for Alvaro Retana and Michael Barnes for comments regarding + 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. + + + + + + + + + + +Lindem & Arkko Standards Track [Page 14] + +RFC 7503 OSPFv3 Autoconfiguration April 2015 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lindem & Arkko Standards Track [Page 15] + -- cgit v1.2.3