<?xml version="1.0"encoding="US-ASCII"?>encoding="utf-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-6man-segment-routing-header-26"ipr="trust200902">number="8754" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.35.0 --> <front> <title abbrev="IPv6 Segment Routing Header (SRH)">IPv6 Segment Routing Header (SRH)</title> <seriesInfo name="RFC" value="8754" /> <author fullname="Clarence Filsfils" initials="C." role="editor" surname="Filsfils"> <organization>Cisco Systems, Inc.</organization> <address> <postal> <street/> <city>Brussels</city> <region/> <code/> <country>BE</country> </postal> <email>cfilsfil@cisco.com</email> </address> </author> <author fullname="Darren Dukes" initials="D." role="editor" surname="Dukes"> <organization>Cisco Systems, Inc.</organization> <address> <postal> <street/> <city>Ottawa</city> <region/> <code/> <country>CA</country> </postal> <email>ddukes@cisco.com</email> </address> </author> <author fullname="Stefano Previdi" initials="S." surname="Previdi"> <organization>Huawei</organization> <address> <postal> <street/> <city/> <code/> <country>Italy</country> </postal> <email>stefano@previdi.net</email> </address> </author> <author fullname="John Leddy" initials="J." surname="Leddy"> <organization>Individual</organization> <address> <postal> <street/> <city/> <region/> <code/> <country>US</country> </postal> <email>john@leddy.net</email> </address> </author> <author fullname="Satoru Matsushima" initials="S." surname="Matsushima"><organization>Softbank</organization><organization>SoftBank</organization> <address> <email>satoru.matsushima@g.softbank.co.jp</email> </address> </author> <author fullname="Daniel Voyer" initials="D." surname="Voyer"> <organization>Bell Canada</organization> <address> <email>daniel.voyer@bell.ca</email> </address> </author> <dateyear="2019"/>year="2020" month="March"/> <workgroup>Network Working Group</workgroup> <keyword>SRv6</keyword> <keyword>source-routing</keyword> <keyword>network-programming</keyword> <abstract> <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment RoutingHeader.Header (SRH). This document describes theSegment Routing HeaderSRH and how it is used by nodes that are Segment Routingcapable nodes.</t>(SR) capable.</t> </abstract> </front> <middle> <section anchor="INTRO"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Segment Routing (SR) can be applied to the IPv6 data plane using a new type ofRouting Headerrouting header called the Segment RoutingHeader.Header (SRH). This document describes theSegment Routing HeaderSRH and how it is used bySegment Routing capable nodes.</t> <t>The Segmentnodes that are SR capable.</t> <t>"Segment RoutingArchitectureArchitecture" <xreftarget="RFC8402"/>target="RFC8402" format="default"/> describes Segment Routing and its instantiation in two dataplanes;planes: MPLS and IPv6.</t> <t>The encoding of IPv6 segments in theSegment Routing HeaderSRH is defined in this document.</t> <section anchor="TERMS" numbered="true" toc="default"> <name>Terminology</name> <t>This document uses the terms SegmentRouting,Routing (SR), SR domain, SRDomain, SRv6,over IPv6 (SRv6), SegmentIDIdentifier (SID), SRv6 SID, Active Segment, and SR Policy as defined in <xreftarget="RFC8402"/>.</t>target="RFC8402" format="default"/>.</t></section> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="SRH"title="Segmentnumbered="true" toc="default"> <name>Segment RoutingHeader">Header</name> <t>RoutingHeadersheaders are defined in <xreftarget="RFC8200"/>.target="RFC8200" format="default"/>. The Segment Routing Header (SRH) has a new Routing Type(suggested value 4) to be assigned by IANA.</t>(4).</t> <t>TheSegment Routing Header (SRH)SRH is defined asfollows:<figurefollows:</t> <artwork name="" type="" align="left"anchor="SRHFIG" suppress-title="true"> <artwork>alt="">< | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[n](128 bits(128-bit IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // // Optional Type Length Value objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:</artwork> </figure><list style="symbols"> <t>Next Header: Defined]]></artwork> <t>where:</t> <dl spacing="normal"> <dt>Next Header:</dt><dd>Defined in <xreftarget="RFC8200"/> Section 4.4</t> <t>Hdrtarget="RFC8200" sectionFormat="comma" section="4.4"/>.</dd> <dt>Hdr ExtLen: Defined in <xref target="RFC8200"/> Section 4.4</t> <t>Routing Type: TBD, to be assigned by IANA (suggested value: 4).</t> <t>Segments Left: DefinedLen:</dt><dd>Defined in <xreftarget="RFC8200"/> Section 4.4</t> <t>Last Entry: containstarget="RFC8200" sectionFormat="comma" section="4.4"/>.</dd> <dt>Routing Type:</dt><dd>4.</dd> <dt>Segments Left:</dt><dd>Defined in <xref target="RFC8200" sectionFormat="comma" section="4.4"/>.</dd> <dt>Last Entry:</dt><dd>contains the index (zero based), in the Segment List, of the last element of the SegmentList.</t> <t>Flags: 8List.</dd> <dt>Flags:</dt><dd>8 bits of flags. <xreftarget="SRHFLAGSREG"/>target="SRHFLAGSREG" format="default"/> creates an IANA registry for new flags to be defined. The following flags aredefined:<figure align="left" anchor="SRHFLAGS" suppress-title="true">defined:</dd></dl> <artworkalign="left">align="left" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |U U U U U U U U| +-+-+-+-+-+-+-+-+</artwork> </figure><list style="hanging"> <t>U:]]></artwork> <dl newline="false" spacing="normal"> <dt/> <dd>U: Unused and for future use.MUST<bcp14>MUST</bcp14> be 0 on transmission and ignored onreceipt.</t> </list></t> <t>Tag: tagreceipt.</dd> </dl> <dl spacing="normal"> <dt>Tag:</dt><dd>Tag a packet as part of a class or group ofpackets,packets -- e.g., packets sharing the same set of properties. WhentagTag is not used atsourcethe source, itMUST<bcp14>MUST</bcp14> be set to zero on transmission. WhentagTag is not used during SRHProcessingprocessing, itSHOULD<bcp14>SHOULD</bcp14> be ignored. Tag is not used when processing the SID defined in <xreftarget="pktENDSID"/>.target="pktENDSID" format="default"/>. It may be used when processing other SIDs that are not defined in this document. The allocation and use of tag is outside the scope of thisdocument.</t> <t>Segment List[n]: 128 bitdocument.</dd> <dt>Segment List[0..n]:</dt><dd>128-bit IPv6 addresses representing the nth segment in the Segment List. The Segment List is encoded starting from the last segment of the SR Policy.I.e.,That is, the first element of thesegment list (SegmentSegment List[0])(Segment List[0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SRPolicyPolicy, and soon.</t> <t>Typeon.</dd> <dt>TLV:</dt><dd>Type Length Value (TLV)areis described in <xreftarget="TLVS"/>.</t> </list></t>target="TLVS" format="default"/>.</dd> </dl> <t>In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments Left fields are defined inSection 4.4 of<xreftarget="RFC8200"/>.target="RFC8200" sectionFormat="of" section="4.4"/>. Based on the constraints in that section, Next Header, Header Ext Len, and Routing Type are not mutable while Segments Left is mutable.</t> <t>The mutability of the TLV value is defined by the most significant bit in the type, as specified in <xreftarget="TLVS"/>.</t>target="TLVS" format="default"/>.</t> <t><xreftarget="ENDSID"/>target="ENDSID" format="default"/> defines the mutability of the remaining fields in the SRH (Flags, Tag, Segment List) in the context of the SID defined in this document.</t> <t>New SIDs defined in the futureMUST<bcp14>MUST</bcp14> specify the mutability properties of the Flags, Tag, and Segment List and indicate how theHMACHashed Message Authentication Code (HMAC) TLV (<xreftarget="HMACTLV"/>)target="HMACTLV" format="default"/>) verification works.Note, thatNote that, ineffecteffect, these fields are mutable.</t> <t>Consistent with thesource routingSR model, the source of the SRH always knows how to set thesegment list,Segment List, Flags,TagTag, and TLVs of the SRH for use within the SRDomain.domain. How it achieves this is outside the scope of thisdocument,document but may be based on topology, available SIDs and their mutability properties, the SRH mutability requirements of the destination, or any other information.</t> <section anchor="TLVS"title="SRH TLVs">numbered="true" toc="default"> <name>SRH TLVs</name> <t>This section defines TLVs of the Segment Routing Header.</t> <t>A TLV providesmeta-datametadata for segment processing. The only TLVs defined in this document are the HMAC (<xreftarget="HMACTLV"/>)target="HMACTLV" format="default"/>) andPADpadding TLVs (<xreftarget="PADDINGTLV"/>) TLVs.target="PADDINGTLV" format="default"/>). While processing the SID defined in <xreftarget="pktENDSID"/>,target="pktENDSID" format="default"/>, all TLVs are ignored unless local configuration indicates otherwise (<xreftarget="TLVPROCESS"/>).target="TLVPROCESS" format="default"/>). Thus, TLV and HMAC support is optional for anyimplementation,implementation; however, an implementation adding or parsing TLVsMUST<bcp14>MUST</bcp14> support PAD TLVs. Other documents may define additional TLVs and processing rules for them.</t> <t>TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2.</t> <t>While processing TLVs at a segment endpoint, TLVsMUST<bcp14>MUST</bcp14> be fully contained within the SRH as determined by the Hdr ExtLen.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.</t> <t>An implementationMAY<bcp14>MAY</bcp14> limit the number and/or length of TLVs it processes based on local configuration. ItMAY:<list style="symbols"> <t>Limit the<bcp14>MAY</bcp14> limit:</t> <ul spacing="normal"> <li>the number of consecutive Pad1 (<xreftarget="PAD1"/>)target="PAD1" format="default"/>) options to 1. If padding of more than one byte is required, then PadN (<xreftarget="PADN"/>)target="PADN" format="default"/>) should beused.</t> <t>Limit theused.</li> <li>The length in PadN to5.</t> <t>Limit the5.</li> <li>The maximum number of non-Pad TLVs to beprocessed.</t> <t>Limit theprocessed.</li> <li>The maximum length of all TLVs to beprocessed.</t> </list>processed.</li> </ul> <t> The implementationMAY<bcp14>MAY</bcp14> stop processing additional TLVs in the SRH when these configured limits are exceeded.</t><figure> <artwork><artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- | Type | Length |Variable lengthVariable-length data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------</artwork> </figure> <t>Type: An 8 bit]]></artwork><dl spacing="normal"> <dt>Type:</dt><dd>An 8-bit codepoint fromSegmentthe "Segment Routing HeaderTLVs Registry TBD IANA Reference.TLVs" <xref target="IANA-SRHTLV" format="default"/>. Unrecognized TypesMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t> <t>Length: Thereceipt.</dd> <dt>Length:</dt><dd>The length of theVariable lengthvariable-length data field inbytes.</t> <t>Variable length data: Length bytes of databytes.</dd> <dt>Variable-length data:</dt><dd>data that is specific to theType.</t>Type.</dd></dl> <t>Type Length Value (TLV) entries containOPTIONAL<bcp14>OPTIONAL</bcp14> information that may be used by the node identified in the Destination Address (DA) of the packet.</t> <t>Each TLV has its own length,formatformat, 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.</t> <t>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:<list> <t>0:</t> <ul empty="true" spacing="normal"> <li>0: TLV data does not change enroute</t> <t>1:route</li> <li>1: TLV data does change enroute</t> </list></t>route</li> </ul> <t>All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per <xreftarget="RFC8200"/>.target="RFC8200" format="default"/>. The SRSourcesource nodes use the xn+y alignment requirements of TLVs and Padding TLVs when constructing an SRH.</t> <t>The"Length"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"Length defines the TLV length in octets, not including the"Type"Type and"Length"Length fields.</t> <t>The following TLVs are defined in thisdocument:<list> <t>Padding TLVs</t> <t>HMAC TLV</t> </list></t>document:</t> <ul empty="true" spacing="normal"> <li>Padding TLVs</li> <li>HMAC TLV</li> </ul> <t>Additional TLVs may be defined in the future.</t> <section anchor="PADDINGTLV"title="Padding TLVs">numbered="true" toc="default"> <name>Padding TLVs</name> <t>There are two types of Padding TLVs,pad1Pad1 and PadN, andpadN,the following applies toboth:<list> <t>Paddingboth:</t> <ul empty="true" spacing="normal"> <li>Padding TLVs are used for meeting the alignment requirement of the subsequentTLVs.</t> <t>PaddingTLVs.</li> <li>Padding TLVs are used to pad the SRH to a multiple of 8octets.</t> <t>Paddingoctets.</li> <li>Padding TLVs are ignored by a node processing the SRHTLV.</t> <t>MultipleTLV.</li> <li>Multiple Padding TLVsMAY<bcp14>MAY</bcp14> be used in oneSRH</t> </list></t>SRH.</li> </ul> <section anchor="PAD1"title="PAD1">numbered="true" toc="default"> <name>Pad1</name> <t>Alignment requirement: none</t><figure> <artwork><artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type |+-+-+-+-+-+-+-+-+</artwork> </figure> <t><list> <t>Type: to be assigned by IANA (Suggested value 0)</t> </list></t>+-+-+-+-+-+-+-+-+]]></artwork> <dl spacing="normal"> <dt>Type:</dt><dd>0</dd> </dl> <t>A single Pad1 TLVMUST<bcp14>MUST</bcp14> be used when a single byte of padding is required. A Pad1 TLVMUST NOT<bcp14>MUST NOT</bcp14> be used if more than one consecutive byte of padding is required.</t> </section> <section anchor="PADN"title="PADN">numbered="true" toc="default"> <name>PadN</name> <t>Alignment requirement: none</t><figure> <artwork><artwork name="" type="" align="left" alt=""><![CDATA[ 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) //+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <t><list> <t>Type: to be assigned by IANA (suggested value 4).</t> <t>Length: 0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> <dl spacing="normal"> <dt>Type:</dt><dd>4</dd> <dt>Length:</dt><dd>0 to5</t> <t>Padding: Length octets5. The length ofpadding.the Padding field in bytes.</dd> <dt>Padding:</dt><dd>Padding bits have no semantic. TheyMUST<bcp14>MUST</bcp14> be set to 0 on transmission and ignored onreceipt.</t> </list></t>receipt.</dd> </dl> <t>The PadN TLVMUST<bcp14>MUST</bcp14> be used when more than one byte of padding is required.</t> </section> </section> <section anchor="HMACTLV"title="HMAC TLV">numbered="true" toc="default"> <name>HMAC TLV</name> <t>Alignment requirement: 8n</t> <t>The keyed Hashed Message Authentication Code (HMAC) TLV isOPTIONAL<bcp14>OPTIONAL</bcp14> and has the followingformat:<figure> <artwork>format:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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)(variable) // | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:</artwork> </figure> <list style="symbols"> <t>Type: to be assigned by IANA (suggested value 5).</t> <t>Length: Thewhere:]]></artwork> <dl spacing="normal"> <dt>Type:</dt><dd>5.</dd> <dt>Length:</dt><dd>The length of thevariable lengthvariable-length data inbytes.</t> <t>D: 1bytes.</dd> <dt>D:</dt><dd>1 bit. 1 indicates that the Destination Address verification is disabled due to use of a reducedsegment list,Segment List (see <xreftarget="REDUCED"/>.</t> <t>RESERVED: 15target="REDUCED" format="default"/>).</dd> <dt>RESERVED:</dt><dd>15 bits.MUST<bcp14>MUST</bcp14> be 0 ontransmission.</t> <t>HMACtransmission.</dd> <dt>HMAC KeyID: A 4 octetID:</dt><dd>A 4-octet opaque numberwhichthat uniquely identifies the pre-shared key and algorithm used to generate theHMAC.</t> <t>HMAC: KeyedHMAC.</dd> <dt>HMAC:</dt><dd>Keyed HMAC, in multiples of 8 octets, at most 32octets.</t> </list></t>octets.</dd> </dl> <t>The HMAC TLV is used to verify that the SRH applied to a packet was selected by an authorizedparty,party and to ensure that the segment list is not modified after generation. This also allows for verification that the current segment (by virtue of being in the authorizedsegment list)Segment List) is authorized for use. The SRDomaindomain ensures that the source node is permitted to use the source address in the packet via ingress filtering mechanisms as defined in BCP 84 <xreftarget="RFC3704"/>,target="RFC3704" format="default"/> or other strategies as appropriate.</t> <sectiontitle="HMACnumbered="true" toc="default"> <name>HMAC Generation andVerification">Verification</name> <t>Local configuration determines when to check for an HMAC. This local configuration is outside the scope of this document. It may be based on the active segment at an SR Segment endpoint node, the result of anACLAccess Control List (ACL) that considers incoming interface, HMAC Key ID, or other packet fields.</t> <t>An implementation that supports the generation and verification of the HMAC supports the following default behavior, as defined in the remainder of this section.</t> <t>The HMAC verification begins by checking that the current segment is equal to the destination address of the IPv6 header. The check is successful wheneither<list style="symbols"> <t>HMACeither:</t> <ul spacing="normal"> <li>HMAC D bit is 1 and Segments Left is greater than LastEntry.</t> <t>HMACEntry, or</li> <li>HMAC Segments Left is less than or equal to LastEntryEntry, and the destination address is equal to SegmentList [Segments Left].</t> </list></t>List[Segments Left].</li> </ul> <t>The HMAC field is the output of the HMAC computation as defined in <xreftarget="RFC2104"/>, using:<list style="symbols"> <t>key: thetarget="RFC2104" format="default"/>, using:</t> <ul spacing="normal"> <li>key: The pre-shared key identified by HMAC KeyID</t> <t>HMACID</li> <li>HMAC algorithm:identifiedIdentified by the HMAC KeyID</t>ID</li> <li> <t>Text:aA concatenation of the following fields from the IPv6 header and the SRH, as it would be received at the node verifying theHMAC:<list style="symbols"> <t>IPv6HMAC:</t> <ul spacing="normal"> <li>IPv6 header:sourceSource address (16octets)</t> <t>SRH:octets)</li> <li>SRH: Last Entry (1octet)</t> <t>SRH:octet)</li> <li>SRH: Flags (1octet)</t> <t>SRH:octet)</li> <li>SRH: HMAC 16 bits followingLength</t> <t>SRH:Length</li> <li>SRH: HMAC Key ID (4octets)</t> <t>SRH: alloctets)</li> <li>SRH: All addresses in the Segment List (variableoctets)</t> </list></t> </list></t>octets)</li> </ul> </li> </ul> <t>The HMAC digest is truncated to 32 octets and placed in the HMAC field of the HMAC TLV.</t> <t>For HMAC algorithms producing digests less than 32octets,octets long, the digest is placed in thelowest orderlowest-order octets of the HMAC field. Subsequent octetsMUST<bcp14>MUST</bcp14> be set to zero such that the HMAC length is a multiple of 8 octets.</t> <t>If HMAC verification is successful, processing proceeds as normal.</t> <t>If HMAC verification fails, an ICMP error message (parameter problem, error code 0, pointing to the HMAC TLV)SHOULD<bcp14>SHOULD</bcp14> be generated (but rate limited) andSHOULD be loggedlogged, and the packet <bcp14>SHOULD</bcp14> be discarded.</t> </section> <sectiontitle="HMAC Pre-Sharednumbered="true" toc="default"> <name>HMAC Pre-shared KeyAlgorithm">Algorithm</name> <t>The HMAC Key ID field allows for the simultaneous existence of several hash algorithms (SHA-256, SHA3-256 ... or future ones) as well as pre-shared keys.</t> <t>The HMAC Key ID field isopaque,opaque -- i.e., it has neither syntax nor semantic except as an identifier of the right combination of pre-shared key and hash algorithm.</t> <t>At the HMAC TLV generating and verification nodes, the Key ID uniquely identifies the pre-shared key and HMAC algorithm.</t> <t>At the HMAC TLV generating node, the Text for the HMAC computation is set to the IPv6 header fields and SRH fields as they would appear at the verification node(s), not necessarily the same as the source node sending a packet with the HMAC TLV.</t><t>Pre-shared<t>Pre-Shared keyroll-overrollover is supported by having two key IDs in use while the HMAC TLV generating node and verifying node converge to a new key.</t> <t>The HMAC TLV generating node may need to revoke an SRH for which it previously generated an HMAC. Revocation is achieved by allocating a new key and key ID, then rolling over the key ID associated with the SRH to be revoked. The HMAC TLV verifying node drops packets with the revoked SRH.</t> <t>An implementation supporting HMAC can support multiple hash functions. An implementation supporting HMACMUST<bcp14>MUST</bcp14> implement SHA-2 <xreftarget="FIPS180-4"/>target="FIPS180-4" format="default"/> in its SHA-256 variant.</t> <t>The selection of pre-shared key andalgorithm,algorithm and their distribution is outside the scope of this document. Some options may include:<list style="symbols"> <t>in</t> <ul spacing="normal"> <li>setting these items in the configuration of the HMAC generating or verifying nodes, either by static configuration or anySDN oriented approach</t> <t>dynamicallySDN-oriented approach</li> <li>dynamically using a trusted key distribution protocol such as <xreftarget="RFC6407"/></t> </list></t>target="RFC6407" format="default"/></li> </ul> <t>While key management is outside the scope of this document, the recommendations of BCP 107 <xreftarget="RFC4107"/>target="RFC4107" format="default"/> should be considered when choosing the key management system.</t> </section> </section> </section> </section> <section anchor="SRNODES"title="SR Nodes">numbered="true" toc="default"> <name>SR Nodes</name> <t>There are different types of nodes that may be involved in segment routing networks:sourceSR source nodes that originate packets with a segment in the destination address of the IPv6 header, transit nodes that forward packets destined to a remote segment, and SR segment endpoint nodes that process a local segment in the destination address of an IPv6 header.</t> <section anchor="SOURCE"title="Source SR Node"> <t>Anumbered="true" toc="default"> <name>SR Source Node</name> <t>A SRNodesource node is any node that originates an IPv6 packet with a segment(i.e.(i.e., SRv6 SID) in the destination address of the IPv6 header. The packet leaving thesourceSRNodesource node may or may not contain an SRH. This includes either:<list style="hanging"> <t>A</t> <ul spacing="normal"> <li>A host originating an IPv6packet.</t> <t>Anpacket, or</li> <li>An SR domain ingress router encapsulating a received packet in an outer IPv6 header, followed by an optionalSRH.</t> </list></t> <t>TheSRH.</li> </ul> <t>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 theSRH, is derived is outside the scope of this document.</t>SRH are derived.</t> </section> <section anchor="TRANSIT"title="Transit Node">numbered="true" toc="default"> <name>Transit Node</name> <t>A transit node is any node forwarding an IPv6 packet where the destination address of that packet is not locally configured as a segmentnoror a local interface. A transit node is not required to be capable of processing a segmentnoror SRH.</t> </section> <sectiontitle="SRnumbered="true" toc="default"> <name>SR Segment EndpointNode"> <t>ANode</name> <t>An SR segment endpoint node is any node receiving an IPv6 packet where the destination address of that packet is locally configured as a segment or local interface.</t> </section> </section> <section anchor="PacketProcessing"title="Packet Processing">numbered="true" toc="default"> <name>Packet Processing</name> <t>This section describes SRv6 packet processing at the SR source,TransitTransit, and SR segment endpoint nodes.</t> <section anchor="pktSourceNode"title="Source SR Node"> <t>Anumbered="true" toc="default"> <name>SR Source Node</name> <t>A source node steers a packet into an SR Policy. If the SR Policy results in asegment listSegment List containing a single segment, and there is no need to add information to the SRH flag ortoaddTLV,TLV; the DA is set to the singlesegment list entrySegment List entry, and the SRHMAY<bcp14>MAY</bcp14> be omitted.</t> <t>When needed, the SRH is created asfollows:<list style="hanging"> <t>Nextfollows:</t> <dl newline="false" spacing="normal"> <dt/> <dd>The Next Header and Hdr Ext Len fields are set as specified in <xreftarget="RFC8200"/>.</t> <t>Routingtarget="RFC8200" format="default"/>.</dd> <dt/> <dd>The Routing Type field is setas TBD (to be allocated by IANA, suggested value 4).</t> <t>Theto 4.</dd> <dt/> <dd>The DA of the packet is set with the value of the firstsegment.</t> <t>Thesegment.</dd> <dt/> <dd>The first element of the SRH Segment List is the ultimate segment. The second element is the penultimate segment, and soon.</t> <t>Theon.</dd> <dt/> <dd>The Segments Left field is set ton-1n-1, where n is the number of elements in the SRPolicy.</t> <t>ThePolicy.</dd> <dt/> <dd>The Last Entry field is set ton-1n-1, where n is the number of elements in the SRPolicy.</t> <t>TLVsPolicy.</dd> <dt/> <dd>TLVs (including HMAC) may be set according to theirspecification.</t> <t>Thespecification.</dd> <dt/> <dd>The packet is forwarded toward the packet's Destination Address (the firstsegment).</t> </list></t>segment).</dd> </dl> <section anchor="REDUCED"title="Reduced SRH">numbered="true" toc="default"> <name>Reduced SRH</name> <t>When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used.</t> <t>A reduced SRH does not contain the first segment of the related SR Policy (the first segment is the one already in the DA of the IPv6 header), and the Last Entry field is set ton-2n-2, where n is the number of elements in the SR Policy.</t> </section> </section> <sectiontitle="Transit Node">numbered="true" toc="default"> <name>Transit Node</name> <t>As specified in <xreftarget="RFC8200"/>,target="RFC8200" format="default"/>, the only node allowed to inspect the Routing Extension Header (and therefore theSRH),SRH) is the node corresponding to the DA of the packet. Any other transit nodeMUST NOT<bcp14>MUST NOT</bcp14> inspect the underneath routing header andMUST<bcp14>MUST</bcp14> forward the packet toward the DA according to its IPv6 routing table.</t> <t>When a SID is in the destination address of an IPv6 header of a packet, it's routed through an IPv6 network as an IPv6 address. SIDs, or the prefix(es) covering SIDs, and their reachability may be distributed by means outside the scope of this document. For example, <xreftarget="RFC5308"/>target="RFC5308" format="default"/> or <xreftarget="RFC5340"/>target="RFC5340" format="default"/> may be used to advertise a prefix covering the SIDs on a node.</t> </section> <section anchor="ENDSID"title="SRnumbered="true" toc="default"> <name>SR Segment EndpointNode">Node</name> <t>Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs.</t> <t>When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on thepacketspacket's destination address. This lookup can return any of thefollowing:<figure align="left"> <artwork> * Afollowing:</t> <ul> <li>A FIB entry that represents a locally instantiated SRv6SID * ASID</li> <li>A FIB entry that represents a local interface, not locally instantiated as an SRv6SID * ASID</li> <li>A FIB entry that represents anon-local route * No Match</artwork> </figure></t>nonlocal route</li> <li>No Match</li> </ul> <section anchor="pktENDSID"title="FIBnumbered="true" toc="default"> <name>FIB Entry Is a Locally Instantiated SRv6SID">SID</name> <t>Thisdocument,document andsection, definessection define a single SRv6 SID. Future documents may define additional SRv6 SIDs. Inwhichsuch a case, the entire content of this section will be defined in that document.</t> <t>If the FIB entry represents a locally instantiated SRv6 SID, process the next header chain of the IPv6 header as defined insection 4 of<xreftarget="RFC8200"/>.target="RFC8200" sectionFormat="of" section="4"/>. <xreftarget="SRHPROC"/>target="SRHPROC" format="default"/> describes how to process anSRH,SRH; <xreftarget="UPPERHEADER"/>target="UPPERHEADER" format="default"/> describes how to process anupper layerupper-layer header orno next header.</t>the absence of a Next Header.</t> <t>Processing this SID modifies the Segments Left and, if configured to process TLVs, it may modify the"variable length"variable-length data" of TLV types that change en route.ThereforeTherefore, Segments Left ismutablemutable, and TLVs that change en route are mutable. The remainder of the SRH (Flags, Tag, Segment List, and TLVs that do not change en route) are immutable while processing this SID.</t> <section anchor="SRHPROC"title="SRH Processing"> <t><figure align="left"> <artwork>numbered="true" toc="default"> <name>SRH Processing</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 theRoutingrouting 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. }</artwork> </figure></t>]]></artwork> <section anchor="TLVPROCESS"title="TLV Processing">numbered="true" toc="default"> <name>TLV Processing</name> <t>Local configuration determines how TLVs are to be processed when the Active Segment is a local SID defined in this document. The definition of local configuration is outside the scope of this document.</t> <t>For illustrationpurposepurposes only, two example local configurations that may be associated with a SID are provided below.</t><t><figure align="left"> <artwork><artwork name="" type="" align="left" alt=""><![CDATA[ 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}</artwork> </figure></t>}]]></artwork> </section> </section> <section anchor="UPPERHEADER"title="Upper-layernumbered="true" toc="default"> <name>Upper-Layer Header or No NextHeader">Header</name> <t>When processing theUpper-layerupper-layer header of a packet matching a FIB entry locally instantiated as an SRv6 SID defined in thisdocument.</t> <t><figure> <artwork>document:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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(TBD by IANA)(4) "SR Upper-layer Header Error", pointer set to the offset of the upper-layer header. }</artwork> </figure></t>]]></artwork> <t>A unique error code allows an SRSourcesource node to recognize an error in SID processing at an endpoint.</t> </section> </section> <sectiontitle="FIBnumbered="true" toc="default"> <name>FIB Entry IsAa LocalInterface">Interface</name> <t>If the FIB entry represents a localinterface,interface and is not locally instantiated as an SRv6 SID, the SRH is processed asfollows:<list> <t>Iffollows:</t> <ul empty="true" spacing="normal"> <li>If Segments Left is zero, the node must ignore theRoutingrouting header and proceed to process the next header in the packet, whose type is identified by the Next Header field in theRouting Header.</t> <t>Ifrouting header.</li> <li>If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized RoutingType.</t> </list></t>Type.</li> </ul> </section> <sectiontitle="FIBnumbered="true" toc="default"> <name>FIB Entry IsA Non-Local Route">a Nonlocal Route</name> <t>Processing is not changed by this document.</t> </section> <sectiontitle="FIBnumbered="true" toc="default"> <name>FIB Entry IsAa NoMatch">Match</name> <t>Processing is not changed by this document.</t> </section> </section> </section> <section anchor="DEP"title="Intra SR Domainnumbered="true" toc="default"> <name>Intra-SR-Domain DeploymentModel">Model</name> <t>The use of the SIDs exclusively within the SRDomaindomain and solely for packets of the SRDomaindomain is an important deployment model.</t> <t>This enables the SRDomaindomain to act as a single routing system.</t> <t>This sectioncovers:<list style="symbols"> <t>securingcovers:</t> <ul spacing="normal"> <li>securing the SRDomaindomain from externalattemptattempts to use itsSIDs</t> <t>SR DomainSIDs</li> <li>using the SR domain as a single system with delegation betweencomponents</t> <t>handlingcomponents</li> <li>handling packets of the SRDomain</t> </list></t>domain</li> </ul> <section anchor="SECSRDOMAIN"title="Securingnumbered="true" toc="default"> <name>Securing the SRDomain">Domain</name> <t>Nodes outside the SRDomaindomain are not trusted: they cannot directly use the SIDs of the domain. This is enforced by two levels of access control lists:<list style="numbers"></t> <ol spacing="normal" type="1"> <li> <t>Any packet entering the SRDomaindomain and destined to a SID within the SRDomaindomain is dropped. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:<list style="symbols"> <t>allocate</t> <ul spacing="normal"> <li>Allocate all theSID'sSIDs from a blockS/s</t> <t>configureS/s</li> <li>Configure each external interface of each edge node of the domain with an inbound infrastructure access list (IACL)whichthat drops any incoming packet with a destination address inS/s</t> <t>FailureS/s</li> <li>Failure to implement this method of ingress filtering exposes the SRDomaindomain tosource routing attackssource-routing attacks, as described and referenced in <xreftarget="RFC5095"/></t> </list></t>target="RFC5095" format="default"/></li> </ul> </li> <li> <t>The distributed protection in #1 is complemented withper nodeper-node protection, dropping packets to SIDs from source addresses outside the SRDomain.domain. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant:<list style="symbols"> <t>assign</t> <ul spacing="normal"> <li>Assign all interface addresses from prefixA/a</t> <t>atA/a</li> <li>At node k, all SIDs local to k are assigned from prefixSk/sk</t> <t>configureSk/sk</li> <li>Configure each internal interface of each SR node k in the SRDomaindomain with an inbound IACLwhichthat drops any incoming packet with a destination address in Sk/sk if the source address is not inA/a.</t> </list></t> </list></t>A/a.</li> </ul> </li> </ol> </section> <section anchor="SINGLESYS"title="SRnumbered="true" toc="default"> <name>SR Domain asAa Single System with DelegationAmong Components">among Components</name> <t>Allintra SR Domainintra-SR-domain packets are of the SRDomain.domain. The IPv6 header is originated by a node of the SRDomain,domain and is destined to a node of the SRDomain.</t>domain.</t> <t>Allinter domaininterdomain packets are encapsulated for the part of the packet journey that is within the SRDomain.domain. The outer IPv6 header is originated by a node of the SRDomain,domain and is destined to a node of the SRDomain.</t>domain.</t> <t>As a consequence, any packet within the SRDomaindomain is of the SRDomain.</t>domain.</t> <t>The SRDomaindomain is a system in which the operator may want to distribute or delegate different operations of theouter mostoutermost header to different nodes within the system.</t> <t>An operator of an SR domain may choose to delegate SRH addition to a host node within the SRdomain,domain and delegate validation of the contents of any SRH to a more trusted router or switch attached to the host. Consider atop of racktop-of-rack switch(T)T connected to host(H)H via interface(I).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 specificSLA.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 SRDomaindomain (S/s). T checks and verifies that SRH1 isvalid,valid and contains an HMACTLV andTLV; T then verifies the HMAC.</t> <t>An operator of the SRDomaindomain may choose to have all segments in the SRDomaindomain verify the HMAC. This mechanism would verify that the SRHsegment listSegment List is not modified while traversing the SRDomain.</t>domain.</t> </section> <section anchor="MTU"title="MTU Considerations">numbered="true" toc="default"> <name>MTU Considerations</name> <t>An SRDomaindomain ingress edge node encapsulates packets traversing the SRDomain,domain and needs to consider the MTU of the SRDomain.domain. Within the SRDomain, well knowndomain, well-known mitigation techniques areRECOMMENDED,<bcp14>RECOMMENDED</bcp14>, such as deploying a greater MTU value within the SRDomaindomain than at the ingress edges.</t> <t>Encapsulation with an outer IPv6 header and SRHshareshares the same MTU and fragmentation considerations as IPv6 tunnels described in <xreftarget="RFC2473"/>.target="RFC2473" format="default"/>. Further investigation on the limitation of various tunneling methods (including IPv6 tunnels)areis discussed in <xreftarget="I-D.ietf-intarea-tunnels"/>target="I-D.ietf-intarea-tunnels" format="default"/> andSHOULD<bcp14>SHOULD</bcp14> be considered by operators when considering MTU within the SRDomain.</t>domain.</t> </section> <section anchor="ICMP"title="ICMPnumbered="true" toc="default"> <name>ICMP ErrorProcessing">Processing</name> <t>ICMP error packets generated within the SRDomaindomain are sent to source nodes within the SRDomain.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.</t> <t>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 byprotocol error handlers.<list style="symbols">protocol-error handlers.</t> <ul spacing="normal"> <li> <t>Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding theupper layer header.<list style="symbols">upper-layer header.</t> <ul spacing="normal"> <li> <t>If routing header is typeTBD IANA (SRH)<list style="symbols"> <t>The4 Segment Routing Header (SRH)</t> <ul spacing="normal"> <li>The SID at Segment List[0] may be used as the destination address of the invokingpacket.</t> </list></t> </list></t> </list></t>packet.</li> </ul> </li> </ul> </li> </ul> <t>ICMP errors are then processed byupper layerupper-layer transports as defined in <xreftarget="RFC4443"/>.</t>target="RFC4443" format="default"/>.</t> <t>For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in <xreftarget="RFC2473"/>.</t>target="RFC2473" format="default"/>.</t> </section> <section anchor="LBECMP"title="Loadnumbered="true" toc="default"> <name>Load Balancing andECMP">ECMP</name> <t>For anyinter domaininterdomain packet, the SRSourcesource nodeMUST<bcp14>MUST</bcp14> impose a flow label computed based on the inner packet. The computation of the flow label is as recommended in <xreftarget="RFC6438"/>target="RFC6438" format="default"/> for the sending Tunnel End Point.</t> <t>For anyintra domainintradomain packet, the SRSourcesource nodeSHOULD<bcp14>SHOULD</bcp14> impose a flow label computed as described in <xreftarget="RFC6437"/>target="RFC6437" format="default"/> to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH.</t> <t>At any transit node within an SR domain, the flow labelMUST<bcp14>MUST</bcp14> be used as defined in <xreftarget="RFC6438"/>target="RFC6438" format="default"/> 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.</t> <t>At an SR segment endpoint node, the flow labelMUST<bcp14>MUST</bcp14> be used as defined in <xreftarget="RFC6438"/>target="RFC6438" format="default"/> to calculate any ECMP hash used to forward the processed packet to the next segment.</t> </section> <section anchor="other"title="Other Deployments">numbered="true" toc="default"> <name>Other Deployments</name> <t>Other deployment models and their implications on security, MTU, HMAC, ICMP errorprocessingprocessing, and interaction with other extension headers are outside the scope of this document.</t> </section> </section> <section anchor="ILL"title="Illustrations">numbered="true" toc="default"> <name>Illustrations</name> <t>This section provides illustrations of SRv6 packet processing at SR source,transittransit, and SR segment endpoint nodes.</t> <sectiontitle="Abstractnumbered="true" toc="default"> <name>Abstract Representation of anSRH">SRH</name> <t>For a node k, its IPv6 address is represented as Ak, and its SRv6 SID is represented as Sk.</t> <t>IPv6 headers are represented as the tuple of(source, destination).(source,destination). For example, a packet with source address A1 and destination address A2 is represented as (A1,A2). The payload of the packet is omitted.</t> <t>An SR Policy is a list of segments. A list of segments is represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is the second SID tovisitvisit, and S3 is the last SID to visit.</t> <t>(SA,DA)(S3, S2, S1;(S3,S2,S1; SL) represents an IPv6 packetwith:<list style="symbols"> <t>Sourcewith:</t> <ul spacing="normal"> <li>Source AddressisSA, Destination AddressesisDA, andnext-header is SRH.</t> <t>SRHnext header SRH.</li> <li>SRH with SID list<S1, S2, S3><S1,S2,S3> with SegmentsLeft =SL.</t> <t>NoteSL.</li> <li>Note the difference between the <> and () symbols.<S1, S2, S3><S1,S2,S3> represents a SID list where the leftmost segment is the first segment.Whereas, (S3, S2, S1;In contrast, (S3,S2,S1; SL) represents the same SID list but encoded in the SRH Segment List format where the leftmost segment is the last segment. When referring to an SRpolicyPolicy in a high-leveluse-case,use case, it is simpler to use the<S1, S2, S3><S1,S2,S3> notation. When referring to an illustration of detailed behavior, the(S3, S2, S1;(S3,S2,S1; SL) notation is moreconvenient.</t> </list></t>convenient.</li> </ul> <t>At its SR Policy headend, the Segment List <S1,S2,S3> results in SRH (S3,S2,S1; SL=2) represented fully as:<figure align="left"> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ Segments Left=2 Last Entry=2 Flags=0 Tag=0 Segment List[0]=S3 Segment List[1]=S2 SegmentList[2]=S1</artwork> </figure></t>List[2]=S1]]></artwork> </section> <sectiontitle="Example Topology">numbered="true" toc="default"> <name>Example Topology</name> <t>The following topology is used in examples below: </t> <figurealign="center"anchor="TOPO1"><artwork><artwork name="" type="" align="left" alt=""><![CDATA[ + * * * * * * * * * * * * * * * * * * * * + * [8] [9] * | | * | | * [1]----[3]--------[5]----------------[6]---------[4]---[2] * | | * | | * | | * +--------[7]-------+ * * + * * * * * * * SRDomaindomain * * * * * * *+</artwork> </figure><list style="symbols"> <t>3+]]></artwork> </figure> <ul spacing="normal"> <li>3 and 4 are SRDomaindomain edgerouters</t> <t>5,routers</li> <li>5, 6, and 7 are all SRDomain routers</t> <t>8domain routers</li> <li>8 and 9 are hosts within the SRDomain</t> <t>1domain</li> <li>1 and 2 are hosts outside the SRDomain</t> <t>Thedomain</li> <li>The SR domain implements ingress filtering as per <xreftarget="SECSRDOMAIN"/>target="SECSRDOMAIN" format="default"/> and no external packet can enter the domain with a destination address equal to a segment of thedomain.</t> </list></t>domain.</li> </ul> </section> <sectiontitle="Source SR Node">numbered="true" toc="default"> <name>SR Source Node</name> <sectiontitle="Intra SR Domain Packet">numbered="true" toc="default"> <name>Intra-SR-Domain Packet</name> <t>When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the packet is</t> <t>P1: (A8,S7)(A9,S7; SL=1)</t> <sectiontitle="Reduced Variant">numbered="true" toc="default"> <name>Reduced Variant</name> <t>When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it wants to use a reduced SRH, the packet is</t> <t>P2: (A8,S7)(A9; SL=1)</t> </section> </section> <sectiontitle="Inter SR Domainnumbered="true" toc="default"> <name>Inter-SR-Domain Packet- Transit">-- Transit</name> <t>When host 1 sends a packet to host 2, the packet is</t> <t>P3: (A1,A2)</t> <t>The SRDomaindomain ingress router 3 receives P3 and steers it to SRDomaindomain egress router 4 via an SR Policy<S7, S4>.<S7,S4>. Router 3 encapsulates the received packet P3 in an outer header with an SRH. The packet is</t> <t>P4:(A3, S7)(S4, S7; SL=1)(A1, A2)</t>(A3,S7)(S4,S7; SL=1)(A1,A2)</t> <t>If the SR Policy contains only one segment (the egress router 4), the ingressRouterrouter 3 encapsulates P3 into an outer header(A3, S4)(A3,S4) without SRH. The packet is</t> <t>P5:(A3, S4)(A1, A2)</t>(A3,S4)(A1,A2)</t> <sectiontitle="Reduced Variant">numbered="true" toc="default"> <name>Reduced Variant</name> <t>The SRDomaindomain ingress router 3 receives P3 and steers it to SRDomaindomain egress router 4 via an SR Policy<S7, S4>.<S7,S4>. If router 3 wants to use a reduced SRH,Router 3it encapsulates the received packet P3 in an outer header with a reduced SRH. The packet is</t> <t>P6:(A3, S7)(S4; SL=1)(A1, A2)</t>(A3,S7)(S4; SL=1)(A1,A2)</t> </section> </section> <sectiontitle="Inter SR Domainnumbered="true" toc="default"> <name>Inter-SR-Domain Packet--- Internal toExternal">External</name> <t>When host 8 sends a packet to host 1, the packet is encapsulated for the portion of its journey within the SRDomain.domain. From 8 to 3 the packet is</t> <t>P7: (A8,S3)(A8,A1)</t> <t>In the opposite direction, the packet generated from 1 to 8 is</t> <t>P8: (A1,A8)</t> <t>At node33, P8 is encapsulated for the portion of its journey within the SR domain, with the outer header destined to segment S8.ResultingThis results in</t> <t>P9: (A3,S8)(A1,A8)</t> <t>At node88, the outer IPv6 header is removed by S8 processing, then processed again when received by A8.</t> </section> </section> <sectiontitle="Transit Node"> <t>Nodesnumbered="true" toc="default"> <name>Transit Node</name> <t>Node 5 acts as transitnodesnode for packetP1,P1 and sends packet</t> <t>P1: (A8,S7)(A9,S7;SL=1)</t> <t>on the interface toward node 7.</t> </section> <sectiontitle="SRnumbered="true" toc="default"> <name>SR Segment EndpointNode">Node</name> <t>Node 7 receives packet P1 and, using the logic in <xreftarget="pktENDSID"/>,target="pktENDSID" format="default"/>, sends packet</t> <t>P7: (A8,A9)(A9,S7; SL=0)</t> <t>on the interface toward router 6.</t> </section> <sectiontitle="Delegationnumbered="true" toc="default"> <name>Delegation of Function with HMACVerification">Verification</name> <t>This section describes how a function may be delegated within the SRDomain.domain. In the followingsectionssections, consider a host 8 connected to a top of rack 5.</t> <sectiontitle="SIDnumbered="true" toc="default"> <name>SID ListVerification">Verification</name> <t>An operator may prefer to apply the SRH at source 8, while 5 verifies that the SID list is valid.</t> <t>For illustrationpurpose,purposes, an SDN controller provides 8 an SRH terminating at node 9, withsegment listSegment List <S5,S7,S6,A9>, and HMAC TLV computed for the SRH. The HMAC key ID and key associated with the HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is configured with an IACL applied to the interface connected to 8, requiring HMAC verification for any packet destined to S/s.</t> <t>Node 8 originates packets with the receivedSRHSRH, including HMAC TLV.</t><t>P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC)</t><t>P15: (A8,S5)(A9,S6,S7,S5;SL=3;HMAC)</t> <t>Node 5 receives and verifies the HMAC for the SRH, then forwards the packet to the next segment</t><t>P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC)</t><t>P16: (A8,S7)(A9,S6,S7,S5;SL=2;HMAC)</t> <t>Node 6 receives</t><t>P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC)</t><t>P17: (A8,S6)(A9,S6,S7,S5;SL=1;HMAC)</t> <t>Node 9 receives</t><t>P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC)</t><t>P18: (A8,A9)(A9,S6,S7,S5;SL=0;HMAC)</t> <t>This use of an HMAC is particularly valuable within anenterprise basedenterprise-based SRDomaindomain <xreftarget="SRN"/>.</t>target="SRN" format="default"/>.</t> </section> </section> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This section reviews security considerations related to the SRH, given the SRH processing and deployment models discussed in this document.</t> <t>As described in <xreftarget="DEP"/>,target="DEP" format="default"/>, it is necessary to filterpacketspackets' ingress to the SRDomain,domain, destined to SIDs within the SRDomaindomain (i.e., bearing a SID in the destination address). This ingress filtering is via an IACL at SRDomaindomain ingress border nodes. Additional protection is applied via an IACL at each SR Segment Endpoint node, filtering packets not from within the SRDomain,domain, destined to SIDs in the SRDomain.domain. ACLs are easily supported for small numbers of seldom changing prefixes, making summarizationimportant, and when the prefixes requiring filtering is kept to a seldom changing set.</t>important.</t> <t>Additionally, ingress filtering of IPv6 source addresses as recommended inBCP38BCP 38 <xreftarget="RFC2827"/> SHOULDtarget="RFC2827" format="default"/> <bcp14>SHOULD</bcp14> be used.</t> <sectiontitle="Source Routing Attacks">numbered="true" toc="default"> <name>SR Attacks</name> <t>An SR domain implements distributed andper nodeper-node protection as described insection 5.1.<xref target="SECSRDOMAIN"/>. Additionally, domains deny traffic with spoofed addresses by implementing the recommendations in BCP 84 <xreftarget="RFC3704"/>.</t>target="RFC3704" format="default"/>.</t> <t>Full implementation of the recommended protection blocks the attacks documented in <xreftarget="RFC5095"/>target="RFC5095" format="default"/> from outside the SR domain, including bypassing filtering devices, reachingotherwise unreachableotherwise-unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast.</t> <t>Failure to implement distributed andper nodeper-node protection allows attackers to bypass filtering devices and exposes the SRDomaindomain to these attacks.</t> <t>Compromised nodes within the SRDomaindomain may mount the attacks listed above along with other known attacks on IP networks(e.g. DOS/DDOS,(e.g., DoS/DDoS, topology discovery, man-in-the-middle, traffic interception/siphoning).</t> </section> <sectiontitle="Service Theft">numbered="true" toc="default"> <name>Service Theft</name> <t>Service theft is defined as the use of a service offered by the SRDomaindomain by a node not authorized to use the service.</t> <t>Service theft is not a concern within the SRDomaindomain, as all SRSourcesource nodes and SR segment endpoint nodes within the domain are able to utilize the services of theDomain.domain. If a node outside the SRDomaindomain learns of segments or a topological service within the SR domain, IACL filtering denies access to those segments.</t> </section> <sectiontitle="Topology Disclosure">numbered="true" toc="default"> <name>Topology Disclosure</name> <t>The SRH is unencrypted and may contain SIDs of some intermediateSR-nodesSR nodes in the path towards the destination within the SRDomain.domain. If packets can be snooped within the SRDomain,domain, the SRH may reveal topology, traffic flows, and service usage.</t> <t>This is applicable within an SRDomain,domain, but the disclosure is less relevant as an attacker has other means of learning topology, flows, and service usage.</t> </section> <sectiontitle="ICMP Generation">numbered="true" toc="default"> <name>ICMP Generation</name> <t>The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing destination address or SRH in back-to-back packets. An implementation that correctly followsSection 2.4 of<xreftarget="RFC4443"/>target="RFC4443" sectionFormat="of" section="2.4"/> would be protected by the ICMPv6 rate-limiting mechanism.</t> </section> <sectiontitle="Applicabilitynumbered="true" toc="default"> <name>Applicability ofAH">AH</name> <t>The SRDomaindomain is a trusted domain, as defined in <xreftarget="RFC8402"/> Section 2target="RFC8402" format="default"/>, Sections <xref target="RFC8402" section="2" sectionFormat="bare" /> andSection 8.2.<xref target="RFC8402" section="8.2" sectionFormat="bare" />. The SRSourcesource is trusted to add an SRH (optionally verified as having been generated by a trusted source via the HMAC TLV in this document), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane. Assuchsuch, the SRDomaindomain does not rely on the Authentication Header (AH) as defined in <xreftarget="RFC4302"/>target="RFC4302" format="default"/> to secure the SRH.</t> <t>The use of SRH with AH by an SR sourcenode,node and its processing ataan SR segment endpoint nodeisare not defined in this document. Future documents may define use of SRH with AH and its processing.</t> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document makes the following registrations in theInternet"Internet Protocol Version 6 (IPv6)Parameters "Routing Type" registryParameters" "Routing Types" subregistry maintained byIANA:<figure align="center"> <artwork align="left"> Suggested Description Reference Value ---------------------------------------------------------- 4 SegmentIANA:</t> <table anchor="SRH-REG"> <name>SRH Registration</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>4</td> <td>Segment Routing Header(SRH) This document</artwork> </figure></t>(SRH)</td> <td>This document</td> </tr> </tbody> </table> <t>This document makes the following registrations in the "Type 4 - Parameter Problem" message of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained byIANA:<figure align="center"> <artwork align="left"> CODE NAME/DESCRIPTION ---------------------------------------------------------- TBD IANA SRIANA:</t> <table anchor="UPPER-LAYER"> <name>SR Upper-layer HeaderError</artwork> </figure></t> <t>This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the SRH, in accordance with BCP 26, <xref target="RFC8126"/>.</t> <t>The following terms are used here with the meanings defined in BCP 26: "namespace", "assigned value", "registration".</t> <t>The following policies are used here with the meanings defined in BCP 26 <xref target="RFC8126"/>: "IETF Review".</t>Error Registration</name> <thead> <tr> <th>Code</th> <th>Name</th> </tr> </thead> <tbody> <tr> <td>4</td> <td>SR Upper-layer Header Error</td> </tr> </tbody> </table> <section anchor="SRHFLAGSREG"title="Segmentnumbered="true" toc="default"> <name>Segment Routing Header FlagsRegistry">Registry</name> <t>This documentrequests the creation ofdescribes a newIANA managedIANA-managed registry to identify SRH Flags Bits. The registration procedure is "IETFReview". SuggestedReview" <xref target="RFC8126" format="default"/>. The registry name is "Segment Routing Header Flags". Flagsisare 8 bits.</t> </section> <section anchor="SRHTLVREG"title="Segmentnumbered="true" toc="default"> <name>Segment Routing Header TLVsRegistry">Registry</name> <t>This documentrequests the creation ofdescribes a newIANA managedIANA-managed registry to identify SRH TLVs. The registration procedure is "IETF Review".SuggestedThe registry name is "Segment Routing Header TLVs". A TLV is identified through an unsigned8 bit8-bit codepoint value, with assigned values 0-127 for TLVs that do not change enroute,route and 128-255 for TLVs that may change en route. The following codepoints are defined in this document:<figure align="center"> <artwork align="left"> Assigned Description Reference Value ----------------------------------------------------- 0 Pad1 TLV This document 1 Reserved This document 2 Reserved This document 3 Reserved This document 4 PadN TLV This document 5 HMAC TLV This document 6 Reserved This document 124-126 Experimentation and Test This document 127 Reserved This document 252-254 Experimentation and Test This document 255 Reserved This document</artwork> </figure></t></t> <table anchor="TLV-REG"> <name>Segment Routing Header TLVs Registry</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Pad1 TLV</td> <td>This document</td> </tr> <tr> <td>1</td> <td>Reserved</td> <td>This document</td> </tr> <tr> <td>2</td> <td>Reserved</td> <td>This document</td> </tr> <tr> <td>3</td> <td>Reserved</td> <td>This document</td> </tr> <tr> <td>4</td> <td>PadN TLV</td> <td>This document</td> </tr> <tr> <td>5</td> <td>HMAC TLV</td> <td>This document</td> </tr> <tr> <td>6</td> <td>Reserved</td> <td>This document</td> </tr> <tr> <td>124-126</td> <td>Experimentation and Test</td> <td>This document</td> </tr> <tr> <td>127</td> <td>Reserved</td> <td>This document</td> </tr> <tr> <td>252-254</td> <td>Experimentation and Test</td> <td>This document</td> </tr> <tr> <td>255</td> <td>Reserved</td> <td>This document</td> </tr> </tbody> </table> <t>Values1,2,3,61, 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 futurespecificationsspecifications, if needed.</t> </section> </section><section anchor="Implementation" title="Implementation Status"> <t>This section is to be removed prior to publishing as an RFC.</t> <t>See <xref target="I-D.matsushima-spring-srv6-deployment-status"/> for updated deployment and interoperability reports.</t> <section anchor="IMPLINUX" title="Linux"> <t>Name: Linux Kernel v4.14</t> <t>Status: Production</t> <t>Implementation: adds SRH, performs END processing, supports HMAC TLV</t> <t>Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and <xref target="I-D.filsfils-spring-srv6-interop"/></t> </section> <section anchor="IMPCISCO" title="Cisco Systems"> <t>Name: IOS XR and IOS XE</t> <t>Status: Production (IOS XR), Pre-production (IOS XE)</t> <t>Implementation: adds SRH, performs END processing, no TLV processing</t> <t>Details: <xref target="I-D.filsfils-spring-srv6-interop"/></t> </section> <section anchor="IMPFDIO" title="FD.io"> <t>Name: VPP/Segment Routing for IPv6</t> <t>Status: Production</t> <t>Implementation: adds SRH, performs END processing, no TLV processing</t> <t>Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and <xref target="I-D.filsfils-spring-srv6-interop"/></t> </section> <section anchor="IMPBAREFOOT" title="Barefoot"> <t>Name: Barefoot Networks Tofino NPU</t> <t>Status: Prototype</t> <t>Implementation: performs END processing, no TLV processing</t> <t>Details: <xref target="I-D.filsfils-spring-srv6-interop"/></t> </section> <section title="Juniper"> <t>Name: Juniper Networks Trio and vTrio NPU's</t> <t>Status: Prototype & Experimental</t> <t>Implementation: SRH insertion mode, Process SID where SID is an interface address, no TLV processing</t> </section> <section title="Huawei"> <t>Name: Huawei Systems VRP Platform</t> <t>Status: Production</t> <t>Implementation: adds SRH, performs END processing, no TLV processing</t> </section> </section> <section anchor="Contributors" title="Contributors"> <t>Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James Connolly, Aloys Augustin contributed to the content of this document.</t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> <t>The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kuhlewind, Roman Danyliw, Joe Touch, and Magnus Westerlund for their comments to this document.</t> </section></middle> <back><references title="Normative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8200.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5095.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6407.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6438.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6437.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml"?><displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5095.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6407.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"/> <reference anchor="FIPS180-4" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf"> <front><title>FIPS 180-4 Secure<title>Secure Hash Standard (SHS)</title> <author> <organization>National Institute of Standards andTechnology</organization>Technology (NIST)</organization> </author> <datemonth="March" year="2012"/>month="August" year="2015"/> </front> <refcontent>FIPS PUB 180-4</refcontent> <refcontent>DOI 10.6028/NIST.FIPS.180-4</refcontent> </reference> <reference anchor="IANA-SRHTLV" target="https://www.iana.org/assignments/ipv6-parameters/"> <front> <title>Segment Routing Header TLVs</title> <author> <organization>IANA</organization> </author> </front> </reference> </references><references title="Informative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"?> <?rfc include="reference.I-D.filsfils-spring-srv6-interop.xml"?> <?rfc include="reference.I-D.ietf-intarea-tunnels.xml"?> <?rfc include="reference.I-D.matsushima-spring-srv6-deployment-status.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml"?><references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <!-- I-D.draft-ietf-intarea-tunnels-10; IESG state I-D Exists --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-intarea-tunnels-10.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <reference anchor="SRN" target="https://inl.info.ucl.ac.be/system/files/sosr18-final15-embedfonts.pdf"> <front> <title>Software Resolved Networks: Rethinking Enterprise Networks with IPv6 Segment Routing</title> <author fullname="David Lebrun"/> <author fullname="Mathieu Jadin"/> <author fullname="Francois Clad"/> <author fullname="Clarence Filsfils"/> <author fullname="Olivier Bonaventure"/> <date year="2018"/> </front> </reference> </references> </references> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thank <contact fullname="Ole Troan"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Fred Baker"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Alexandru Petrescu"/>, <contact fullname="Punit Kumar Jaiswal"/>, <contact fullname="David Lebrun"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Frank Xialiang"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Joe Touch"/>, and <contact fullname="Magnus Westerlund"/> for their comments to this document.</t> </section> <section anchor="Contributors" numbered="false" toc="default"> <name>Contributors</name> <t><contact fullname="Kamran Raza"/>, <contact fullname="Zafar Ali"/>, <contact fullname="Brian Field"/>, <contact fullname="Daniel Bernier"/>, <contact fullname="Ida Leung"/>, <contact fullname="Jen Linkova"/>, <contact fullname="Ebben Aries"/>, <contact fullname="Tomoya Kosugi"/>, <contact fullname="Eric Vyncke"/>, <contact fullname="David Lebrun"/>, <contact fullname="Dirk Steinberg"/>, <contact fullname="Robert Raszuk"/>, <contact fullname="Dave Barach"/>, <contact fullname="John Brzozowski"/>, <contact fullname="Pierre Francois"/>, <contact fullname="Nagendra Kumar"/>, <contact fullname="Mark Townsley"/>, <contact fullname="Christian Martin"/>, <contact fullname="Roberta Maglione"/>, <contact fullname="James Connolly"/>, and <contact fullname="Aloys Augustin"/> contributed to the content of this document.</t> </section> </back> </rfc>