RFC 7684

OSPFv2 Prefix/Link Attribute Advertisement

📅 published November 2015, from ietf

🎀 RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement 🎀

okay bestie, so this is the doc that lets OSPFv2 carry extra attributes for prefixes and links without redoing the old fixed-format LSAs 🦋 it's giving "add a little extra info, keep everything backward compatible" energy and I'm obsessed ✨

Title block vibes 💅: it's an Internet Standards Track document (so it's a real, official spec, not just a vibe 👑), published in November 2015 by a squad of authors: P. Psenak (Cisco Systems), H. Gredler (Independent), R. Shakir (Jive Communications, Inc.), W. Henderickx (Alcatel-Lucent), J. Tantsura (Ericsson), and A. Lindem (Cisco Systems) 🫶. It's published under the ISSN 2070-1721, and it doesn't obsolete or update any other RFCs, so it's its own little main character 🌸

Abstract

OSPFv2 needs to be extended in ways the fixed-format Link State Advertisements (LSAs) from RFC 2328 just can't handle easily 😭 This doc defines OSPFv2 Opaque LSAs built on Type-Length-Value (TLV) tuples, which can attach extra attributes to prefixes or links 🧚 Depending on the application, those prefixes and links might or might not show up in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible, so nobody's left out 💖

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, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG) 💅 For more on Internet Standards, check Section 2 of RFC 5741 🌈

Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7684 ✨

Copyright Notice

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. Please read these carefully, because they spell out your rights and restrictions 📜 Code Components pulled out of 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 that license 💜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from them, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🙈

Table of Contents 🍓

1. Introduction ....................................................3
   1.1. Requirements Notation ......................................3
2. OSPFv2 Extended Prefix Opaque LSA ...............................3
   2.1. OSPFv2 Extended Prefix TLV .................................5
3. OSPFv2 Extended Link Opaque LSA .................................8
   3.1. OSPFv2 Extended Link TLV ...................................9
4. Backward Compatibility .........................................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
   6.1. OSPFv2 Extended Prefix Opaque LSA TLVs Registry ...........11
   6.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry ..............12
   6.3. OSPFv2 Extended Prefix TLV Flags Registry .................12
   6.4. OSPFv2 Extended Link Opaque LSA TLVs Registry .............12
   6.5. OSPFv2 Extended Link TLV Sub-TLVs Registry ................13
7. References .....................................................13
   7.1. Normative References ......................................13
   7.2. Informative References ....................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................15

1. Introduction ✨

OSPFv2 needs functional extensions that the fixed-format Link State Advertisements (LSAs) described in RFC 2328 [OSPFV2] can't readily do 😭 So this document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples, which let you attach extra attributes to prefixes or links 💖 Depending on the application, those prefixes and links may or may not be advertised in the fixed-format LSAs, and the OSPFv2 Opaque LSAs are optional and fully backward compatible 🫶

Contrast this with OSPFv3 [OSPFv3-EXTEND], where the existing LSAs get replaced by TLV-based extended LSAs. OSPFv2 is taking the more chill route 🦋

New requirements like source/destination routing, route tagging, and segment routing are the reason this extension exists 🌈

This specification defines the following OSPFv2 Opaque LSAs:

OSPFv2 Extended Prefix Opaque LSA: allows advertisement of additional attributes for prefixes advertised in Router-LSAs, Network-LSAs, Summary-LSAs (IP network), NSSA-LSAs, and AS-external-LSAs [OSPFV2][RFC3101] 🎀
OSPFv2 Extended Link Opaque LSA: allows advertisement of additional attributes for links advertised in Router-LSAs 🧚

It also defines these TLVs:

OSPFv2 Extended Prefix TLV: top-level TLV advertising attributes for a prefix in the OSPFv2 Extended Prefix Opaque LSA 💅
OSPFv2 Extended Link TLV: top-level TLV advertising attributes for a link in the OSPFv2 Extended Link Opaque LSA 👑

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 [KEYWORDS] 🔥

2. OSPFv2 Extended Prefix Opaque LSA 🌸

The OSPFv2 Extended Prefix Opaque LSA is how you advertise additional prefix attributes 💖 Opaque LSAs are described in [OPAQUE] 🦋

