<?xml version="1.0"encoding="US-ASCII"?> <!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"><!ENTITYRFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">nbsp " "> <!ENTITYRFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">zwsp "​"> <!ENTITYRFC8200 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">nbhy "‑"> <!ENTITYRFC8250 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml"> <!ENTITY RFC5036 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"> <!ENTITY RFC4193 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"> <!ENTITY RFC1772 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1772.xml"> <!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"> <!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"> <!ENTITY RFC9098 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"> <!ENTITY RFC9326 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="no"?> <?rfc tocdepth="3"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-ippm-ioam-ipv6-options-12"ipr="trust200902">number="9486" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <titleabbrev="In-situ OAM IPv6 encapsulation">In-situ OAMabbrev="IOAM IPv6Options</title>Options">IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)</title> <seriesInfo name="RFC" value="9486"/> <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari" role="editor"> <organization abbrev="Thoughtspot">Thoughtspot</organization> <address> <postal><street>3rd<extaddr>3rd Floor, IndiqubeOrion, 24thOrion</extaddr> <street>24th Main Rd, Garden Layout, HSR Layout</street><city>Bangalore, KARNATAKA 560 102</city><city>Bangalore</city> <region>Karnataka</region> <code>560 102</code> <country>India</country> </postal> <email>shwetha.bhandari@thoughtspot.com</email> </address> </author> <author fullname="Frank Brockners" initials="F." surname="Brockners" role="editor"> <organization abbrev="Cisco">Cisco Systems, Inc.</organization> <address> <postal> <street>Hansaallee 249, 3rd Floor</street><!-- Reorder these if your country does things differently --> <city>DUESSELDORF</city><city>Duesseldorf</city> <code>40549</code> <country>Germany</country> </postal> <email>fbrockne@cisco.com</email><!-- uri and facsimile elements may also be added --></address> </author> <dateday="7" month="May"month="September" year="2023"/><area>Transport Area</area><area>tsv</area> <workgroup>ippm</workgroup> <keyword></keyword> <abstract><t>In-situ<t>In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAMdata fieldsData-Fields are encapsulated in IPv6.</t> </abstract> </front> <middle> <sectiontitle="Introduction"> <t>In-situnumbered="true" toc="default"> <name>Introduction</name> <t>In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. IOAM concepts and associatednomenclature,nomenclature as well as IOAMdata fieldsData-Fields are defined in <xreftarget="RFC9197"/>.target="RFC9197" format="default"/>. This document outlines how IOAMdata fieldsData-Fields are encapsulated in IPv6 <xreftarget="RFC8200"/>target="RFC8200" format="default"/> and discusses deployment requirements for networks that use IPv6-encapsulated IOAMdata fields.</t>Data-Fields.</t> <t>The terms "encapsulation" and "decapsulation" are used in this document in the same way as in <xreftarget="RFC9197"/>:target="RFC9197" format="default"/>: An IOAM encapsulating node incorporates one or moreIOAM-Option-TypesIOAM Option-Types intopackets. Anpackets that IOAMdecapsulating node removes IOAM-Option-Type(s) from packets.</t>is enabled for.</t> </section> <sectiontitle="Conventions">numbered="true" toc="default"> <name>Conventions</name> <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> <sectiontitle="Abbreviations">numbered="true" toc="default"> <name>Abbreviations</name> <t>Abbreviations used in this document:</t><t><list hangIndent="11" style="hanging"> <t hangText="E2E:">Edge-to-Edge</t> <t hangText="IOAM:">In-situ<dl newline="false" spacing="normal" indent="11"> <dt>E2E:</dt> <dd>Edge-to-Edge</dd> <dt>IOAM:</dt> <dd>In situ Operations, Administration, and Maintenance as defined in <xreftarget="RFC9197"/></t> <t hangText="OAM:">Operations,target="RFC9197" format="default"/></dd> <dt>OAM:</dt> <dd>Operations, Administration, andMaintenance</t> <t hangText="POT:">ProofMaintenance</dd> <dt>POT:</dt> <dd>Proof ofTransit</t> </list></t>Transit</dd> </dl> </section> </section> <sectiontitle="In-situnumbered="true" toc="default"> <name>In situ OAM Metadata Transport inIPv6">IPv6</name> <t>IOAM in IPv6 is used to enhance diagnostics of IPv6 networks. It complements other mechanisms designed to enhance diagnostics of IPv6 networks, such as theIPv6"IPv6 Performance and Diagnostic Metrics (PDM) DestinationOptionOption" described in <xreftarget="RFC8250"/>.</t>target="RFC8250" format="default"/>.</t> <t> At the time this document was written, several implementations of IOAM for IPv6 exist, e.g., IOAM for IPv6 in the Linux Kernel (supported from Kernel version 5.15onwardsonward, <eref target="https://github.com/torvalds/linux/commit/7c804e91df523a37c29e183ea2b10ac73c3a4f3d"> IPv6 IOAM in LinuxKernel</eref>),Kernel</eref>) and <eref target="https://docs.fd.io/vpp/17.04/ioam_ipv6_doc.html"> IOAM for IPv6 inVPP </eref>.Vector Packet Processing (VPP)</eref>. </t> <t>IOAMdata fieldsData-Fields can be encapsulated with two types of extension headers in IPv6 packets--- either the hop-by-hop options header or the destination options header. Multiple options with the same option typeMAY<bcp14>MAY</bcp14> appear in the same hop-by-hop options or destination optionsheader,header with distinct content.</t> <t>An IPv6 packet carrying IOAM data in an extension header can have other extension headers, compliant with <xreftarget="RFC8200"/>.</t> <t>IPv6 hop-by-hoptarget="RFC8200" format="default"/>.</t> <figure> <name>IPv6 Hop-by-Hop anddestination option formatDestination Option Format forcarryingCarrying IOAMdata fields:<figure> <artwork><![CDATA[Data-Fields</name> <artwork name="" type="" align="center" alt=""><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option TypeOption-Type | Opt Data Len | Reserved |IOAM-Opt-TypeIOAM Opt-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | | . . I . . O . . A . . M . . . . Option Data . O . . P . . T . . I . . O . . N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ ]]></artwork></figure></t> <t><list style="hanging"> <t hangText="Option Type:">8-bit</figure> <dl newline="false" spacing="normal"> <dt>Option-Type:</dt> <dd>8-bit option type identifier as defined in <xreftarget="IANA"/>.</t> <t hangText="Opttarget="IANA" format="default"/>.</dd> <dt>Opt DataLen:">8-bitLen:</dt> <dd>8-bit unsigned integer. Length of this option, in octets, not including the first 2octets.</t> <t hangText="Reserved:">8-bitoctets.</dd> <dt>Reserved:</dt> <dd>8-bit fieldMUST<bcp14>MUST</bcp14> be set to zero by thesource.</t> <t hangText="IOAM-Option-Type:"> Abbreviatedsource.</dd> <dt>IOAM Option-Type:</dt> <dd>Abbreviated to"IOAM-Opt-Type""IOAM Opt-Type" in the diagram above: 8-bit field as defined insection 4.1 of<xreftarget="RFC9197"/>.</t> <t hangText="Option Data:">Variable-lengthtarget="RFC9197" section="4.1" sectionFormat="of"/>.</dd> <dt>Option Data:</dt> <dd><t>Variable-length field.Option-Type-specific data.</t> </list></t> <t>IOAM OptionThe data isinsertedspecific to the Option-Type, asfollows:<list style="numbers"> <t>Pre-allocateddetailed below.</t> <dl newline="false" spacing="normal"> <dt>Pre-allocated TraceOption: TheOption:</dt> <dd> <t>The IOAMPreallocatedPre-allocated TraceOption-TypeOption-Type, defined inSection 4.4 of<xreftarget="RFC9197"/>target="RFC9197" section="4.4" sectionFormat="of"/>, is represented as an IPv6 option in the hop-by-hop extensionheader: <list style="hanging"> <t hangText="Option Type:">TBD_1_1 8-bitheader:</t> <dl newline="false" spacing="normal"> <dt>Option-Type:</dt> <dd>0x31 (8-bit identifier of the IPv6Option TypeOption-Type forIOAM.</t> <t hangText="IOAM Type:">IOAMIOAM).</dd> <dt>IOAM Type:</dt> <dd>IOAM Pre-allocated TraceOption-Type.</t> </list></t> <t>ProofOption-Type.</dd> </dl> </dd> <dt>Proof of TransitOption: TheOption-Type:</dt> <dd> <t>The IOAM POTOption-TypeOption-Type, defined inSection 4.5 of<xreftarget="RFC9197"/>target="RFC9197" section="4.5" sectionFormat="of"/>, is represented as an IPv6 option in the hop-by-hop extensionheader: <list style="hanging"> <t hangText="Option Type:">TBD_1_1 8-bitheader:</t> <dl newline="false" spacing="normal"> <dt>Option-Type:</dt> <dd>0x31 (8-bit identifier of the IPv6Option TypeOption-Type forIOAM.</t> <t hangText="IOAM Type:">IOAMIOAM).</dd> <dt>IOAM Type:</dt> <dd>IOAM POTOption-Type.</t> </list></t> <t>Edge to Edge Option: TheOption-Type.</dd> </dl> </dd> <dt>Edge-to-Edge Option:</dt> <dd> <t>The IOAM E2EoptionOption, defined inSection 4.6<xreftarget="RFC9197"/>target="RFC9197" section="4.6" sectionFormat="of"/>, is represented as an IPv6 option in destination extension header:<list style="hanging"> <t hangText="Option Type:">TBD_1_0 8-bit</t> <dl newline="false" spacing="normal"> <dt>Option-Type:</dt> <dd>0x11 (8-bit identifier of the IPv6Option TypeOption-Type forIOAM.</t> <t hangText="IOAM Type:">IOAMIOAM).</dd> <dt>IOAM Type:</dt> <dd>IOAM E2EOption-Type.</t> </list></t> <t>DirectOption-Type.</dd> </dl> </dd> <dt>Direct Export (DEX)Option: TheOption:</dt> <dd> <t>The IOAM Direct ExportOption-TypeOption-Type, defined inSection 3.2 of<xreftarget="RFC9326"/>target="RFC9326" section="3.2" sectionFormat="of"/>, is represented as an IPv6 option in the hop-by-hop extensionheader: <list style="hanging"> <t hangText="Option Type:">TBD_1_0 8-bitheader:</t> <dl newline="false" spacing="normal"> <dt>Option-Type:</dt> <dd>0x11 (8-bit identifier of the IPv6Option TypeOption-Type forIOAM.</t> <t hangText="IOAM Type:">IOAMIOAM).</dd> <dt>IOAM Type:</dt> <dd>IOAM Direct Export (DEX)Option-Type.</t> </list></t> </list>AllOption-Type.</dd> </dl> </dd> </dl> </dd> </dl> <t>All the IOAM IPv6 options defined here have alignment requirements. Specifically, they all require4n alignment.alignment on multiples of 4 bytes. This ensures that fields specified in <xreftarget="RFC9197"/>target="RFC9197" format="default"/> are aligned at a multiple-of-4 offset from the start of the hop-by-hop and destination options header.</t> <t>IPv6 options can have a maximum length of 255 octets. Consequently, the total length of IOAM Option-Types including all data fields is also limited to 255 octets when encapsulated into IPv6.</t> </section> <sectiontitle="IOAMnumbered="true" toc="default"> <name>IOAM DeploymentInin IPv6Networks"> <t/>Networks</name> <section anchor="v6_requirement"title="Considerationsnumbered="true" toc="default"> <name>Considerations for IOAMdeploymentDeployment andimplementationImplementation in IPv6networks">Networks</name> <t>IOAM deployments in IPv6 networksMUST<bcp14>MUST</bcp14> take the following considerations and requirements intoaccount:<list style="hanging"> <t hangText="C1">account.</t> <ol type="C%d:"> <li> IOAMMUST<bcp14>MUST</bcp14> be deployed in an IOAM-Domain. An IOAM-Domain is a set of nodes that use IOAM. An IOAM-Domain is bounded by its perimeter or edge. The set of nodes forming an IOAM-Domain may be connected to the same physical infrastructure (e.g., a service provider's network). They may also be remotely connected to each other (e.g., an enterprise VPN or an overlay). It is expected that all nodes in an IOAM-Domain are managed by the same administrative entity. Please refer to <xreftarget="RFC9197"/>)target="RFC9197" format="default"/> for more details on IOAM-Domains.</t> <t hangText="C2">Implementations</li> <li> Implementations of IOAMMUST<bcp14>MUST</bcp14> ensure that the addition of IOAMdata fieldsData-Fields does not alter the way routers forward packets or the forwarding decisions they make. Packets with added IOAM information must follow the same path within the domain as an identical packet without IOAM information would, even in the presence of Equal-CostMulti-PathMultipath (ECMP). This behavior is important for deployments where IOAMdata fieldsData-Fields are only added "on-demand". Implementations of IOAMMUST<bcp14>MUST</bcp14> ensure that ECMP behavior for packets with and without IOAMdata fieldsData-Fields is the same. In order for IOAM to work in IPv6 networks, IOAMMUST<bcp14>MUST</bcp14> be explicitly enabled per interface on every node within theIOAM domain.IOAM-Domain. Unless a particular interface is explicitly enabled (i.e., explicitly configured) for IOAM, a routerMUST<bcp14>MUST</bcp14> ignore IOAM Options.</t> <t hangText="C3"></li> <li> In order to maintain the integrity of packets in anIOAM domain,IOAM-Domain, the Maximum Transmission Unit (MTU) of transit routers and switches must be configured to a value that does not lead to anICMP"ICMP Packet TooBigBig" error message being sent to the originator and the packet being dropped. The PMTU tolerance range must beidentifiedidentified, and IOAM encapsulation operations or data field insertion must not exceed this range. Control of the MTU is critical to the proper operation of IOAM. The PMTU tolerance must be identified throughconfigurationconfiguration, and IOAM operations must not exceed the packet size beyondPMTU.</t> <t hangText="C4">PMTU. </li> <li> <xreftarget="RFC8200"/>target="RFC8200" format="default"/> precludes insertion of IOAM data directly into the original IPv6 header of in-flight packets. IOAM deploymentswhichthat do not encapsulate/decapsulate IOAM on the host but desire to encapsulate/decapsulate IOAM on transit nodesMUST<bcp14>MUST</bcp14> add an additional IPv6 header to the original packet. IOAM data is added to this additional IPv6 header.</t> </list></t></li> </ol> </section> <sectiontitle="IOAM domains boundednumbered="true" toc="default"> <name>IOAM-Domains Bounded byhosts">Hosts</name> <t>For deployments where theIOAM domainIOAM-Domain is bounded by hosts, hosts will perform the operation of IOAMdata fieldData-Field encapsulation and decapsulation, i.e., hosts will place the IOAMdata fieldsData-Fields directly in the IPv6 header or remove the IOAMdata fieldsData-Fields directly from the IPv6 header. IOAM data is carried in IPv6 packets as hop-by-hop or destination options as specified in this document.</t> </section> <sectiontitle="IOAM domains boundednumbered="true" toc="default"> <name>IOAM-Domains Bounded bynetwork devices">Network Devices</name> <t>For deployments where theIOAM domainIOAM-Domain is bounded by network devices, network devices such as routers form the edge of anIOAM domain.IOAM-Domain. Network devices will perform the operation of IOAMdata fieldData-Field encapsulation and decapsulation. Network devices will encapsulate IOAMdata fieldsData-Fields in an additional, outer, IPv6 headerwhichthat carries the IOAMdata fields.</t>Data-Fields.</t> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document describes the encapsulation of IOAMdata fieldsData-Fields in IPv6. For general IOAM security considerations, see <xreftarget="RFC9197"/>.target="RFC9197" format="default"/>. Security considerations of the specific IOAMdata fieldsData-Fields for each case (i.e., Trace,Proof of Transit,POT, and E2E) are also described and defined in <xreftarget="RFC9197"/>.</t>target="RFC9197" format="default"/>.</t> <t>As this document describes new options for IPv6, the security considerations of <xreftarget="RFC8200"/>target="RFC8200" format="default"/> and <xreftarget="RFC8250"/>target="RFC8250" format="default"/> apply.</t> <t>From a network-protection perspective, there is an assumed trust model such that any node that adds IOAM to a packet, removes IOAM from a packet, or modifies IOAMdata fieldsData-Fields of a packet is assumed to be allowed to do so. By default, packets that include IPv6 extension headers with IOAM informationMUST NOT<bcp14>MUST NOT</bcp14> be leaked through the boundaries of the IOAM-Domain.</t> <t>IOAM-Domain boundary routersMUST<bcp14>MUST</bcp14> filter any incoming traffic from outside the IOAM-Domain that contains IPv6 extension headers with IOAM information. IOAM-Domain boundary routersMUST<bcp14>MUST</bcp14> also filter any outgoing traffic leaving the IOAM-Domain that contains IPv6 extension headers with IOAM information.</t> <t>In the general case, an IOAM node only adds, removes, or modifies an IPv6 extension header with IOAM information, if the directive to do so comes from a trusted source and the directive is validated.</t> <t>Problems may occur if the above behaviors are not implemented or if the assumed trust model is violated (e.g., through a security breach). In addition to the security considerations discussed in <xreftarget="RFC9197"/>,target="RFC9197" format="default"/>, the security considerations associated with IPv6 extension headers listed in <xreftarget="RFC9098"/>target="RFC9098" format="default"/> apply.</t> <sectiontitle="Applicabilitynumbered="true" toc="default"> <name>Applicability ofAH">Authentication Header (AH)</name> <t> The network devices in an IOAM-Domain are trusted to add,updateupdate, and remove IOAM options according to the constraints specified in <xreftarget="RFC8200"/>. IOAM domaintarget="RFC8200" format="default"/>. IOAM-Domain does not rely on theAuthentication Header (AH)AH as defined in <xreftarget="RFC4302"/>target="RFC4302" format="default"/> to secure IOAM options. The use of IOAM options with AH and its processingisare not defined in this document. Future documents may define the use of IOAM with AH and its processing.</t> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t>This draft requestsnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has assigned thefollowingIPv6Option Type assignmentsOption-Types from thedestination options"Destination Options andhop-by-hop options sub-registryHop-by-Hop Options" subregistry ofInternet"Internet Protocol Version 6 (IPv6)Parameters.</t> <t>http://www.iana.org/assignments/ipv6-parameters/ipv6- parameters.xhtml#ipv6-parameters-2</t> <t><figure> <artwork><![CDATA[ Hex Value Binary Value Description Reference act chg rest ------------------------------------------------------------------ TBD_1_0 00 0 TBD_1 IOAM [This draft] destination optionParameters" <eref target="https://www.iana.org/assignments/ipv6-parameters/" brackets="angle"/>.</t> <table> <thead> <tr> <th rowspan="2">Hex Value</th> <th colspan="3">Binary Value</th> <th rowspan="2">Description</th> <th rowspan="2">Reference</th> </tr> <tr> <th>act</th> <th>chg</th> <th>rest</th> </tr> </thead> <tbody> <tr> <td>0x11</td> <td>00</td> <td>0</td> <td>10001</td> <td>IOAM Destination Option and IOAMhop-by-hop option TBD_1_1 00 1 TBD_1 IOAM [This draft] destination optionHop-by-Hop Option</td> <td>RFC 9486</td> </tr> <tr> <td>0x31</td> <td>00</td> <td>1</td> <td>10001</td> <td>IOAM Destination Option and IOAMhop-by-hop option ]]></artwork> </figure></t>Hop-by-Hop Option</td> <td>RFC 9486</td> </tr> </tbody> </table> </section> </middle> <back> <displayreference target="I-D.kitamura-ipv6-record-route" to="IPV6-RECORD-ROUTE"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.kitamura-ipv6-record-route.xml"/> </references> </references> <sectiontitle="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thankTom Herbert, Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan<contact fullname="Tom Herbert"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Nalini Elkins"/>, <contact fullname="Srihari Raghavan"/>, <contact fullname="Ranganathan TS, KarthikS"/>, <contact fullname="Karthik Babu HarichandraBabu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, Mark Smith, Andrew Yourtchenko and Justin IurmanBabu"/>, <contact fullname="Akshaya Nadahalli"/>, <contact fullname="Stefano Previdi"/>, <contact fullname="Hemant Singh"/>, <contact fullname="Erik Nordmark"/>, <contact fullname="LJ Wobker"/>, <contact fullname="Mark Smith"/>, <contact fullname="Andrew Yourtchenko"/>, and <contact fullname="Justin Iurman"/> for the comments and advice. For the IPv6 encapsulation, this document leverages concepts described in <xreftarget="I-D.kitamura-ipv6-record-route"/>.target="I-D.kitamura-ipv6-record-route" format="default"/>. The authors would like to acknowledge the work done by the authorHiroshi Kitamura<contact fullname="Hiroshi Kitamura"/> and people involved in writing it.</t> </section><!----> <!-- --> </middle> <back> <references title="Normative References"> &RFC2119; &RFC8174; &RFC9197; &RFC9326; </references> <references title="Informative References"> &RFC8200; &RFC8250; &RFC4302; &RFC9098; <reference anchor="I-D.kitamura-ipv6-record-route"> <front> <title>Record Route for IPv6 (PR6) Hop-by-Hop Option Extension</title> <author fullname="Hiroshi Kitamura" initials="H" surname="Kitamura"/> <date month="November" year="2000"/> </front> <seriesInfo name="Internet-Draft" value="draft-kitamura-ipv6-record-route-00"/> <format target="https://tools.ietf.org/id/draft-kitamura-ipv6-record-route-00.txt" type="TXT"/> </reference> </references><sectionnumbered="no" title="Contributors">numbered="false" toc="default"> <name>Contributors</name> <t>This document was the collective effort of several authors. The text and content were contributed by the editors and theco-authorscoauthors listedbelow. The contact information of the co-authors appears at the end of this document.</t> <t><list style="symbols"> <t>Carlos Pignataro</t> <t>Hannes Gredler</t> <t>John Leddy</t> <t>Stephen Youell</t> <t>Tal Mizrahi</t> <t>Aviv Kfir</t> <t>Barak Gafni</t> <t>Petr Lapukhov</t> <t>Mickey Spiegel</t> <t>Suresh Krishnan</t> <t>Rajiv Asati</t> <t>Mark Smith</t> </list></t> </section> <section numbered="no" title="Contributors' Addresses"> <t><figure> <artwork><![CDATA[ Carlos Pignataro Ciscobelow.</t> <contact fullname="Carlos Pignataro"> <organization>Cisco Systems,Inc. 7200-11Inc.</organization> <address> <postal> <street>7200-11 Kit CreekRoad ResearchRoad</street> <city>Research TrianglePark, NC 27709 UnitedPark</city> <region>NC</region><code>27709</code> <country>United StatesEmail: cpignata@cisco.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com John Leddy Email: john@leddy.net Stephen Youell JPof America</country> </postal> <email>cpignata@cisco.com</email> </address> </contact> <contact fullname="Hannes Gredler"> <organization>RtBrick Inc.</organization> <address> <email>hannes@rtbrick.com</email> </address> </contact> <contact fullname="John Leddy"> <address> <email>john@leddy.net</email> </address> </contact> <contact fullname="Stephen Youell"> <organization>JP MorganChase 25Chase</organization> <address> <postal> <street>25 BankStreet London E14 5JP United Kingdom Email: stephen.youell@jpmorgan.com Tal Mizrahi HuaweiStreet</street> <city>London</city><code>E14 5JP</code> <country>United Kingdom</country> </postal> <email>stephen.youell@jpmorgan.com</email> </address> </contact> <contact fullname="Tal Mizrahi"> <organization>Huawei Network.IO InnovationLab Israel Email: tal.mizrahi.phd@gmail.com Aviv Kfir MellanoxLab</organization> <address> <postal> <country>Israel</country> </postal> <email>tal.mizrahi.phd@gmail.com</email> </address> </contact> <contact fullname="Aviv Kfir"> <organization>Mellanox Technologies,Inc. 350Inc.</organization> <address> <postal> <street>350 Oakmead Parkway, Suite100 Sunnyvale, CA 94085 U.S.A. Email: avivk@mellanox.com Barak Gafni Mellanox100</street> <city>Sunnyvale</city> <region>CA</region><code>94085</code> <country>United States of America</country> </postal> <email>avivk@mellanox.com</email> </address> </contact> <contact fullname="Barak Gafni"> <organization>Mellanox Technologies,Inc. 350Inc.</organization> <address> <postal> <street>350 Oakmead Parkway, Suite100 Sunnyvale, CA 94085 U.S.A. Email: gbarak@mellanox.com Petr Lapukhov Facebook 1100</street> <city>Sunnyvale</city><region>CA</region><code>94085</code> <country>United States of America</country> </postal> <email>gbarak@mellanox.com</email> </address> </contact> <contact fullname="Petr Lapukhov"> <organization>Facebook</organization> <address> <postal> <street>1 HackerWay Menlo Park, CA 94025 US Email: petr@fb.com Mickey Spiegel BarefootWay</street> <city>Menlo Park</city><region>CA</region><code>94025</code> <country>United States of America</country> </postal> <email>petr@fb.com</email> </address> </contact> <contact fullname="Mickey Spiegel"> <organization>Barefoot Networks, an Intelcompany 4750company</organization> <address> <postal> <street>4750 Patrick HenryDrive Santa Clara, CA 95054 US Email: mickey.spiegel@intel.com Suresh Krishnan Kaloom Email: suresh@kaloom.com Rajiv Asati CiscoDrive</street> <city>Santa Clara</city><region>CA</region><code>95054</code> <country>United States of America</country> </postal> <email>mickey.spiegel@intel.com</email> </address> </contact> <contact fullname="Suresh Krishnan"> <organization>Kaloom</organization> <address> <email>suresh@kaloom.com</email> </address> </contact> <contact fullname="Rajiv Asati"> <organization>Cisco Systems,Inc. 7200Inc.</organization> <address> <postal> <street>7200 Kit CreekRoad ResearchRoad</street> <city>Research TrianglePark, NC 27709 US Email: rajiva@cisco.com Mark Smith POPark</city><region>NC</region><code>27709</code> <country>United States of America</country> </postal> <email>rajiva@cisco.com</email> </address> </contact> <contact fullname="Mark Smith"> <address> <postal> <street>PO BOX521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith+id@gmail.com ]]></artwork> </figure></t>521</street> <city>Heidelberg</city><region>VIC</region><code>3084</code> <country>Australia</country> </postal> <email>markzzzsmith+id@gmail.com</email> </address> </contact> </section> </back> </rfc>