1.1. Terminology

This document uses the terms Segment Routing (SR), SR domain, SR over IPv6 (SRv6), Segment Identifier (SID), SRv6 SID, Active Segment, and SR Policy as defined in [RFC8402].¶

2.1. SRH TLVs

This section defines TLVs of the Segment Routing Header.¶

A TLV provides metadata for segment processing. The only TLVs defined in this document are the HMAC (Section 2.1.2) and padding TLVs (Section 2.1.1). While processing the SID defined in Section 4.3.1, all TLVs are ignored unless local configuration indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support is optional for any implementation; however, an implementation adding or parsing TLVs MUST support PAD TLVs. Other documents may define additional TLVs and processing rules for them.¶

TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2.¶

While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len.  Detection of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field of the SRH, and the packet being discarded.¶

An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY limit:¶

• the number of consecutive Pad1 (Section 2.1.1.1) options to 1. If padding of more than one byte is required, then PadN (Section 2.1.1.2) should be used.¶
• The length in PadN to 5.¶
• The maximum number of non-Pad TLVs to be processed.¶
• The maximum length of all TLVs to be processed.¶

The implementation MAY stop processing additional TLVs in the SRH when these configured limits are exceeded.¶

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|     Type      |    Length     | Variable-length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------

Type:

An 8-bit codepoint from the "Segment Routing Header TLVs" [IANA-SRHTLV]. Unrecognized Types MUST be ignored on receipt.¶

Length:

The length of the variable-length data field in bytes.¶

Variable-length data:

data that is specific to the Type.¶

Type Length Value (TLV) entries contain OPTIONAL information that may be used by the node identified in the Destination Address (DA) of the packet.¶

Each TLV has its own length, format, and semantic. The codepoint allocated (by IANA) to each TLV Type defines both the format and the semantic of the information carried in the TLV. Multiple TLVs may be encoded in the same SRH.¶

The highest-order bit of the TLV type (bit 0) specifies whether or not the TLV data of that type can change en route to the packet's final destination:¶

• 0: TLV data does not change en route¶
• 1: TLV data does change en route¶

All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per [RFC8200]. The SR source nodes use the xn+y alignment requirements of TLVs and Padding TLVs when constructing an SRH.¶

The Length field of the TLV is used to skip the TLV while inspecting the SRH in case the node doesn't support or recognize the Type. The Length defines the TLV length in octets, not including the Type and Length fields.¶

The following TLVs are defined in this document:¶

• Padding TLVs¶
• HMAC TLV¶

Additional TLVs may be defined in the future.¶

  0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |     Type      |
  +-+-+-+-+-+-+-+-+

 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     |      Padding (variable)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                    Padding (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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    |D|        RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      HMAC Key ID (4 octets)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                              //
|                      HMAC (variable)                         //
|                                                              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

3.1. SR Source Node

A SR source node is any node that originates an IPv6 packet with a segment (i.e., SRv6 SID) in the destination address of the IPv6 header. The packet leaving the SR source node may or may not contain an SRH. This includes either:¶

• A host originating an IPv6 packet, or¶
• An SR domain ingress router encapsulating a received packet in an outer IPv6 header, followed by an optional SRH.¶

It is out of the scope of this document to describe the mechanism through which a segment in the destination address of the IPv6 header and the Segment List in the SRH are derived.¶

3.2. Transit Node

A transit node is any node forwarding an IPv6 packet where the destination address of that packet is not locally configured as a segment or a local interface. A transit node is not required to be capable of processing a segment or SRH.¶

4.1. SR Source Node

A source node steers a packet into an SR Policy. If the SR Policy results in a Segment List containing a single segment, and there is no need to add information to the SRH flag or add TLV; the DA is set to the single Segment List entry, and the SRH MAY be omitted.¶

When needed, the SRH is created as follows:¶

The Next Header and Hdr Ext Len fields are set as specified in [RFC8200].¶

The Routing Type field is set to 4.¶

The DA of the packet is set with the value of the first segment.¶

The first element of the SRH Segment List is the ultimate segment. The second element is the penultimate segment, and so on.¶

The Segments Left field is set to n-1, where n is the number of elements in the SR Policy.¶

The Last Entry field is set to n-1, where n is the number of elements in the SR Policy.¶

TLVs (including HMAC) may be set according to their specification.¶

The packet is forwarded toward the packet's Destination Address (the first segment).¶

4.3. SR Segment Endpoint Node

Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs.¶

When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address. This lookup can return any of the following:¶

• A FIB entry that represents a locally instantiated SRv6 SID¶
• A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID¶
• A FIB entry that represents a nonlocal route¶
• No Match¶

S01. When an SRH is processed {
S02.   If Segments Left is equal to zero {
S03.     Proceed to process the next header in the packet,
         whose type is identified by the Next Header field in
         the routing header.
S04.   }
S05.   Else {
S06.     If local configuration requires TLV processing {
S07.       Perform TLV processing (see TLV Processing)
S08.     }
S09.     max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
S10.     If  ((Last Entry > max_last_entry) or
S11.          (Segments Left is greater than (Last Entry+1)) {
S12.       Send an ICMP Parameter Problem, Code 0, message to
           the Source Address, pointing to the Segments Left
           field, and discard the packet.
S13.     }
S14.     Else {
S15.       Decrement Segments Left by 1.
S16.       Copy Segment List[Segments Left] from the SRH to the
           destination address of the IPv6 header.
S17.       If the IPv6 Hop Limit is less than or equal to 1 {
S18.         Send an ICMP Time Exceeded -- Hop Limit Exceeded in
             Transit message to the Source Address and discard
             the packet.
S19.       }
S20.       Else {
S21.         Decrement the Hop Limit by 1
S22.         Resubmit the packet to the IPv6 module for transmission
             to the new destination.
S23.       }
S24.     }
S25.   }
S26. }

Example 1:
For any packet received from interface I2
  Skip TLV processing

Example 2:
For any packet received from interface I1
  If first TLV is HMAC {
    Process the HMAC TLV
  }
  Else {
    Discard the packet
  }

IF (Upper-layer Header is IPv4 or IPv6) and
    local configuration permits {
  Perform IPv6 decapsulation
  Resubmit the decapsulated packet to the IPv4 or IPv6 module
}
ELSE {
  Send an ICMP parameter problem message to the Source Address and
  discard the packet.  Error code (4) "SR Upper-layer
  Header Error", pointer set to the offset of the upper-layer
  header.
}

5.1. Securing the SR Domain

Nodes outside the SR domain are not trusted: they cannot directly use the SIDs of the domain. This is enforced by two levels of access control lists:¶

1. Any packet entering the SR domain and destined to a SID within the SR domain is dropped. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:¶

   • Allocate all the SIDs from a block S/s¶
   • Configure each external interface of each edge node of the domain with an inbound infrastructure access list (IACL) that drops any incoming packet with a destination address in S/s¶
   • Failure to implement this method of ingress filtering exposes the SR domain to source-routing attacks, as described and referenced in [RFC5095]¶

2. The distributed protection in #1 is complemented with per-node protection, dropping packets to SIDs from source addresses outside the SR domain. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:¶

   • Assign all interface addresses from prefix A/a¶
   • At node k, all SIDs local to k are assigned from prefix Sk/sk¶
   • Configure each internal interface of each SR node k in the SR domain with an inbound IACL that drops any incoming packet with a destination address in Sk/sk if the source address is not in A/a.¶

5.2. SR Domain as a Single System with Delegation among Components

All intra-SR-domain packets are of the SR domain. The IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.¶

All interdomain packets are encapsulated for the part of the packet journey that is within the SR domain. The outer IPv6 header is originated by a node of the SR domain and is destined to a node of the SR domain.¶

As a consequence, any packet within the SR domain is of the SR domain.¶

The SR domain is a system in which the operator may want to distribute or delegate different operations of the outermost header to different nodes within the system.¶

An operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain and delegate validation of the contents of any SRH to a more trusted router or switch attached to the host. Consider a top-of-rack switch T connected to host H via interface I. H receives an SRH (SRH1) with a computed HMAC via some SDN method outside the scope of this document. H classifies traffic it sources and adds SRH1 to traffic requiring a specific Service Level Agreement (SLA). T is configured with an IACL on I requiring verification of the SRH for any packet destined to the SID block of the SR domain (S/s). T checks and verifies that SRH1 is valid and contains an HMAC TLV; T then verifies the HMAC.¶

An operator of the SR domain may choose to have all segments in the SR domain verify the HMAC. This mechanism would verify that the SRH Segment List is not modified while traversing the SR domain.¶

5.3. MTU Considerations

An SR domain ingress edge node encapsulates packets traversing the SR domain and needs to consider the MTU of the SR domain. Within the SR domain, well-known mitigation techniques are RECOMMENDED, such as deploying a greater MTU value within the SR domain than at the ingress edges.¶

Encapsulation with an outer IPv6 header and SRH shares the same MTU and fragmentation considerations as IPv6 tunnels described in [RFC2473]. Further investigation on the limitation of various tunneling methods (including IPv6 tunnels) is discussed in [INTAREA-TUNNELS] and SHOULD be considered by operators when considering MTU within the SR domain.¶

5.4. ICMP Error Processing

ICMP error packets generated within the SR domain are sent to source nodes within the SR domain. The invoking packet in the ICMP error message may contain an SRH. Since the destination address of a packet with an SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet.¶

For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol-error handlers.¶

• Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper-layer header.¶

  • If routing header is type 4 Segment Routing Header (SRH)¶

    • The SID at Segment List[0] may be used as the destination address of the invoking packet.¶

ICMP errors are then processed by upper-layer transports as defined in [RFC4443].¶

For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in [RFC2473].¶

5.5. Load Balancing and ECMP

For any interdomain packet, the SR source node MUST impose a flow label computed based on the inner packet. The computation of the flow label is as recommended in [RFC6438] for the sending Tunnel End Point.¶

For any intradomain packet, the SR source node SHOULD impose a flow label computed as described in [RFC6437] to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH.¶

At any transit node within an SR domain, the flow label MUST be used as defined in [RFC6438] to calculate the ECMP hash toward the destination address. If a flow label is not used, the transit node would likely hash all packets between a pair of SR Edge nodes to the same link.¶

At an SR segment endpoint node, the flow label MUST be used as defined in [RFC6438] to calculate any ECMP hash used to forward the processed packet to the next segment.¶

5.6. Other Deployments

Other deployment models and their implications on security, MTU, HMAC, ICMP error processing, and interaction with other extension headers are outside the scope of this document.¶

8.1. Segment Routing Header Flags Registry

This document describes a new IANA-managed registry to identify SRH Flags Bits. The registration procedure is "IETF Review" [RFC8126]. The registry name is "Segment Routing Header Flags". Flags are 8 bits.¶

8.2. Segment Routing Header TLVs Registry

This document describes a new IANA-managed registry to identify SRH TLVs. The registration procedure is "IETF Review". The registry name is "Segment Routing Header TLVs". A TLV is identified through an unsigned 8-bit codepoint value, with assigned values 0-127 for TLVs that do not change en route and 128-255 for TLVs that may change en route. The following codepoints are defined in this document:¶

Values 1, 2, 3, and 6 were defined in draft versions of this specification and are Reserved for backwards compatibility with early implementations and should not be reassigned. Values 127 and 255 are Reserved to allow for expansion of the Type field in future specifications, if needed.¶