An OSPFv2 router can advertise multiple OSPFv2 Extended Prefix Opaque LSAs ✨ Their flooding scope depends on the scope of the prefixes being advertised, and the advertising router controls it 💅 In some cases (for example, a mapping server deployment [SEGMENT-ROUTING]), the LSA flooding scope can be bigger than the scope of the matching prefixes 🌈

The format of the OSPFv2 Extended Prefix Opaque LSA 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |   LS Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Opaque Type  |                 Opaque ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

                OSPFv2 Extended Prefix Opaque LSA

The Opaque Type used by the OSPFv2 Extended Prefix Opaque LSA is 7 🎀 Opaque Type is how you tell the different OSPFv2 Opaque LSAs apart, and Section 3 of [OPAQUE] explains it 💜 The LS Type may be 10 or 11, which sets the Opaque LSA flooding scope: 10 means area-local and 11 means AS-wide [OPAQUE] 🌸 The LSA Length field [OSPFV2] is the total length in octets of the Opaque LSA, counting the LSA header and all TLVs (padding included) 🍓

The Opaque ID is an arbitrary value used to keep multiple OSPFv2 Extended Prefix Opaque LSAs apart 🧚 For these LSAs it has no semantic meaning beyond telling apart the ones originated by the same OSPFv2 router 💖 If multiple OSPFv2 Extended Prefix Opaque LSAs include the same prefix, the attributes from the one with the lowest Opaque ID SHOULD be used 🫶

The TLVs in the body of the OSPFv2 Extended Prefix Opaque LSA use the same format as the Traffic Engineering Extensions to OSPFv2 [TE] 🦋 The variable TLV section holds one or more nested TLV tuples, and nested TLVs are also called sub-TLVs 🌈 Each TLV is formatted 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                              |
                                  o
                                  o
                                  o
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             TLV Format

The Length field is the length of the value portion in octets, so a TLV with no value portion has a length of 0 👑 Each TLV is padded to 4-octet alignment, but the padding does NOT count toward the Length field 💅 So 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, and 3 octets of padding get added to the end of the value portion 🦋 That padding is made of zeros 🎀

⚠️ Heads up, this is only part 1 of 3! More sections (2.1 onward, the Extended Link LSA, IANA, Security, the works) are coming next, so stay tuned, bestie 💖

2.1. OSPFv2 Extended Prefix TLV 🎀

okay so the OSPFv2 Extended Prefix TLV is how we slide extra attributes onto a prefix ✨. Multiple OSPFv2 Extended Prefix TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA 💖. But here's the tea: the Opaque LSA type is what decides how far the LSA floods 🌊, so that flooding scope MUST satisfy the application-specific needs of every prefix packed into one OSPFv2 Extended Prefix Opaque LSA. no cap, that's a big deal bestie 👑. The format 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            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Route Type   | Prefix Length |     AF        |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Address Prefix (variable)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Sub-TLVs (variable)                      |
    +-                                                             -+
    |                             ...                               |

                        OSPFv2 Extended Prefix TLV

Type 🧚 The TLV type. The value is 1 for this TLV type.

Length 📏 Variable, dependent on sub-TLVs.

Route Type 🦋 This is the type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 External Prefix TLV applies to the prefix regardless of the prefix's route type. this is useful when an external entity that doesn't know the route type of the prefix still advertises prefix-specific attributes 🙈. The supported types are:

0 - Unspecified
1 - Intra-Area
3 - Inter-Area
5 - Autonomous System (AS) External
7 - Not-So-Stubby Area (NSSA) External

These route types line up directly with the OSPFv2 LSA types in the "OSPFv2 Link State (LS) Type" registry at <http://www.iana.org/assignments/ospfv2-parameters> 🌸. Specifying any route type that isn't defined will break the correlation with existing OSPFv2 LSAs, and that's beyond the scope of this specification 💀.

Prefix Length 📐 The length of the prefix in bits.

AF 🌈 The address family for the prefix. Right now the only supported value is 0, for IPv4 unicast. Including the address family in this TLV leaves room for future extension ✨.

Flags 🚩 This is a one-octet field holding flags that apply to the prefix. The supported flags are:

0x80 - A-Flag (Attach Flag): An Area Border Router (ABR) generating an OSPFv2 Extended Prefix TLV for an inter-area prefix that is locally connected, or attached in another connected area, SHOULD set this flag 🔥.
0x40 - N-Flag (Node Flag): Set when the prefix identifies the advertising router. In other words, the prefix is a host prefix advertising a globally reachable address, typically tied to a loopback address 🫶. The advertising router MAY choose not to set this flag even when the above conditions are met. If the flag is set and the prefix length is not a host prefix, then the flag MUST be ignored 😭. The flag is preserved when the OSPFv2 Extended Prefix Opaque LSA is propagated between areas ✨.

Address Prefix 🍓 For the IPv4 unicast address family, the prefix itself is encoded as a 32-bit value. The default route is represented by a prefix of length 0. Prefix encoding for other address families is beyond the scope of this specification.

If this TLV is advertised more than once for the same prefix in the same OSPFv2 Extended Prefix Opaque LSA, receiving OSPFv2 routers only use the first instance of the TLV 👀. This situation SHOULD be logged as an error.

If this TLV is advertised more than once for the same prefix in different OSPFv2 Extended Prefix Opaque LSAs originated by the same OSPFv2 router, that router is re-originating LSAs for multiple prefixes and is most likely repacking Extended-Prefix-TLVs into new OSPFv2 Extended Prefix Opaque LSAs 🧺. In this case, receiving OSPFv2 routers use the Extended-Prefix-TLV in the OSPFv2 Extended Prefix Opaque LSA with the smallest Opaque ID. This situation may be logged as a warning 🌟.

It is RECOMMENDED that OSPFv2 routers advertising OSPFv2 Extended Prefix TLVs in different OSPFv2 Extended Prefix Opaque LSAs re-originate these LSAs in ascending order of Opaque ID to minimize the disruption 💜. That's the smooth move, bestie.

If this TLV is advertised more than once for the same prefix in different OSPFv2 Extended Prefix Opaque LSAs originated by different OSPFv2 routers, the application using the information is required to determine which OSPFv2 Extended Prefix Opaque LSA gets used 🧠. For example, the application could prefer the LSA that gives the best path to the prefix.

This document creates a registry for OSPFv2 Extended Prefix sub-TLVs in Section 6 📚.

3. OSPFv2 Extended Link Opaque LSA 🦋

The OSPFv2 Extended Link Opaque LSA is used to advertise additional link attributes 💅. Opaque LSAs are described in [OPAQUE].

This LSA has an area flooding scope 🌸. A single router can advertise multiple OSPFv2 Extended Link Opaque LSAs in an area ✨.

The format of the OSPFv2 Extended Link Opaque LSA 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            LS age             |     Options   |   LS Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Opaque Type  |                   Opaque ID                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Advertising Router                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     LS sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         LS checksum           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                            TLVs                             -+
      |                             ...                               |

                      OSPFv2 Extended Link Opaque LSA

The Opaque Type used by the OSPFv2 Extended Link Opaque LSA is 8 🧚. The LS Type is 10, which tells you the Opaque LSA flooding scope is area-local [OPAQUE]. The Opaque Type is how we tell the different OSPFv2 Opaque LSAs apart, and it's described in Section 3 of [OPAQUE] 🔍. The LSA Length field [OSPFV2] is the total length (in octets) of the Opaque LSA, including the LSA header and all TLVs, padding included 📏.

The Opaque ID field is an arbitrary value used to keep multiple OSPFv2 Extended Prefix Opaque LSAs apart 🫧. For OSPFv2 Extended Link Opaque LSAs, the Opaque ID has no semantic significance beyond telling apart the OSPFv2 Extended Link Opaque LSAs that the same OSPFv2 router originated. If multiple OSPFv2 Extended Link Opaque LSAs include the same link, the attributes from the Opaque LSA with the lowest Opaque ID will be used 🏆.

The format of the TLVs inside the body of the OSPFv2 Extended Link Opaque LSA is the same as what's described in Section 2 💖.

3.1. OSPFv2 Extended Link TLV ✨

The OSPFv2 Extended Link TLV is used to advertise various attributes of a link 🔗. It describes a single link and is built from a set of sub-TLVs. There are no ordering requirements for the sub-TLVs 🙌. Only one OSPFv2 Extended Link TLV SHALL be advertised in each OSPFv2 Extended Link Opaque LSA, which allows for fine-grained changes in the topology 🌈.

The OSPFv2 Extended Link TLV has the following format:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Link Type |                  Reserved                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Link ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Link Data                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sub-TLVs (variable)                      |
      +-                                                             -+
      |                             ...                               |

                         OSPFv2 Extended Link TLV

Type 🧚 The TLV type. The value is 1 for this TLV type.

Length 📏 Variable, dependent on sub-TLVs.

Link Type 🛣️ Link Type is defined in Section A.4.2 of [OSPFV2] and in the "OSPFv2 Router LSA Link Type (Value 1)" registry at <http://www.iana.org/assignments/ospfv2-parameters>. Specifying link types that aren't defined will break the correlation with existing OSPFv2 Router-LSA links, and that's beyond the scope of this specification 💀.

Link ID 🪪 Link ID is defined in Section A.4.2 of [OSPFV2].

Link Data 📦 Link Data is defined in Section A.4.2 of [OSPFV2].

If this TLV is advertised more than once in the same OSPFv2 Extended Link Opaque LSA, receiving OSPFv2 routers only use the first instance of the TLV 👀. This situation SHOULD be logged as an error.

If this TLV is advertised more than once for the same link in different OSPFv2 Extended Link Opaque LSAs originated by the same OSPFv2 router, receiving OSPFv2 routers use the OSPFv2 Extended Link TLV in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID. This situation may be logged as a warning 🌟.

It is RECOMMENDED that OSPFv2 routers advertising OSPFv2 Extended Link TLVs in different OSPFv2 Extended Link Opaque LSAs re-originate these LSAs in ascending order of Opaque ID to minimize the disruption 💜.

This document creates a registry for OSPFv2 Extended Link sub-TLVs in Section 6 📚.

4. Backward Compatibility ✨

Since Opaque OSPFv2 LSAs are optional and backward compatible [OPAQUE], the extensions described here are fully backward compatible 🫶. However, future OSPFv2 applications that use these extensions MUST address backward compatibility for the corresponding functionality 🙈. that part is on them, bestie 💅.

5. Security Considerations 🔐

Okay so bestie, this part is SERIOUS but I'm still gonna hype it up 💅. In general, the new LSAs defined in this document have the same security concerns as the ones in [OSPFV2] and [OPAQUE]. No new drama, just the same vibes. 🫶

OSPFv2 applications that use these extensions MUST define the security considerations for those applications in the specs for those applications. So if you're building on top of this, you own your own security section, periodt 🎀.

Now the really important part 😭. Implementations MUST make sure that malformed TLV and sub-TLV combos get detected, and that they do NOT give attackers a way to crash the OSPFv2 router or routing process. Not a crash, not even a little one 💀.

Also, malformed LSAs MUST NOT be stored in the Link State Database (LSDB), acknowledged, or reflooded. Like, absolutely not. Bin it 🗑️. Reception of malformed LSAs SHOULD be counted and/or logged for further analysis, so you can actually see what's going on 👀.

Quick definition so nobody gets confused 🧠: a malformed LSA is one that can't be parsed because a TLV or sub-TLV runs past the end of the thing that contains it (the LSA, TLV, or sub-TLV), OR there's leftover data to parse but it's smaller than a TLV header. Yikes, no thank you 🙅‍♀️.

6. IANA Considerations 📋

Okay, IANA era ✨. This specification updates the "Opaque Link-State Advertisements (LSA) Option Types" registry with these values:

7 - OSPFv2 Extended Prefix Opaque LSA
8 - OSPFv2 Extended Link Opaque LSA

This spec also creates five brand new registries 🌈:

OSPFv2 Extended Prefix Opaque LSA TLVs
OSPFv2 Extended Prefix TLV Sub-TLVs
OSPFv2 Extended Prefix TLV Flags
OSPFv2 Extended Link Opaque LSA TLVs
OSPFv2 Extended Link TLV Sub-TLVs

6.1. OSPFv2 Extended Prefix Opaque LSA TLVs Registry 🦋

The "OSPFv2 Extend Prefix Opaque LSA TLVs" registry defines the top-level TLVs for OSPFv2 Extended Prefix Opaque LSAs. It has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval [RFC5226]. Lowkey very organized 🍓.

These initial values have been allocated:

0 - Reserved
1 - OSPFv2 Extended Prefix TLV

Types in the range 32768-33023 are for Experimental Use. These will NOT be registered with IANA and MUST NOT be mentioned by RFCs. Experimental vibes only 🧪.

Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that covers the IANA considerations for the range being assigned. No shortcuts, bestie 🚫.

6.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry 🧚

The "OSPFv2 Extended Prefix TLV Sub-TLVs" registry defines sub-TLVs at any level of nesting for OSPFv2 Extended Prefix TLVs. It has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.

The only initial value allocated is:

0 - Reserved

Types in the range 32768-33023 are for Experimental Use. These will NOT be registered with IANA and MUST NOT be mentioned by RFCs. 🧪💜

6.3. OSPFv2 Extended Prefix TLV Flags Registry 🎀

The "OSPFv2 Extended Prefix TLV Flags" registry defines the bits in the 8-bit OSPFv2 Extended Prefix TLV Flags (Section 2.1). This spec defines the A (0x80) and N (0x40) bits. It has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval. Flag it, don't bag it 🚩.

6.4. OSPFv2 Extended Link Opaque LSA TLVs Registry 🌸

The "OSPFv2 Extended Link Opaque LSA TLVs" registry defines the top-level TLVs for OSPFv2 Extended Link Opaque LSAs. It has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.

These initial values have been allocated:

0 - Reserved
1 - OSPFv2 Extended Link TLV

Types in the range 32768-33023 are for Experimental Use. These will NOT be registered with IANA and MUST NOT be mentioned by RFCs.

6.5. OSPFv2 Extended Link TLV Sub-TLVs Registry 🦄

The "OSPFv2 Extended Link TLV Sub-TLVs" registry defines sub-TLVs at any level of nesting for OSPFv2 Extended Link TLVs. It has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.

The only initial value allocated is:

0 - Reserved

Types in the range 32768-33023 are for Experimental Use. These will NOT be registered with IANA and MUST NOT be mentioned by RFCs.

7. References 📚

7.1. Normative References 💖

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[OPAQUE]   Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
           OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
           July 2008, <http://www.rfc-editor.org/info/rfc5250>.

[OSPFV2]   Moy, J., "OSPF Version 2", STD 54, RFC 2328,
           DOI 10.17487/RFC2328, April 1998,
           <http://www.rfc-editor.org/info/rfc2328>.

[TE]       Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
           (TE) Extensions to OSPF Version 2", RFC 3630,
           DOI 10.17487/RFC3630, September 2003,
           <http://www.rfc-editor.org/info/rfc3630>.

7.2. Informative References 🌈

[OSPFv3-EXTEND]
           Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
           LSA Extendibility", Work in Progress, draft-ietf-ospf-
           ospfv3-lsa-extend-08, October 2015.

[RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
           RFC 3101, DOI 10.17487/RFC3101, January 2003,
           <http://www.rfc-editor.org/info/rfc3101>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[SEGMENT-ROUTING]
           Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
           Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
           Extensions for Segment Routing", Work in Progress,
           draft-ietf-ospf-segment-routing-extensions-05, June 2015.

Acknowledgements 🫶

We would like to thank Anton Smirnov for his contribution.

Thanks to Tony Przygienda for his review and comments.

Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, Shraddha Hegde, and Csaba Mate for their responses to the implementation survey.

Thanks to Tom Petch and Chris Bowers for review and comments.

Thanks to Alia Atlas and Alvaro Retana for their AD review and comments.

Thanks to Carlos Pignataro and Ron Bonica for Operations Directorate review and comments.

Thanks to Suresh Krishnan for the Gen-ART review and comments.

Thanks to Ben Campbell, Kathleen Moriarty, and Barry Leiba for IESG review and comments.

Authors' Addresses 💌

Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
Bratislava, 821 09
Slovakia
Email: ppsenak@cisco.com


Hannes Gredler
Independent
Email: hannes@gredler.at


Rob Shakir
Jive Communications, Inc.
1275 W 1600 N, Suite 100
Orem, UT  84057
United States
Email: rjs@rob.sh


Wim Henderickx
Alcatel-Lucent
Copernicuslaan
Antwerp, 2018  94089
Belgium
Email: wim.henderickx@alcatel-lucent.com


Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA  95134
United States
Email: jeff.tantsura@ericsson.com


Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC  27513
United States
Email: acee@cisco.com

📦 where this page comes from

ietf: rfc7684 2015-11
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms