GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7503

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,
            <http://www.rfc-editor.org/info/rfc2328>.
 [OSPFV3]   Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
            for IPv6", RFC 5340, July 2008,
            <http://www.rfc-editor.org/info/rfc5340>.
 [OSPFV3-AF]
            Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
            R. Aggarwal, "Support of Address Families in OSPFv3", RFC
            5838, April 2010,
            <http://www.rfc-editor.org/info/rfc5838>.
 [OSPFV3-AUTH-TRAILER]
            Bhatia, M., Manral, V., and A. Lindem, "Supporting
            Authentication Trailer for OSPFv3", RFC 7166, March 2014,
            <http://www.rfc-editor.org/info/rfc7166>.
 [RFC-KEYWORDS]
            Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [SLAAC]    Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862, September 2007,
            <http://www.rfc-editor.org/info/rfc4862>.

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, <http://www.rfc-editor.org/info/rfc3630>.

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,
            <http://standards.ieee.org/regauth/oui/tutorials/
            EUI64.html>.
 [IANA-GUIDELINES]
            Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008, <http://www.rfc-editor.org/info/rfc5226>.
 [IPv6-CPE]
            Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
            Requirements for IPv6 Customer Edge Routers", RFC 7084,
            November 2013, <http://www.rfc-editor.org/info/rfc7084>.
 [OSPFV3-IPSEC]
            Gupta, M. and N. Melam, "Authentication/Confidentiality
            for OSPFv3", RFC 4552, June 2006,
            <http://www.rfc-editor.org/info/rfc4552>.

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7503.txt · Last modified: 2015/04/06 20:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki