RFC 9513

OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)

📅 published December 2023, from ietf

OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) 🦋

  • Series: Internet Engineering Task Force (IETF)
  • RFC number: 9513
  • Authors: Z. Li and Z. Hu from Huawei Technologies, plus K. Talaulikar (Ed.) and P. Psenak from Cisco Systems 🌸
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: December 2023
  • Obsoletes / Updates: nothing is listed in this RFC's header, so it doesn't obsolete or update any earlier document. ✨

Abstract ✨

Okay bestie, so the Segment Routing (SR) architecture lets you define an end-to-end path really flexibly 💅 You encode the path as a sequence of topological elements called segments, and it can run on either an MPLS or an IPv6 data plane. This document is all about the OSPFv3 extensions you need to get SR working over the IPv6 data plane 🫶

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 went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9513 🔗

Copyright (c) 2023 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🌈

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  SRv6 Capabilities TLV
3.  Advertisement of Supported Algorithms
4.  Advertisement of Maximum SRv6 SID Depths
  4.1.  Maximum Segments Left MSD Type
  4.2.  Maximum End Pop MSD Type
  4.3.  Maximum H.Encaps MSD Type
  4.4.  Maximum End D MSD Type
5.  SRv6 SIDs and Reachability
  5.1.  SRv6 Flexible Algorithm
6.  Advertisement of Anycast Property
7.  SRv6 Locator LSA
  7.1.  SRv6 Locator TLV
  7.2.  SRv6 Locator Sub-TLVs
8.  Advertisement of SRv6 End SIDs
9.  Advertisement of SRv6 SIDs Associated with Adjacencies
  9.1.  SRv6 End.X SID Sub-TLV
  9.2.  SRv6 LAN End.X SID Sub-TLV
10. SRv6 SID Structure Sub-TLV
11. Advertising Endpoint Behaviors
12. Security Considerations
13. IANA Considerations
  13.1.  OSPF Router Information TLVs
  13.2.  OSPFv3 LSA Function Codes
  13.3.  OSPFv3 Prefix Options
  13.4.  OSPFv3 SRv6 Capabilities TLV Flags
  13.5.  OSPFv3 SRv6 End SID Sub-TLV Flags
  13.6.  OSPFv3 SRv6 Adjacency SID Sub-TLV Flags
  13.7.  OSPFv3 Extended-LSA Sub-TLVs
  13.8.  OSPFv3 SRv6 Locator LSA TLVs
  13.9.  OSPFv3 SRv6 Locator LSA Sub-TLVs
  13.10. OSPFv3 Extended-LSA Sub-TLVs
14. References
  14.1.  Normative References
  14.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Let's start with the basics. The Segment Routing (SR) architecture [RFC8402] describes how a node can steer a packet using an ordered list of instructions called segments. Each segment is identified by a Segment Identifier (SID) 🦋

SR can run on the IPv6 data plane by using the Segment Routing Header (SRH) defined in [RFC8754]. Running SR on IPv6 is called SRv6 💖

The network programming model for SRv6 is in [RFC8986]. It explains how any behavior can be attached to a SID, and how any network program can be built out of a combination of SIDs. It also covers several well-known behaviors you can attach to SRv6 SIDs 🌸

This document defines OSPFv3 extensions that support SRv6 capabilities, as set out in [RFC8986], [RFC8754], and [RFC9259]. The extensions let an OSPFv3 router advertise its SRv6 capabilities, its SRv6 Locators, and its required SRv6 SIDs, along with the Endpoint behaviors each one supports. You need to be familiar with [RFC8986] to understand what this document specifies 🧠

At a high level, the OSPFv3 extensions are made up of the following:

  1. An SRv6 Capabilities TLV that advertises the SRv6 features and SRH operations an OSPFv3 router supports.
  2. Several sub-TLVs that advertise the various SRv6 Maximum SID Depths.
  3. An SRv6 Locator TLV, carried in an SRv6 Locator Link State Advertisement (LSA), that advertises the SRv6 Locator. Think of it as a summary address for the IGP algorithm-specific SIDs instantiated on an OSPFv3 router 🎀
  4. TLVs and sub-TLVs that advertise the SRv6 SIDs instantiated on an OSPFv3 router, together with their Endpoint behaviors 👑

1.1. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🫶

2. SRv6 Capabilities TLV 🌈

The SRv6 Capabilities TLV is how an OSPFv3 router advertises that it supports the SR Segment Endpoint Node [RFC8754] functionality, along with its SRv6-related capabilities. It's an optional top-level TLV of the OSPFv3 Router Information LSA [RFC7770], and it MUST be advertised by an SRv6-enabled router 💖

This TLV MUST be advertised only once in the OSPFv3 Router Information LSA. If a receiver gets multiple SRv6 Capabilities TLVs from one router, it MUST use the first occurrence of the TLV in the OSPFv3 Router Information LSA. If the SRv6 Capabilities TLV shows up in multiple OSPFv3 Router Information LSAs that have different flooding scopes, the TLV in the LSA with the area-scoped flooding scope MUST be used. If it shows up in multiple OSPFv3 Router Information LSAs with the same flooding scope, the TLV in the LSA with the numerically smallest Link State ID MUST be used, and subsequent instances of the TLV MUST be ignored 🔥

