rfc9486xml2.original.xml   rfc9486.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (priva
te) -->
<!DOCTYPE rfc SYSTEM "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/referen
ce.RFC.2119.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2784.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8200 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8200.xml">
<!ENTITY RFC8250 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8250.xml">
<!ENTITY RFC5036 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5036.xml">
<!ENTITY RFC4193 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4193.xml">
<!ENTITY RFC1772 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1772.xml">
<!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9197.xml">
<!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4302.xml">
<!ENTITY RFC9098 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9098.xml">
<!ENTITY RFC9326 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9326.xml">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-ietf-ippm-ioam-ipv6-options-12"
ipr="trust200902">
<front>
<title abbrev="In-situ OAM IPv6 encapsulation">In-situ OAM IPv6
Options</title>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
std" consensus="true" docName="draft-ietf-ippm-ioam-ipv6-options-12" number="948
6" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" toc
Depth="3" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="IOAM IPv6 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="e ditor"> <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari" role="e ditor">
<organization abbrev="Thoughtspot">Thoughtspot</organization> <organization abbrev="Thoughtspot">Thoughtspot</organization>
<address> <address>
<postal> <postal>
<street>3rd Floor, Indiqube Orion, 24th Main Rd, Garden Lay <extaddr>3rd Floor, Indiqube Orion</extaddr>
out, HSR Layout</street> <street>24th Main Rd, Garden Layout, HSR Layout</street>
<city>Bangalore, KARNATAKA 560 102</city> <city>Bangalore</city>
<country>India</country> <region>Karnataka</region>
</postal> <code>560 102</code>
<email>shwetha.bhandari@thoughtspot.com</email> <country>India</country>
</address> </postal>
<email>shwetha.bhandari@thoughtspot.com</email>
</address>
</author> </author>
<author fullname="Frank Brockners" initials="F." surname="Brockners" role="e ditor"> <author fullname="Frank Brockners" initials="F." surname="Brockners" role="e ditor">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Hansaallee 249, 3rd Floor</street> <street>Hansaallee 249, 3rd Floor</street>
<city>Duesseldorf</city>
<!-- Reorder these if your country does things differently -->
<city>DUESSELDORF</city>
<code>40549</code> <code>40549</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>fbrockne@cisco.com</email> <email>fbrockne@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date month="September" year="2023"/>
<date day="7" month="May" year="2023"/> <area>tsv</area>
<area>Transport Area</area>
<workgroup>ippm</workgroup> <workgroup>ippm</workgroup>
<keyword></keyword>
<abstract> <abstract>
<t>In-situ Operations, Administration, and Maintenance (IOAM) records <t>In situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
outlines how IOAM data fields are encapsulated in IPv6.</t> outlines how IOAM Data-Fields are encapsulated in IPv6.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>In-situ Operations, Administration, and Maintenance (IOAM) records <name>Introduction</name>
<t>In situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. IOAM concepts traverses a path between two points in the network. IOAM concepts and
and associated nomenclature, as well as IOAM data fields are associated nomenclature as well as IOAM Data-Fields are defined in <xref
defined in <xref target="RFC9197"/>. target="RFC9197" format="default"/>. This document outlines how IOAM
This document outlines how IOAM data fields are encapsulated in IPv6 <xref Data-Fields are encapsulated in IPv6 <xref target="RFC8200"
target="RFC8200"/> and discusses deployment requirements for networks that format="default"/> and discusses deployment requirements for networks
use IPv6-encapsulated IOAM data fields.</t> that use IPv6-encapsulated IOAM Data-Fields.</t>
<t>The terms "encapsulation" and "decapsulation" are used in this document <t>The terms "encapsulation" and "decapsulation" are used in this
in the same way as in <xref target="RFC9197"/>: document in the same way as in <xref target="RFC9197" format="default"/>:
An IOAM encapsulating node incorporates one or more IOAM-Option-Types An IOAM encapsulating node incorporates one or more IOAM Option-Types
into packets. An IOAM decapsulating node removes IOAM-Option-Type(s) into packets that IOAM is enabled for.</t>
from packets.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions</name>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Conventions">
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t>Abbreviations used in this document:</t> <t>Abbreviations used in this document:</t>
<dl newline="false" spacing="normal" indent="11">
<t><list hangIndent="11" style="hanging"> <dt>E2E:</dt>
<t hangText="E2E:">Edge-to-Edge</t> <dd>Edge-to-Edge</dd>
<dt>IOAM:</dt>
<t hangText="IOAM:">In-situ Operations, Administration, and <dd>In situ Operations, Administration, and Maintenance as defined in
Maintenance as defined in <xref target="RFC9197"/></t> <xref target="RFC9197"
format="default"/></dd>
<t hangText="OAM:">Operations, Administration, and Maintenance</t> <dt>OAM:</dt>
<dd>Operations, Administration, and Maintenance</dd>
<t hangText="POT:">Proof of Transit</t> <dt>POT:</dt>
</list></t> <dd>Proof of Transit</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="In-situ OAM Metadata Transport in IPv6"> <name>In situ OAM Metadata Transport in IPv6</name>
<t>IOAM in IPv6 is used to enhance diagnostics of IPv6 networks. <t>IOAM in IPv6 is used to enhance diagnostics of IPv6 networks. It
It complements other mechanisms designed to enhance diagnostics of IPv6 complements other mechanisms designed to enhance diagnostics of IPv6
networks, such as the IPv6 Performance and Diagnostic Metrics networks, such as the "IPv6 Performance and Diagnostic Metrics (PDM)
Destination Option described in <xref target="RFC8250"/>.</t> Destination Option" described in <xref target="RFC8250"
format="default"/>.</t>
<t> At the time this document was written, several implementations of IOAM <t> At the time this document was written, several implementations of
for IPv6 exist, e.g., IOAM for IPv6 in the Linux Kernel (supported from Ke IOAM for IPv6 exist, e.g., IOAM for IPv6 in the Linux Kernel (supported
rnel from Kernel version 5.15 onward,
version 5.15 onwards
<eref target="https://github.com/torvalds/linux/commit/7c804e91df523a37c29 e183ea2b10ac73c3a4f3d"> <eref target="https://github.com/torvalds/linux/commit/7c804e91df523a37c29 e183ea2b10ac73c3a4f3d">
IPv6 IOAM in Linux Kernel</eref>), IPv6 IOAM in Linux Kernel</eref>) and
<eref target="https://docs.fd.io/vpp/17.04/ioam_ipv6_doc.html"> <eref target="https://docs.fd.io/vpp/17.04/ioam_ipv6_doc.html">
IOAM for IPv6 in VPP </eref>. IOAM for IPv6 in Vector Packet Processing (VPP)</eref>.
</t> </t>
<t>IOAM data fields can be encapsulated with two types of extension header <t>IOAM Data-Fields can be encapsulated with two types of extension
s headers in IPv6 packets -- either the hop-by-hop options header or the
in IPv6 packets - either the hop-by-hop options header or destination options header. Multiple options with the same option type
the destination options header. Multiple options <bcp14>MAY</bcp14> appear in the same hop-by-hop options or destination
with the same option type MAY appear in the same hop-by-hop options or options header with distinct content.</t>
destination options header, with distinct content.</t>
<t>An IPv6 packet carrying IOAM data in an extension header can have <t>An IPv6 packet carrying IOAM data in an extension header can have
other extension headers, compliant with <xref target="RFC8200"/>.</t> other extension headers, compliant with <xref target="RFC8200" format="def
ault"/>.</t>
<t>IPv6 hop-by-hop and destination option format for carrying <figure>
IOAM data fields:<figure> <name>IPv6 Hop-by-Hop and Destination Option Format for Carrying
<artwork><![CDATA[ IOAM Data-Fields</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved | IOAM-Opt-Type | | Option-Type | Opt Data Len | Reserved | IOAM Opt-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | | | |
. . I . . I
. . O . . O
. . A . . A
. . M . . M
. . . . . .
. Option Data . O . Option Data . O
. . P . . P
. . T . . T
skipping to change at line 166 skipping to change at line 143
. . M . . M
. . . . . .
. Option Data . O . Option Data . O
. . P . . P
. . T . . T
. . I . . I
. . O . . O
. . N . . N
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t><list style="hanging">
<t hangText="Option Type:">8-bit option type identifier as defined
in <xref target="IANA"/>.</t>
<t hangText="Opt Data Len:">8-bit unsigned integer. Length of this
option, in octets, not including the first 2 octets.</t>
<t hangText="Reserved:">8-bit field MUST be set to zero
by the source.</t>
<t hangText="IOAM-Option-Type:"> Abbreviated to "IOAM-Opt-Type"
in the diagram above: 8-bit field as defined in section 4.1 of
<xref target="RFC9197"/>.</t>
<t hangText="Option Data:">Variable-length field.
Option-Type-specific data.</t>
</list></t>
<t>IOAM Option data is inserted as follows:<list style="numbers">
<t>Pre-allocated Trace Option: The IOAM Preallocated Trace
Option-Type defined in Section 4.4 of <xref target="RFC9197"/> is
represented as an IPv6 option in the hop-by-hop extension header: <lis
t
style="hanging">
<t hangText="Option Type:">TBD_1_1 8-bit identifier of the
IPv6 Option Type for IOAM.</t>
<t hangText="IOAM Type:">IOAM Pre-allocated Trace Option-Type.</t>
</list></t>
<t>Proof of Transit Option: The IOAM POT Option-Type defined in
Section 4.5 of <xref target="RFC9197"/> is represented as an IPv6
option in the hop-by-hop extension header: <list style="hanging">
<t hangText="Option Type:">TBD_1_1 8-bit identifier of the
IPv6 Option Type for IOAM.</t>
<t hangText="IOAM Type:">IOAM POT Option-Type.</t>
</list></t>
<t>Edge to Edge Option: The IOAM E2E option defined in Section 4.6
<xref target="RFC9197"/> is represented as an IPv6 option
in destination extension header: <list style="hanging">
<t hangText="Option Type:">TBD_1_0 8-bit identifier of the
IPv6 Option Type for IOAM.</t>
<t hangText="IOAM Type:">IOAM E2E Option-Type.</t>
</list></t>
<t>Direct Export (DEX) Option: The IOAM Direct Export Option-Type defi
ned in
Section 3.2 of <xref target="RFC9326"/> is represented
as an IPv6 option in the hop-by-hop extension header:
<list style="hanging">
<t hangText="Option Type:">TBD_1_0 8-bit identifier of the
IPv6 Option Type for IOAM.</t>
<t hangText="IOAM Type:">IOAM Direct Export (DEX) Option-Type.</t> <dl newline="false" spacing="normal">
</list></t> <dt>Option-Type:</dt>
<dd>8-bit option type identifier as defined
in <xref target="IANA" format="default"/>.</dd>
<dt>Opt Data Len:</dt>
<dd>8-bit unsigned integer. Length of this
option, in octets, not including the first 2 octets.</dd>
<dt>Reserved:</dt>
<dd>8-bit field <bcp14>MUST</bcp14> be set to zero
by the source.</dd>
<dt>IOAM Option-Type:</dt>
<dd>Abbreviated to "IOAM Opt-Type"
in the diagram above: 8-bit field as defined in <xref target="RFC9197"
section="4.1" sectionFormat="of"/>.</dd>
<dt>Option Data:</dt>
<dd><t>Variable-length field.
The data is specific to the Option-Type, as detailed below.</t>
</list>All the IOAM IPv6 options defined here have alignment <dl newline="false" spacing="normal">
requirements. Specifically, they all require 4n alignment. This ensures <dt>Pre-allocated Trace Option:</dt>
that fields specified in <xref target="RFC9197"/> are <dd>
aligned at a multiple-of-4 offset from the start of the hop-by-hop and <t>The IOAM Pre-allocated Trace Option-Type, defined in <xref
destination options header.</t> target="RFC9197" section="4.4" sectionFormat="of"/>, is represented
as an IPv6 option in the hop-by-hop extension header:</t>
<dl newline="false" spacing="normal">
<dt>Option-Type:</dt>
<dd>0x31 (8-bit identifier of the IPv6 Option-Type for
IOAM).</dd>
<dt>IOAM Type:</dt>
<dd>IOAM Pre-allocated Trace Option-Type.</dd>
</dl>
</dd>
<dt>Proof of Transit Option-Type:</dt>
<dd>
<t>The IOAM POT Option-Type, defined in <xref target="RFC9197"
section="4.5" sectionFormat="of"/>, is represented as an IPv6
option in the hop-by-hop extension header:</t>
<dl newline="false" spacing="normal">
<dt>Option-Type:</dt>
<dd>0x31 (8-bit identifier of the IPv6 Option-Type for
IOAM).</dd>
<dt>IOAM Type:</dt>
<dd>IOAM POT Option-Type.</dd>
</dl>
</dd>
<dt>Edge-to-Edge Option:</dt>
<dd>
<t>The IOAM E2E Option, defined in <xref target="RFC9197"
section="4.6" sectionFormat="of"/>, is represented as an IPv6
option in destination extension header: </t>
<dl newline="false" spacing="normal">
<dt>Option-Type:</dt>
<dd>0x11 (8-bit identifier of the IPv6 Option-Type for
IOAM).</dd>
<dt>IOAM Type:</dt>
<dd>IOAM E2E Option-Type.</dd>
</dl>
</dd>
<dt>Direct Export (DEX) Option:</dt>
<dd>
<t>The IOAM Direct Export Option-Type, defined in <xref
target="RFC9326" section="3.2" sectionFormat="of"/>, is
represented as an IPv6 option in the hop-by-hop extension
header:</t>
<dl newline="false" spacing="normal">
<dt>Option-Type:</dt>
<dd>0x11 (8-bit identifier of the IPv6 Option-Type for
IOAM).</dd>
<dt>IOAM Type:</dt>
<dd>IOAM Direct Export (DEX) Option-Type.</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
<t>All the IOAM IPv6 options defined here have alignment
requirements. Specifically, they all require alignment on multiples of 4
bytes. This ensures that fields specified in <xref 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, <t>IPv6 options can have a maximum length of 255 octets. Consequently,
the total length of IOAM Option-Types including all data fields the total length of IOAM Option-Types including all data fields is also
is also limited to 255 octets when encapsulated into IPv6.</t> limited to 255 octets when encapsulated into IPv6.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM Deployment In IPv6 Networks"> <name>IOAM Deployment in IPv6 Networks</name>
<t/> <section anchor="v6_requirement" numbered="true" toc="default">
<name>Considerations for IOAM Deployment and Implementation in IPv6
<section anchor="v6_requirement" Networks</name>
title="Considerations for IOAM deployment and implementation <t>IOAM deployments in IPv6 networks <bcp14>MUST</bcp14> take the follow
in IPv6 networks"> ing
considerations and requirements into account.</t>
<t>IOAM deployments in IPv6 networks MUST take the following <ol type="C%d:">
considerations and requirements into account:<list style="hanging"> <li>
<t hangText="C1"> IOAM <bcp14>MUST</bcp14> be deployed in an IOAM-Domain. An
IOAM MUST be deployed in an IOAM-Domain. An IOAM-Domain IOAM-Domain is a set of nodes that use IOAM. An IOAM-Domain is
is a set of nodes that use IOAM. An IOAM-Domain is bounded by bounded by its perimeter or edge. The set of nodes forming an
its perimeter or edge. The set of nodes forming an IOAM-Domain IOAM-Domain may be connected to the same physical infrastructure
may be connected to the same physical infrastructure (e.g., a service provider's network). They may also be remotely
(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
connected to each other (e.g., an enterprise VPN or an overlay). is expected that all nodes in an IOAM-Domain are managed by the same
It is expected that all nodes in an IOAM-Domain are managed by administrative entity. Please refer to <xref target="RFC9197"
the same administrative entity. Please refer to format="default"/> for more details on IOAM-Domains.
<xref target="RFC9197"/>) for more details on IOAM-Domains. </li>
</t> <li>
<t hangText="C2">Implementations of IOAM MUST ensure that the Implementations of IOAM <bcp14>MUST</bcp14> ensure that the
addition of IOAM data fields does not alter the way routers addition of IOAM Data-Fields does not alter the way routers forward
forward packets or the forwarding decisions they make. packets or the forwarding decisions they make. Packets with added
Packets with added IOAM information must follow the same path IOAM information must follow the same path within the domain as an
within the domain as an identical packet without IOAM information identical packet without IOAM information would, even in the
would, even in the presence of Equal-Cost Multi-Path (ECMP). presence of Equal-Cost Multipath (ECMP). This behavior is
This behavior is important for deployments where important for deployments where IOAM Data-Fields are only added
IOAM data fields are only added "on-demand". "on-demand". Implementations of IOAM <bcp14>MUST</bcp14> ensure
Implementations of IOAM MUST ensure that ECMP behavior for that ECMP behavior for packets with and without IOAM Data-Fields is
packets with and without IOAM data fields is the same. the same. In order for IOAM to work in IPv6 networks, IOAM
In order for IOAM to work in IPv6 networks, <bcp14>MUST</bcp14> be explicitly enabled per interface on every
IOAM MUST be explicitly enabled per interface on every node node within the IOAM-Domain. Unless a particular interface is
within the IOAM domain. Unless a particular interface is explicitly enabled (i.e., explicitly configured) for IOAM, a router
explicitly enabled (i.e., explicitly configured) for IOAM, <bcp14>MUST</bcp14> ignore IOAM Options.
a router MUST ignore IOAM Options. </t> </li>
<li>
<t hangText="C3"> In order to maintain the integrity of packets in an IOAM-Domain,
In order to maintain the integrity of packets in an IOAM domain, the Maximum Transmission Unit (MTU) of transit routers and switches
the Maximum Transmission Unit (MTU) of transit routers and switches must be configured to a value that does not lead to an "ICMP Packet
must be configured to a value that does not lead to an ICMP Too Big" error message being sent to the originator and the packet
Packet Too Big error message being sent to the originator and being dropped. The PMTU tolerance range must be identified, and
the packet being dropped. IOAM encapsulation operations or data field insertion must not
The PMTU tolerance range must be identified and IOAM encapsulation exceed this range. Control of the MTU is critical to the proper
operations or data field insertion must not exceed this range. operation of IOAM. The PMTU tolerance must be identified through
Control of the MTU is critical to the proper operation of IOAM. configuration, and IOAM operations must not exceed the packet size
The PMTU tolerance must be identified through configuration and beyond PMTU.
IOAM operations must not exceed the packet size beyond PMTU.</t> </li>
<li>
<t hangText="C4"> <xref target="RFC8200"/> <xref target="RFC8200" format="default"/> precludes insertion of
precludes insertion of IOAM data directly into the original IPv6 IOAM data directly into the original IPv6 header of in-flight
header of in-flight packets. packets. IOAM deployments that do not encapsulate/decapsulate IOAM
IOAM deployments which do not encapsulate/decapsulate IOAM on the on the host but desire to encapsulate/decapsulate IOAM on transit
host but desire to encapsulate/decapsulate IOAM on transit nodes nodes <bcp14>MUST</bcp14> add an additional IPv6 header to the
MUST add an additional IPv6 header to the original packet. original packet. IOAM data is added to this additional IPv6 header.
IOAM data is added to this additional IPv6 header. </li>
</t> </ol>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM domains bounded by hosts"> <name>IOAM-Domains Bounded by Hosts</name>
<t>For deployments where the IOAM domain is bounded by hosts, hosts <t>For deployments where the IOAM-Domain is bounded by hosts, hosts
will perform the operation of IOAM data field encapsulation and will perform the operation of IOAM Data-Field encapsulation and
decapsulation, i.e., hosts will place the IOAM data fields decapsulation, i.e., hosts will place the IOAM Data-Fields
directly in the IPv6 header or remove the IOAM data fields directly directly in the IPv6 header or remove the IOAM Data-Fields directly
from the IPv6 header. IOAM data is carried in IPv6 packets as hop-by-hop or from the IPv6 header. IOAM data is carried in IPv6 packets as hop-by-hop or
destination options as specified in this document.</t> destination options as specified in this document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IOAM domains bounded by network devices"> <name>IOAM-Domains Bounded by Network Devices</name>
<t>For deployments where the IOAM domain is bounded by network <t>For deployments where the IOAM-Domain is bounded by network
devices, network devices such as routers form the edge of an IOAM devices, network devices such as routers form the edge of an
domain. Network devices will perform the operation of IOAM data field IOAM-Domain. Network devices will perform the operation of IOAM
encapsulation and decapsulation. Network devices will encapsulate Data-Field encapsulation and decapsulation. Network devices will
IOAM data fields in an additional, outer, IPv6 header which encapsulate IOAM Data-Fields in an additional, outer, IPv6 header that
carries the IOAM data fields.</t> carries the IOAM Data-Fields.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>This document describes the encapsulation of IOAM data fields in <t>This document describes the encapsulation of IOAM Data-Fields in
IPv6. For general IOAM security considerations, IPv6. For general IOAM security considerations, see <xref
see <xref target="RFC9197"/>. Security considerations of the specific target="RFC9197" format="default"/>. Security considerations of the
IOAM data fields for each case (i.e., Trace, Proof of Transit, and E2E) specific IOAM Data-Fields for each case (i.e., Trace, POT, and E2E) are
are also described and defined in <xref target="RFC9197"/>.</t> also described and defined in <xref target="RFC9197"
format="default"/>.</t>
<t>As this document describes new options for IPv6, the <t>As this document describes new options for IPv6, the
security considerations of <xref target="RFC8200"/> and security considerations of <xref target="RFC8200" format="default"/> and
<xref target="RFC8250"/> apply.</t> <xref target="RFC8250" format="default"/> apply.</t>
<t>From a network-protection perspective, there is an assumed trust
<t>From a network-protection perspective, there is an assumed model such that any node that adds IOAM to a packet, removes IOAM from a
trust model such that any node that adds IOAM to a packet, packet, or modifies IOAM Data-Fields of a packet is assumed to be
removes IOAM from a packet, or modifies IOAM data fields allowed to do so. By default, packets that include IPv6 extension
of a packet is assumed to be allowed to do so. By default, packets that headers with IOAM information <bcp14>MUST NOT</bcp14> be leaked through
include IPv6 extension headers with IOAM information MUST NOT the boundaries of the IOAM-Domain.</t>
be leaked through the boundaries of the IOAM-Domain.</t> <t>IOAM-Domain boundary routers <bcp14>MUST</bcp14> filter any incoming
<t>IOAM-Domain boundary routers MUST filter any incoming traffic traffic from outside the IOAM-Domain that contains IPv6 extension
from outside the IOAM-Domain that contains IPv6 extension headers headers with IOAM information. IOAM-Domain boundary routers
with IOAM information. IOAM-Domain boundary routers MUST <bcp14>MUST</bcp14> also filter any outgoing traffic leaving the
also filter any outgoing traffic leaving the IOAM-Domain that IOAM-Domain that contains IPv6 extension headers with IOAM
contains IPv6 extension headers with IOAM information.</t> information.</t>
<t>In the general case, an IOAM node only adds, removes, or modifies <t>In the general case, an IOAM node only adds, removes, or modifies
an IPv6 extension header with IOAM information, if the an IPv6 extension header with IOAM information, if the
directive to do so comes from a trusted source and the directive directive to do so comes from a trusted source and the directive
is validated.</t> is validated.</t>
<t>Problems may occur if the above behaviors are not implemented <t>Problems may occur if the above behaviors are not implemented
or if the assumed trust model is violated (e.g., through a security or if the assumed trust model is violated (e.g., through a security
breach). In addition to the security considerations discussed in breach). In addition to the security considerations discussed in
<xref target="RFC9197"/>, the security considerations associated <xref target="RFC9197" format="default"/>, the security considerations ass
with IPv6 extension headers listed in <xref target="RFC9098"/> apply.</t> ociated
with IPv6 extension headers listed in <xref target="RFC9098" format="defau
<section title="Applicability of AH"> lt"/> apply.</t>
<t> <section numbered="true" toc="default">
The network devices in an IOAM-Domain are trusted to add, update and remov <name>Applicability of Authentication Header (AH)</name>
e <t> The network devices in an IOAM-Domain are trusted to add, update,
IOAM options according to the constraints specified in <xref target="RFC82 and remove IOAM options according to the constraints specified in
00"/>. <xref target="RFC8200" format="default"/>. IOAM-Domain does not rely
IOAM domain does not rely on the Authentication Header (AH) as defined in on the AH as defined in <xref target="RFC4302" format="default"/> to
<xref target="RFC4302"/> to secure IOAM options. secure IOAM options. The use of IOAM options with AH and its
The use of IOAM options with AH and its processing is not defined processing are not defined in this document. Future documents may
in this document. Future documents may define the use of IOAM with AH and define the use of IOAM with AH and its processing.</t>
its processing.</t> </section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft requests the following IPv6 Option Type assignments from
the destination options and hop-by-hop options sub-registry of 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 option
and
IOAM hop-by-hop option
TBD_1_1 00 1 TBD_1 IOAM [This draft]
destination option
and
IOAM hop-by-hop option
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has assigned the IPv6 Option-Types from
the "Destination Options and Hop-by-Hop Options" subregistry of
"Internet Protocol Version 6 (IPv6) Parameters" <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 IOAM Hop-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 IOAM Hop-by-Hop Option</td>
<td>RFC 9486</td>
</tr>
</tbody>
</table>
<section title="Acknowledgements">
<t>The authors would like to thank Tom Herbert, Eric Vyncke, Nalini
Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra
Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark,
LJ Wobker, Mark Smith, Andrew Yourtchenko and Justin Iurman for the
comments and advice. For the IPv6 encapsulation, this document leverages
concepts described in <xref target="I-D.kitamura-ipv6-record-route"/>.
The authors would like to acknowledge the work done by the author
Hiroshi Kitamura and people involved in writing it.</t>
</section> </section>
<!---->
<!-- -->
</middle> </middle>
<back> <back>
<references title="Normative References">
&RFC2119;
&RFC8174;
&RFC9197; <displayreference target="I-D.kitamura-ipv6-record-route" to="IPV6-RECORD-ROUTE" />;
&RFC9326; <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
326.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
250.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
302.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
098.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.kitamura-ipv6-record-route.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section numbered="false" toc="default">
&RFC8200; <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Tom Herbert"/>,
&RFC8250; <contact fullname="Éric Vyncke"/>, <contact fullname="Nalini Elkins"/>,
<contact fullname="Srihari Raghavan"/>, <contact fullname="Ranganathan T S
&RFC4302; "/>, <contact fullname="Karthik Babu Harichandra Babu"/>, <contact
fullname="Akshaya Nadahalli"/>, <contact fullname="Stefano Previdi"/>,
&RFC9098; <contact fullname="Hemant Singh"/>, <contact fullname="Erik Nordmark"/>,
<contact fullname="LJ Wobker"/>, <contact fullname="Mark Smith"/>,
<reference anchor="I-D.kitamura-ipv6-record-route"> <contact fullname="Andrew Yourtchenko"/>, and <contact fullname="Justin
<front> Iurman"/> for the comments and advice. For the IPv6 encapsulation, this
<title>Record Route for IPv6 (PR6) Hop-by-Hop Option document leverages concepts described in <xref
Extension</title> target="I-D.kitamura-ipv6-record-route" format="default"/>. The authors
would like to acknowledge the work done by the author <contact
<author fullname="Hiroshi Kitamura" initials="H" surname="Kitamura"/> fullname="Hiroshi Kitamura"/> and people involved in writing it.</t>
</section>
<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-rou
te-00.txt"
type="TXT"/>
</reference>
</references> <section numbered="false" toc="default">
<section numbered="no" title="Contributors"> <name>Contributors</name>
<t>This document was the collective effort of several authors. The tex
t
and content were contributed by the editors and the co-authors listed
below. The contact information of the co-authors appears at the end of
this document.</t>
<t><list style="symbols"> <t>This document was the collective effort of several authors. The text
<t>Carlos Pignataro</t> and content were contributed by the editors and the coauthors listed
<t>Hannes Gredler</t> below.</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"> <contact fullname="Carlos Pignataro">
<t><figure> <organization>Cisco Systems, Inc.</organization>
<artwork><![CDATA[ <address>
<postal>
<street>7200-11 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region><code>27709</code>
<country>United States of America</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</contact>
Carlos Pignataro <contact fullname="Hannes Gredler">
Cisco Systems, Inc. <organization>RtBrick Inc.</organization>
7200-11 Kit Creek Road <address>
Research Triangle Park, NC 27709 <email>hannes@rtbrick.com</email>
United States </address>
Email: cpignata@cisco.com </contact>
Hannes Gredler <contact fullname="John Leddy">
RtBrick Inc. <address>
Email: hannes@rtbrick.com <email>john@leddy.net</email>
</address>
</contact>
John Leddy <contact fullname="Stephen Youell">
Email: john@leddy.net <organization>JP Morgan Chase</organization>
<address>
<postal>
<street>25 Bank Street</street>
<city>London</city><code>E14 5JP</code>
<country>United Kingdom</country>
</postal>
<email>stephen.youell@jpmorgan.com</email>
</address>
</contact>
Stephen Youell <contact fullname="Tal Mizrahi">
JP Morgan Chase <organization>Huawei Network.IO Innovation Lab</organization>
25 Bank Street <address>
London E14 5JP <postal>
United Kingdom <country>Israel</country>
Email: stephen.youell@jpmorgan.com </postal>
<email>tal.mizrahi.phd@gmail.com</email>
</address>
</contact>
Tal Mizrahi <contact fullname="Aviv Kfir">
Huawei Network.IO Innovation Lab <organization>Mellanox Technologies, Inc.</organization>
Israel <address>
Email: tal.mizrahi.phd@gmail.com <postal>
<street>350 Oakmead Parkway, Suite 100</street>
<city>Sunnyvale</city> <region>CA</region><code>94085</code>
<country>United States of America</country>
</postal>
<email>avivk@mellanox.com</email>
</address>
</contact>
Aviv Kfir <contact fullname="Barak Gafni">
Mellanox Technologies, Inc. <organization>Mellanox Technologies, Inc.</organization>
350 Oakmead Parkway, Suite 100 <address>
Sunnyvale, CA 94085 <postal>
U.S.A. <street>350 Oakmead Parkway, Suite 100</street>
Email: avivk@mellanox.com <city>Sunnyvale</city><region>CA</region><code>94085</code>
<country>United States of America</country>
</postal>
<email>gbarak@mellanox.com</email>
</address>
</contact>
Barak Gafni <contact fullname="Petr Lapukhov">
Mellanox Technologies, Inc. <organization>Facebook</organization>
350 Oakmead Parkway, Suite 100 <address>
Sunnyvale, CA 94085 <postal>
U.S.A. <street>1 Hacker Way</street>
Email: gbarak@mellanox.com <city>Menlo Park</city><region>CA</region><code>94025</code>
<country>United States of America</country>
</postal>
<email>petr@fb.com</email>
</address>
</contact>
Petr Lapukhov <contact fullname="Mickey Spiegel">
Facebook <organization>Barefoot Networks, an Intel company</organization>
1 Hacker Way <address>
Menlo Park, CA 94025 <postal>
US <street>4750 Patrick Henry Drive</street>
Email: petr@fb.com <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>
Mickey Spiegel <contact fullname="Suresh Krishnan">
Barefoot Networks, an Intel company <organization>Kaloom</organization>
4750 Patrick Henry Drive <address>
Santa Clara, CA 95054 <email>suresh@kaloom.com</email>
US </address>
Email: mickey.spiegel@intel.com </contact>
Suresh Krishnan <contact fullname="Rajiv Asati">
Kaloom <organization>Cisco Systems, Inc.</organization>
Email: suresh@kaloom.com <address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city><region>NC</region><code>27709</code>
<country>United States of America</country>
</postal>
<email>rajiva@cisco.com</email>
</address>
</contact>
Rajiv Asati <contact fullname="Mark Smith">
Cisco Systems, Inc. <address>
7200 Kit Creek Road <postal>
Research Triangle Park, NC 27709 <street>PO BOX 521</street>
US <city>Heidelberg</city><region>VIC</region><code>3084</code>
Email: rajiva@cisco.com <country>Australia</country>
</postal>
<email>markzzzsmith+id@gmail.com</email>
</address>
</contact>
Mark Smith
PO BOX 521
HEIDELBERG, VIC 3084
AU
Email: markzzzsmith+id@gmail.com
]]></artwork>
</figure></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 67 change blocks. 
464 lines changed or deleted 491 lines changed or added

This html diff was produced by rfcdiff 1.48.