The OSPFv3 Router Information LSA can be advertised at any of the defined flooding scopes (link, area, or Autonomous System (AS)). For SRv6 Capabilities TLV advertisement, area-scoped flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL 🦋

Here's the format of the OSPFv3 SRv6 Capabilities TLV:

   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               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Flags             |            Reserved           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Sub-TLVs...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: SRv6 Capabilities TLV

Here's what each field means 🧚

  • Type: a 2-octet field. The value for this type is 20.
  • Length: a 2-octet field. It's the total length (in octets) of the value portion of the TLV, including nested sub-TLVs.
  • Reserved: a 2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
  • Flags: a 2-octet field. The flags are laid out like this:
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | |O|                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • O-flag: if set, the router can support the O-flag in the SRH flags, as specified in [RFC9259] ✨
  • Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt 💀

The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs are defined in this specification 🌸

3. Advertisement of Supported Algorithms 🍓

An SRv6-enabled OSPFv3 router advertises its algorithm support using the SR-Algorithm TLV defined in [RFC8665], as described in [RFC8666] 🫶

4. Advertisement of Maximum SRv6 SID Depths 🎀

An SRv6-enabled router can have different capabilities and limits related to SRH processing. Those need to be advertised to the other OSPFv3 routers in the SRv6 domain 👑

[RFC8476] defines how to advertise node- and link-specific values for Maximum SID Depth (MSD) types. Node MSDs go in the Node MSD TLV in the OSPFv3 Router Information LSA [RFC7770], while Link MSDs go in the Link MSD sub-TLV of the Router-Link TLV [RFC8362]. The format of the MSD types for OSPFv3 is defined in [RFC8476] 🦋

The SRv6 MSD types defined in Section 4 of [RFC9352] for IS-IS are also used by OSPFv3. These MSD types are allocated in the "IGP MSD-Types" registry, which IANA maintains, and IS-IS and OSPF share that registry. They're described in the subsections below 🌈

4.1. Maximum Segments Left MSD Type 💖

The Maximum Segments Left MSD Type signals the maximum value of the Segments Left field of the SRH of a received packet before the Endpoint behavior associated with a SID is applied. If no value is advertised, the supported value is assumed to be 0 🧠

4.2. Maximum End Pop MSD Type 🔥

The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to which the router can apply "Penultimate Segment Pop (PSP) of the SRH" or "Ultimate Segment Pop (USP) of the SRH". Both are flavors defined in [RFC8986]. If the advertised value is zero, or no value is advertised, the router cannot apply the PSP or USP flavors 💅

4.3. Maximum H.Encaps MSD Type ✨

The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be added as part of the H.Encaps behavior defined in [RFC8986]. If the advertised value is zero, or no value is advertised, the headend can apply an SR Policy that contains only one segment, without inserting any SRH. A non-zero SRH Max H.Encaps MSD means the headend can insert an SRH with SIDs up to the advertised value 🦋

4.4. Maximum End D MSD Type 🌸

The Maximum End D MSD Type specifies the maximum number of SIDs present in an SRH when performing decapsulation. These include, but aren't limited to, End.DX6, End.DT4, End.DT46, End with USD, and End.X with USD, all defined in [RFC8986]. If the advertised value is zero, or no value is advertised, the router cannot apply any behavior that results in decapsulation and forwarding of the inner packet when the outer IPv6 header contains an SRH 🙈

5. SRv6 SIDs and Reachability ✨

okay so an SRv6 SID is 128 bits 💖 and it's split into locator, function, and argument parts, as described in [RFC8986]. no cap, this is the foundation 🧚

every OSPFv3 router gets provisioned with algorithm-specific locators, one for each algorithm that router supports 🌸 each locator is a covering prefix for all the SIDs provisioned on that router with the matching algorithm. so the locator is like the big umbrella over the little SIDs underneath ☂️

Locators MUST be advertised within an SRv6 Locator TLV (see Section 7.1) using an SRv6 Locator LSA (see Section 7). the SRv6 Locator LSA exists instead of just reusing the Extended Prefix LSAs [RFC8362], and that's on purpose 🦋 it keeps two kinds of reachability advertisements clearly separate: the base OSPFv3 prefix reachability ones, and the SRv6 Locator reachability ones. iconic separation of concerns, honestly 👑

Forwarding entries for the locators advertised in the SRv6 Locator TLV MUST be installed in the forwarding plane of receiving SRv6-capable routers when the associated algorithm is supported by the receiving OSPFv3 router. locators can be of different route types that map onto existing OSPFv3 LSA types: Intra-Area, Inter-Area, External, and Not-So-Stubby Area (NSSA) 🍓 the advertisement and propagation of SRv6 Locator LSAs also follow the OSPFv3 [RFC5340] specifications for each respective LSA type. same goes for processing the prefix in the SRv6 Locator TLV, working out its reachability, and installing it in the forwarding plane. all of that follows the OSPFv3 [RFC5340] specs for the matching LSA type. it's giving consistency ✨

Locators associated with algorithms 0 and 1 (refer to Section 3.1.1 of [RFC8402]) SHOULD also be advertised using Extended LSA types with extended TLVs [RFC8362], so routers that don't support SRv6 will still install a forwarding entry for SRv6 traffic matching those locators 🫶 when operating in Extended LSA sparse-mode [RFC8362], these locators SHOULD also be advertised using Legacy LSAs [RFC5340] too.

When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs and/or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST be considered a prefix associated with the router. the referenced LSA type MUST point to the Router LSA of the advertising router, as specified in Section 4.4.3.9 of [RFC5340] 💅

now the tea ☕ if a locator shows up both as a prefix reachability advertisement (through Legacy LSAs and/or Extended Prefix TLVs in Extended LSAs) AND in an SRv6 Locator TLV, the prefix reachability advertisement MUST be preferred over the SRv6 Locator TLV one when installing forwarding entries. this stops SRv6-capable and SRv6-incapable OSPFv3 routers from ending up with inconsistent forwarding entries 🔥 and that preference only applies to the forwarding decision. it has zero impact on the rest of the data in the SRv6 Locator TLV, so it's not canceling everything, just that one thing 🙈

SRv6 SIDs get advertised as sub-TLVs in the SRv6 Locator TLV, EXCEPT for SRv6 End.X SIDs and LAN End.X SIDs. those are tied to a specific neighbor or link, so they get advertised as sub-TLVs of the E-Router-Link TLV instead 🎀

SRv6 SIDs received from other OSPFv3 routers are not directly routable, and they MUST NOT be installed in the forwarding plane 🙅‍♀️ reachability to an SRv6 SID depends on there being a covering locator. no locator, no route, periodt 💀

following the rules in this section makes sure SRv6 SIDs tied to a supported algorithm get forwarded correctly, while SRv6 SIDs tied to an unsupported algorithm get dropped 💖

NOTE: The drop behavior depends on the absence of a default/summary route matching the locator prefix.

if the locator associated with SRv6 SID advertisements is the longest prefix match installed in the forwarding plane for those SIDs, that's what guarantees correct forwarding ✨ network operators should take steps to make sure this requirement doesn't get compromised. for example, these situations should be avoided:

  • another locator tied to a different algorithm ends up being the longest prefix match 🙈
  • another prefix advertised via a Legacy or Extended LSA advertisement ends up being the longest prefix match 💀

5.1. SRv6 Flexible Algorithm

[RFC9350] specifies IGP Flexible Algorithm mechanisms for OSPFv3 🧚 Section 14.2 of [RFC9350] explains SRv6 forwarding for Flexible Algorithms, and analogous procedures apply for supporting SRv6 Flexible Algorithms using OSPFv3. so when the algorithm value advertised in the SRv6 Locator TLV (refer to Section 7.1) represents a Flexible Algorithm, the procedures in Section 14.2 of [RFC9350] are followed for programming those specific SRv6 Locators 🦋

Locators associated with Flexible Algorithms SHOULD NOT be advertised in the base OSPFv3 prefix reachability advertisements. the reason is kinda obvious: advertising the Flexible Algorithm locator in a regular prefix reachability advertisement would make it available for non-Flexible Algorithm forwarding, which is algorithm 0 😭 keep your algos separated, bestie

The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as specified in [RFC9350], also apply to SRv6. those procedures cover a) ASBR reachability, b) inter-area, external, and NSSA prefix advertisements, and c) how those prefix advertisements get used in Flexible Algorithm route computation 💅

6. Advertisement of Anycast Property

okay anycast time 🌈 both prefixes and SRv6 Locators can be configured as anycast, which means the same value can be advertised by multiple routers at once. so other routers need a way to know that an advertisement is for an anycast identifier. that's where the AC-bit comes in 🫶

the AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property:

                      0  1  2  3  4  5  6  7
                     +--+--+--+--+--+--+--+--+
                     |AC|EL| N|DN| P| x|LA|NU|
                     +--+--+--+--+--+--+--+--+

Figure 2: OSPFv3 Prefix Options Field

when the prefix or SRv6 Locator is configured as anycast, the AC-bit MUST be set. otherwise, this flag MUST be clear 🎀

the AC-bit MUST be preserved when re-advertising the prefix or SRv6 Locator across areas 🦋

the AC-bit and the N-bit MUST NOT both be set. if both the N-bit and AC-bit are set in the prefix or SRv6 Locator advertisement, the receiving routers MUST ignore the N-bit 🙈 AC wins, that's the tea

the same prefix or SRv6 Locator can be advertised by multiple routers. if at least one of them sets the AC-bit in its advertisement, the prefix or SRv6 Locator is considered anycast ✨

a prefix or SRv6 Locator that's advertised by a single node and has no AC-bit is considered node-specific 🌸

all the nodes advertising the same anycast SRv6 Locator MUST instantiate the exact same set of SIDs under that anycast SRv6 Locator. if they don't, traffic may get dropped or misrouted 😭 this one is serious, not a vibe check

the PrefixOptions field is common to prefix reachability advertisements (the base OSPFv3 prefix LSA types defined in [RFC5340], and the OSPFv3 Extended Prefix TLV types defined in [RFC8362]) and to the SRv6 Locator TLV advertisements specified in Section 7.1 of this document 🧚 when a router originates both the prefix reachability advertisement and the SRv6 Locator advertisement for a given prefix, the router SHOULD advertise the same PrefixOptions bits in both. if the PrefixOptions advertised in the SRv6 Locator and in the prefix reachability advertisements are inconsistent, the ones in the prefix reachability advertisement MUST be preferred 💖

7. SRv6 Locator LSA

the SRv6 Locator LSA has a function code of 42 🔥 the S1/S2 bits depend on the flooding scope you want for the LSA. the flooding scope of the SRv6 Locator LSA depends on the scope of the advertised SRv6 Locator, and the advertising router controls it. the U-bit will be set to say the LSA should be flooded even if it's not understood 🫶

multiple SRv6 Locator LSAs can be advertised by one OSPFv3 router, and they're told apart by their Link State IDs. the originating router picks those IDs arbitrarily 🌈

here's what the SRv6 Locator LSA looks like 👀

     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             |U|S12|   Function Code         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Link State ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Advertising Router                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       LS sequence number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        LS checksum            |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-                            TLVs                             -+
    |                             ...                               |

Figure 3: SRv6 Locator LSA

the TLVs in the body of the SRv6 Locator LSA use the same format as [RFC3630] 🍓 the variable TLV section holds one or more nested TLV tuples. nested TLVs are also called sub-TLVs. 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...                           |
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: SRv6 Locator LSA 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 isn't counted in 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 the Length field set to 1, and 3 octets of padding get added to the end of the value portion. the padding is made of zeros 🫧

Okay bestie, picking up right where we left off 💅✨

7.1. SRv6 Locator TLV 🎀

okay so the SRv6 Locator TLV is a top-level TLV inside the SRv6 Locator LSA, and its whole job is to advertise an SRv6 Locator, its attributes, and the SIDs that live under it 🦋 You're allowed to MAY-stuff multiple SRv6 Locator TLVs into one SRv6 Locator LSA, MAY being the vibe here, but since the S12 bits control the flooding scope, the LSA's flooding scope has to work for every locator packed inside it 🫶

Now the dupe situation, which is kinda iconic lowkey. If a receiver gets multiple SRv6 Locator TLVs from the same router for the same locator, it MUST use the first occurrence in the LSA 💜 If that same locator shows up in SRv6 Locator LSAs with different flooding scopes, the one in the area-scoped LSA MUST be used 🌸 And if the scopes match, the TLV in the LSA with the numerically smallest Link State ID MUST be used, and every later instance MUST be ignored 💀 Main character energy for the smallest Link State ID, no cap ✨

Here's the layout 👇

    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   |  Algorithm    | Locator Length| PrefixOptions |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Locator (up to 16 octets) ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... Locator continued ...                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... Locator continued ...                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... Locator concluded                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sub-TLVs (variable)                      |
   +-                                                             -+
   |                             ...                               |

                       Figure 5: SRv6 Locator TLV

Here's the breakdown of each field, bestie 🧚

  • Type is 2 octets, and the value for this type is 1 🍓
  • Length is 2 octets and counts the value portion of the TLV, nested sub-TLVs included 🌈
  • Route Type is 1 octet and says what kind of locator route it is. The only supported types are the ones below, and the SRv6 Locator TLV MUST be ignored on receipt of any other type 🙈
    • 1: Intra-Area
    • 2: Inter-Area
    • 3: AS External Type 1
    • 4: AS External Type 2
    • 5: NSSA External Type 1
    • 6: NSSA External Type 2
  • Algorithm is 1 octet and is the algorithm tied to the locator. The values live in the "IGP Algorithm Types" registry [RFC8665] 🔥
  • Locator Length is 1 octet and gives the locator prefix length as a number of bits from the range (1-128) ✨
  • PrefixOptions is 1 octet of prefix option bits/flags, as defined in [RFC5340] and extended by [RFC8362] and Section 6 of this document 💜
  • Metric is 4 octets. The value 0xFFFFFFFF MUST be considered as unreachable 💀
  • Locator is 1-16 octets and encodes the advertised SRv6 Locator as an IPv6 Prefix, as specified in Appendix A.4.1 of [RFC5340] 🦋
  • Sub-TLVs carry extra attributes for the locator and the SRv6 SIDs attached to it 🫶

7.2. SRv6 Locator Sub-TLVs 🌸

these OSPFv3 Extended-LSA sub-TLVs that belong to the Extended Prefix LSAs are also fair game as sub-TLVs of the SRv6 Locator TLV, using the code points from Section 13.9 🎀

  • IPv6-Forwarding-Address sub-TLV [RFC8362] 💖
  • Route-Tag sub-TLV [RFC8362] 💖
  • Prefix Source OSPF Router-ID sub-TLV [RFC9084] 💖
  • Prefix Source Router Address sub-TLV [RFC9084] 💖

8. Advertisement of SRv6 End SIDs 🧚‍♀️

okay so the SRv6 End SID sub-TLV is a sub-TLV of the SRv6 Locator TLV inside the SRv6 Locator LSA (defined in Section 7) 💅 It advertises the SRv6 SIDs that belong to the router, along with their Endpoint behaviors. SIDs tied to adjacencies get advertised as described in Section 9 🦋

Every SRv6-enabled OSPFv3 router SHOULD advertise at least one SRv6 SID with an End behavior for itself, as specified in [RFC8986] 🌈 It MAY skip that if the node isn't going to be used as a Segment Endpoint by any SR Source Node (for example, for TE or Topology Independent Loop-Free Alternate (TI-LFA)) 🙈

SRv6 End SIDs inherit the algorithm from their parent locator 🍓 The SRv6 End SID MUST be allocated from its associated locator. SRv6 End SIDs NOT allocated from the associated locator MUST be ignored. Not me doing the bare minimum on this one 💀

The router MAY advertise multiple instances of the SRv6 End SID sub-TLV inside the SRv6 Locator TLV, one for each SRv6 SID being advertised ✨ If a receiver gets multiple SRv6 End SID sub-TLVs from a given router for the same SRv6 SID value, it MUST use the first occurrence of the sub-TLV in the SRv6 Locator TLV 💜

Here's the 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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |   Reserved    |        Endpoint Behavior      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SID (128 bits) ...                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... SID continued ...                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... SID continued ...                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... SID concluded                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Sub-TLVs (variable) . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: SRv6 End SID Sub-TLV

The fields, bestie 🧚

  • Type is 2 octets, and the value for this type is 1 🍓
  • Length is 2 octets and counts the value portion of the sub-TLV, including its nested sub-TLVs 🌈
  • Flags is 1 octet of flags for the SID. No flags are currently defined, so this field MUST be set to 0 on transmission and MUST be ignored on receipt 💅
  • Reserved is 1 octet. It MUST be set to 0 on transmission and MUST be ignored on receipt 🫶
  • Endpoint Behavior is 2 octets and holds the Endpoint behavior code point for this SRv6 SID, as defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 11 of this document. Unsupported or unrecognized behavior values are ignored by the receiver 🙈
  • SID is 16 octets and encodes the advertised SRv6 SID 🦋
  • Sub-TLVs carry extra attributes for the given SRv6 SID 🌸

9. Advertisement of SRv6 SIDs Associated with Adjacencies 🎀

the SRv6 Endpoint behaviors in [RFC8986] include some that are specific to links or adjacencies. The most basic one (and critical for link-state routing protocols like OSPFv3) is End.X, which tells the router to forward to a specific neighbor over a specific link 🔥 These SIDs, plus the others in [RFC8986] that are link- or adjacency-specific, need to be advertised to OSPFv3 routers within an area so SRv6 traffic can be steered over a particular link or adjacency 💜

So SRv6 SIDs that are specific to a particular neighbor (like End.X) are NOT advertised as sub-TLVs of the SRv6 Locator TLV. Instead they go in two optional sub-TLVs of the E-Router-Link TLV defined in [RFC8362] 🧚

  • SRv6 End.X SID sub-TLV: used for OSPFv3 adjacencies over point-to-point or point-to-multipoint links, and for the adjacency to the Designated Router (DR) over broadcast and Non-Broadcast-Multi-Access (NBMA) links 🦋
  • SRv6 LAN End.X SID sub-TLV: used for OSPFv3 adjacencies on broadcast and NBMA links to the Backup DR and DR-Other neighbors. This sub-TLV includes the OSPFv3 Router-ID of the neighbor, so you get one instance per neighbor explicitly advertised as a sub-TLV of the E-Router-Link TLV for the same link 🌈

Every SRv6-enabled OSPFv3 router SHOULD instantiate at least one unique SRv6 End.X SID for each of its neighbors 💖 It MAY skip that if features like TE or TI-LFA (which need End.X SIDs) aren't in use 🙈 A router MAY instantiate more than one SRv6 End.X SID for a single neighbor, and the same SRv6 End.X SID MAY be advertised for more than one neighbor 🫶 So multiple instances of the SRv6 End.X and SRv6 LAN End.X SID sub-TLVs MAY be advertised within the E-Router-Link TLV for a single link ✨

All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a locator with the matching algorithm that's advertised by the same OSPFv3 router in an SRv6 Locator TLV. End.X SIDs that don't meet this MUST be ignored 💀 This makes sure the router advertising the End.X or LAN End.X SID is also advertising its corresponding locator with the algorithm that will be used to compute paths to the SID 👑

9.1. SRv6 End.X SID Sub-TLV ✨

okay bestie, here's the layout for the SRv6 End.X SID sub-TLV 🎀 it's giving neat rows of bits, so let's look at it first 👀

   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               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Endpoint Behavior      |     Flags     |   Reserved1   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Algorithm   |    Weight     |           Reserved2           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   SID (128 bits) ...                                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID continued ...                                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID continued ...                                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID concluded                                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Sub-TLVs (variable) . . .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: SRv6 End.X SID Sub-TLV

here's what each bit of the vibe means 💅

Type: 2-octet field. The value for this type is 31.

Length: 2-octet field. The total length (in octets) of the value portion of the sub-TLV, including its nested sub-TLVs.

Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID as defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 11 of this document. Unsupported or unrecognized behavior values are ignored by the receiver.

Flags: 1-octet field. The flags look like this 🦋

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
  • B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection.
  • S-Flag: Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
  • P-Flag: Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap.

Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt. no wiggle room there 🙅‍♀️

Reserved1: 1-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.

Algorithm: 1-octet field. The algorithm associated with the SRv6 Locator from which the SID is allocated. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665].

Weight: 1-octet field. Its value represents the weight of the End.X SID for load-balancing. The use of the weight is defined in [RFC8402].

Reserved2: 2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.

SID: 16-octet field. This field encodes the advertised SRv6 SID.

Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the given SRv6 End.X SID.

9.2. SRv6 LAN End.X SID Sub-TLV 🌈

next up is the SRv6 LAN End.X SID sub-TLV, which is basically the same energy with one extra field for the neighbor 🫶 here's the layout:

   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               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Endpoint Behavior        |     Flags     |   Reserved1   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Algorithm   |    Weight     |           Reserved2           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Neighbor Router-ID                                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   SID (128 bits) ...                                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID continued ...                                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID continued ...                                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ... SID concluded                                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Sub-TLVs (variable) . . .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 8: SRv6 LAN End.X SID Sub-TLV

the fields, bestie 💖

Type: 2-octet field. The value for this type is 32.

Length: 2-octet field. The total length (in octets) of the value portion of the sub-TLV, including its nested sub-TLVs.

Endpoint Behavior: 2-octet field. The code point for the Endpoint behavior for this SRv6 SID as defined in Section 9.2 of [RFC8986].

Flags: 1-octet field. The flags are defined as follows:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
  • B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection.
  • S-Flag: Set Flag. When set, the S-Flag indicates that the End.X SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
  • P-Flag: Persistent Flag. If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap.

Other flags are not defined and are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt. same rule as before, no exceptions 🙈

Reserved1: 1-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.

Algorithm: 1-octet field. The algorithm associated with the SRv6 Locator from which the SID is allocated. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665].

Weight: 1-octet field. Its value represents the weight of the End.X SID for load balancing. The use of the weight is defined in [RFC8402].

Reserved2: 2-octet field. It MUST be set to 0 on transmission and MUST be ignored on receipt.

Neighbor Router-ID: 4-octet field. It specifies the OSPFv3 Router-ID of the neighbor.

SID: 16-octet field. This field encodes the advertised SRv6 SID.

Sub-TLVs: Used to advertise sub-TLVs that provide additional attributes for the given SRv6 SID.

10. SRv6 SID Structure Sub-TLV 🧚

the SRv6 SID Structure sub-TLV is how you advertise the structure of an SRv6 SID as defined in [RFC8986] 🍓 it's an optional sub-TLV for these three parents:

  • SRv6 End SID sub-TLV (refer to Section 8)
  • SRv6 End.X SID sub-TLV (refer to Section 9.1)
  • SRv6 LAN End.X SID sub-TLV (refer to Section 9.2)

here's the 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               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 9: SRv6 SID Structure Sub-TLV

where:

Type: 2-octet field. The value for this type is 30.

Length: 2-octet field. The value MUST be 4.

LB Length: 1-octet field. SRv6 SID Locator Block length in bits.

LN Length: 1-octet field. SRv6 SID Locator Node length in bits.

Function Length: 1-octet field. SRv6 SID Function length in bits.

Argument Length: 1-octet field. SRv6 SID Argument length in bits.

The SRv6 SID Structure sub-TLV MUST NOT appear more than once in its parent sub-TLV. If it appears more than once in its parent sub-TLV, the parent sub-TLV MUST be ignored by the receiver.

The sum of all four sizes advertised in SRv6 SID Structure sub-TLV MUST be less than or equal to 128 bits. If the sum of all four sizes advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits, the parent TLV or sub-TLV MUST be ignored by the receiver. 🚫 too big, bye

The SRv6 SID Structure sub-TLV is intended for informational use by the control and management planes. It MUST NOT be used at a transit node (as defined in [RFC8754]) for forwarding packets. As an example, this information could be used for the following:

  • Validation of SRv6 SIDs being instantiated in the network and advertised via OSPFv3. These can be learned by controllers via BGP-LS [RFC9514] and then monitored for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986].
  • Verification and the automation for securing the SRv6 domain by provisioning filtering rules at SR domain boundaries as described in Section 5 of [RFC8754].

The details of these potential applications are outside the scope of this document.

11. Advertising Endpoint Behaviors 🦋

Endpoint behaviors are defined in [RFC8986]. The code points for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry of [RFC8986]. This section lists the Endpoint behaviors and their code points, which MAY be advertised by OSPFv3 and the sub-TLVs in which each type MAY appear.

 +===================+===================+=====+=======+===========+
 | Endpoint Behavior | Endpoint Behavior | End | End.X | LAN End.X |
 |                   | Code Point        | SID | SID   | SID       |
 +===================+===================+=====+=======+===========+
 | End (PSP, USP,    | 1-4, 28-31        | Y   | N     | N         |
 | USD)              |                   |     |       |           |
 +-------------------+-------------------+-----+-------+-----------+
 | End.X (PSP, USP,  | 5-8, 32-35        | N   | Y     | Y         |
 | USD)              |                   |     |       |           |
 +-------------------+-------------------+-----+-------+-----------+
 | End.DX6           | 16                | N   | Y     | Y         |
 +-------------------+-------------------+-----+-------+-----------+
 | End.DX4           | 17                | N   | Y     | Y         |
 +-------------------+-------------------+-----+-------+-----------+
 | End.DT6           | 18                | Y   | N     | N         |
 +-------------------+-------------------+-----+-------+-----------+
 | End.DT4           | 19                | Y   | N     | N         |
 +-------------------+-------------------+-----+-------+-----------+
 | End.DT64          | 20                | Y   | N     | N         |
 +-------------------+-------------------+-----+-------+-----------+

              Table 1: SRv6 Endpoint Behaviors in OSPFv3

12. Security Considerations 🔐

Okay, bestie, security time, and yes it's serious, but we're going to be cute about it anyway 💅. This document adds extensions to OSPFv3, so it does not change the existing security considerations for OSPFv3 that are covered in [RFC5340] ✨. [RFC7166] is the glow-up here: it describes an alternative and improved authentication mechanism to IPsec for OSPFv3 🔒. Using authentication is RECOMMENDED for OSPFv3 deployment, no cap 🫶.

Reception of a malformed TLV or sub-TLV SHOULD be counted and/or logged in a rate-limited manner so people can analyze it later 🕵️‍♀️.

This document describes the OSPFv3 extensions you need to support SR over an IPv6 data plane 🌈. The security considerations for SR are discussed in [RFC8402]. [RFC8986] is the one that defines the SRv6 Network Programming concept and specifies the main SR behaviors so you can build interoperable overlays 🧚. The security considerations from that document apply here too, obviously 💖.

Advertising an incorrect MSD value can have negative consequences, so please be careful 😬. See [RFC8476] for additional considerations.

Security concerns with setting the O-flag are described in [RFC9259] 🚩.

Security concerns with using Flexible Algorithms are described in [RFC9350] 🧠.

13. IANA Considerations 📋

So here's the registry situation 🗂️. IANA has made allocations in OSPF- and OSPFv3-related registries and also created some brand new registries, all detailed in the subsections below 🍓.

13.1. OSPF Router Information TLVs

IANA has allocated the following code point in the "OSPF Router Information (RI) TLVs" registry, which lives in the "Open Shortest Path First (OSPF) Parameters" registry group 🎀:

            +=======+===================+=====================+
            | Value | TLV Name          | Reference           |
            +=======+===================+=====================+
            | 20    | SRv6 Capabilities | RFC 9513, Section 2 |
            +-------+-------------------+---------------------+

                                  Table 2

13.2. OSPFv3 LSA Function Codes

IANA has allocated the following code point in the "OSPFv3 LSA Function Codes" registry, inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group ✨:

         +=======+========================+=====================+
         | Value | LSA Function Code Name | Reference           |
         +=======+========================+=====================+
         | 42    | SRv6 Locator LSA       | RFC 9513, Section 7 |
         +-------+------------------------+---------------------+

                                 Table 3

13.3. OSPFv3 Prefix Options

IANA has allocated the following code point in the "OSPFv3 Prefix Options (8 bits)" registry, which is part of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🦋:

               +=======+=============+=====================+
               | Value | Description | Reference           |
               +=======+=============+=====================+
               | 0x80  | AC-bit      | RFC 9513, Section 6 |
               +-------+-------------+---------------------+

                                  Table 4

13.4. OSPFv3 SRv6 Capabilities TLV Flags

IANA has created a brand new subregistry called "OSPFv3 SRv6 Capabilities TLV Flags" in the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🌸. It controls the assignment of bits 0 to 15 in the Flags field of the OSPFv3 SRv6 Capabilities TLV defined in this document. The registration procedure is "Standards Action" as defined in [RFC8126].

Here's the one assignment this document makes:

            +=====+=============+=====================+
            | Bit | Description | Reference           |
            +=====+=============+=====================+
            | 1   | O-flag      | RFC 9513, Section 2 |
            +-----+-------------+---------------------+

                                  Table 5

13.5. OSPFv3 SRv6 End SID Sub-TLV Flags

IANA has created another new subregistry, this one called "OSPFv3 SRv6 End SID Sub-TLV Flags", inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🧁. It controls the assignment of bits 0 to 7 in the Flags field of the OSPFv3 SRv6 End SID sub-TLV defined in this document. The registration procedure is "Standards Action" as defined in [RFC8126].

No assignments are made by this document, so the registry is empty for now 🫧.

13.6. OSPFv3 SRv6 Adjacency SID Sub-TLV Flags

IANA has created a new subregistry called "OSPFv3 SRv6 Adjacency SID Sub-TLV Flags", which lives in the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🛤️. It controls the assignment of bits 0 to 7 in the Flags field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID sub-TLVs defined in this document. The registration procedure is "Standards Action" as defined in [RFC8126].

The following assignments have been made per this document 💜:

       +=====+=============+================================+
       | Bit | Description | Reference                      |
       +=====+=============+================================+
       | 0   | B-flag      | RFC 9513, Sections 9.1 and 9.2 |
       +-----+-------------+--------------------------------+
       | 1   | S-flag      | RFC 9513, Sections 9.1 and 9.2 |
       +-----+-------------+--------------------------------+
       | 2   | P-flag      | RFC 9513, Sections 9.1 and 9.2 |
       +-----+-------------+--------------------------------+

                              Table 6

13.7. OSPFv3 Extended-LSA Sub-TLVs

IANA has allocated the following code points in the "OSPFv3 Extended-LSA Sub-TLVs" registry, inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 👑:

    +=======+====================+======+=======================+
    | Value | Description        | L2BM | Reference             |
    +=======+====================+======+=======================+
    | 30    | SRv6 SID Structure | Y    | RFC 9513, Section 10  |
    +-------+--------------------+------+-----------------------+
    | 31    | SRv6 End.X SID     | Y    | RFC 9513, Section 9.1 |
    +-------+--------------------+------+-----------------------+
    | 32    | SRv6 LAN End.X SID | Y    | RFC 9513, Section 9.2 |
    +-------+--------------------+------+-----------------------+

                               Table 7

13.8. OSPFv3 SRv6 Locator LSA TLVs

IANA has created a new subregistry called "OSPFv3 SRv6 Locator LSA TLVs", inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🌟. It defines the top-level TLVs for the OSPFv3 SRv6 Locator LSA. Here are the initial assignments:

          +=======+==============+=======================+
          | Value | Description  | Reference             |
          +=======+==============+=======================+
          | 0     | Reserved     | RFC 9513              |
          +-------+--------------+-----------------------+
          | 1     | SRv6 Locator | RFC 9513, Section 7.1 |
          +-------+--------------+-----------------------+

                              Table 8

Types in the range 0-32767 are allocated via IETF Review or IESG Approval [RFC8126] 📝.

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

Types in the range 33024-45055 are to be assigned on a First Come First Served (FCFS) basis 🏃‍♀️.

Types in the range 45056-65535 are not to be assigned at this time 🚫. Before any assignments can be made in the 45056-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned.

13.9. OSPFv3 SRv6 Locator LSA Sub-TLVs

IANA has created a new subregistry called "OSPFv3 SRv6 Locator LSA Sub-TLVs", inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🍬. It defines sub-TLVs at any level of nesting for the SRv6 Locator LSA TLV. The initial assignments are below:

      +=======+=========================+=====================+
      | Value | Description             | Reference           |
      +=======+=========================+=====================+
      | 0     | Reserved                | RFC 9513            |
      +-------+-------------------------+---------------------+
      | 1     | SRv6 End SID            | RFC 9513, Section 8 |
      +-------+-------------------------+---------------------+
      | 2     | IPv6-Forwarding-Address | [RFC8362]; RFC      |
      |       |                         | 9513, Section 7.2   |
      +-------+-------------------------+---------------------+
      | 3     | Route-Tag               | [RFC8362]; RFC      |
      |       |                         | 9513, Section 7.2   |
      +-------+-------------------------+---------------------+
      | 4     | Prefix Source OSPF      | [RFC9084]; RFC      |
      |       | Router-ID               | 9513, Section 7.2   |
      +-------+-------------------------+---------------------+
      | 5     | Prefix Source Router    | [RFC9084]; RFC      |
      |       | Address                 | 9513, Section 7.2   |
      +-------+-------------------------+---------------------+
      | 10    | SRv6 SID Structure      | RFC 9513,           |
      |       |                         | Section 10          |
      +-------+-------------------------+---------------------+

                               Table 9

Types in the range 0-32767 are allocated via IETF Review or IESG Approval [RFC8126] 📝.

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

Types in the range 33024-45055 are to be assigned on a FCFS basis 🏃‍♀️.

Types in the range 45056-65535 are not to be assigned at this time 🚫. Before any assignments can be made in the 45056-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned.

IANA also added a note to this registry 📌. It makes sure that any document asking for allocations in this registry for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs also checks whether those allocations apply to the "OSPFv3 Extended-LSA Sub-TLVs" registry too:

   |  Note: Allocations made in this registry for sub-TLVs that are
   |  associated with OSPFv3 SRv6 Locator TLVs MUST be evaluated for
   |  their applicability as OSPFv3 Extended-LSA sub-TLVs, which are
   |  required to be allocated in the "OSPFv3 Extended-LSA Sub-TLVs"
   |  registry.

13.10. OSPFv3 Extended-LSA Sub-TLVs

IANA has added a note to the "OSPFv3 Extended-LSA Sub-TLVs" registry, inside the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🔁. The point of this note is to make sure that any document asking for allocations in this registry for sub-TLVs of any of the OSPFv3 Extended Prefix TLVs also checks whether those allocations apply to the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry defined in this document:

   |  Note: Allocations made in this registry for sub-TLVs that are
   |  associated with OSPFv3 Extended TLVs related to prefix
   |  advertisements MUST be evaluated for their applicability as OSPFv3
   |  SRv6 Locator sub-TLVs, which are required to be allocated in the
   |  "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry.

14. References 📚

The reference list picks up in the next part, bestie 🫶✨

14.1. Normative References 📚✨

okay bestie, these are the receipts the spec can't function without 🧾💅 every doc below is something this one leans on, so you need them to actually read the thing 🫶

14.2. Informative References 🌸

these ones are more like the bonus reading 📖 helpful for context but the spec doesn't need you to read them to get the core vibe 🦋

Acknowledgements 💖

the authors gave a big shoutout to Dean Cheng for helping out in the early draft versions of this doc 🫶 they also thanked Ran Chen and Detao Zhao for their ideas about extending PrefixOptions so the anycast property could be signaled ✨

they also thanked Chenzichao, Dirk Goethals, Baalajee S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and Reese Enghardt for reviewing it and sharing comments 🙌 Acee Lindem got a special thank you for his detailed shepherd review and feedback, and John Scudder got one for his AD review and suggestions 👑

Authors' Addresses 🧚

Zhenbin Li Huawei Technologies Email: lizhenbin@huawei.com

Zhibo Hu Huawei Technologies Email: huzhibo@huawei.com

Ketan Talaulikar (editor) Cisco Systems India Email: ketant.ietf@gmail.com

Peter Psenak Cisco Systems Slovakia Email: ppsenak@cisco.com

📦 where this page comes from