rfc9486.original   rfc9486.txt 
ippm S. Bhandari, Ed. Internet Engineering Task Force (IETF) S. Bhandari, Ed.
Internet-Draft Thoughtspot Request for Comments: 9486 Thoughtspot
Intended status: Standards Track F. Brockners, Ed. Category: Standards Track F. Brockners, Ed.
Expires: 8 November 2023 Cisco ISSN: 2070-1721 Cisco
7 May 2023 September 2023
In-situ OAM IPv6 Options IPv6 Options for In Situ Operations, Administration, and Maintenance
draft-ietf-ippm-ioam-ipv6-options-12 (IOAM)
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records 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. outlines how IOAM Data-Fields are encapsulated in IPv6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 November 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9486.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2.1. Requirements Language
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations
3. In-situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 3 3. In situ OAM Metadata Transport in IPv6
4. IOAM Deployment In IPv6 Networks . . . . . . . . . . . . . . 5 4. IOAM Deployment in IPv6 Networks
4.1. Considerations for IOAM deployment and implementation in 4.1. Considerations for IOAM Deployment and Implementation in
IPv6 networks . . . . . . . . . . . . . . . . . . . . . . 5 IPv6 Networks
4.2. IOAM domains bounded by hosts . . . . . . . . . . . . . . 6 4.2. IOAM-Domains Bounded by Hosts
4.3. IOAM domains bounded by network devices . . . . . . . . . 7 4.3. IOAM-Domains Bounded by Network Devices
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
5.1. Applicability of AH . . . . . . . . . . . . . . . . . . . 8 5.1. Applicability of Authentication Header (AH)
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Contributors
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
In-situ Operations, Administration, and Maintenance (IOAM) records 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 associated nomenclature, as well as IOAM data fields are defined and associated nomenclature as well as IOAM Data-Fields are defined
in [RFC9197]. This document outlines how IOAM data fields are in [RFC9197]. This document outlines how IOAM Data-Fields are
encapsulated in IPv6 [RFC8200] and discusses deployment requirements encapsulated in IPv6 [RFC8200] and discusses deployment requirements
for networks that use IPv6-encapsulated IOAM data fields. for networks that use IPv6-encapsulated IOAM Data-Fields.
The terms "encapsulation" and "decapsulation" are used in this The terms "encapsulation" and "decapsulation" are used in this
document in the same way as in [RFC9197]: An IOAM encapsulating node document in the same way as in [RFC9197]: An IOAM encapsulating node
incorporates one or more IOAM-Option-Types into packets. An IOAM incorporates one or more IOAM Option-Types into packets that IOAM is
decapsulating node removes IOAM-Option-Type(s) from packets. enabled for.
2. Conventions 2. Conventions
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
Abbreviations used in this document: Abbreviations used in this document:
E2E: Edge-to-Edge E2E: Edge-to-Edge
IOAM: In-situ Operations, Administration, and Maintenance as IOAM: In situ Operations, Administration, and Maintenance as
defined in [RFC9197] defined in [RFC9197]
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
POT: Proof of Transit POT: Proof of Transit
3. In-situ OAM Metadata Transport in IPv6 3. In situ OAM Metadata Transport in IPv6
IOAM in IPv6 is used to enhance diagnostics of IPv6 networks. It IOAM in IPv6 is used to enhance diagnostics of IPv6 networks. 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 [RFC8250]. Destination Option" described in [RFC8250].
At the time this document was written, several implementations of At the time this document was written, several implementations of
IOAM for IPv6 exist, e.g., IOAM for IPv6 in the Linux Kernel IOAM for IPv6 exist, e.g., IOAM for IPv6 in the Linux Kernel
(supported from Kernel version 5.15 onwards IPv6 IOAM in Linux Kernel (supported from Kernel version 5.15 onward, IPv6 IOAM in Linux Kernel
(https://github.com/torvalds/linux/ (https://github.com/torvalds/linux/
commit/7c804e91df523a37c29e183ea2b10ac73c3a4f3d)), IOAM for IPv6 in commit/7c804e91df523a37c29e183ea2b10ac73c3a4f3d)) and IOAM for IPv6
VPP (https://docs.fd.io/vpp/17.04/ioam_ipv6_doc.html). in Vector Packet Processing (VPP) (https://docs.fd.io/vpp/17.04/
ioam_ipv6_doc.html).
IOAM data fields can be encapsulated with two types of extension IOAM Data-Fields can be encapsulated with two types of extension
headers in IPv6 packets - either the hop-by-hop options header or the headers in IPv6 packets -- either the hop-by-hop options header or
destination options header. Multiple options with the same option the destination options header. Multiple options with the same
type MAY appear in the same hop-by-hop options or destination options option type MAY appear in the same hop-by-hop options or destination
header, with distinct content. options header with distinct content.
An IPv6 packet carrying IOAM data in an extension header can have An IPv6 packet carrying IOAM data in an extension header can have
other extension headers, compliant with [RFC8200]. other extension headers, compliant with [RFC8200].
IPv6 hop-by-hop and destination option format for carrying IOAM data
fields:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
. . I . . I
. . O . . O
. . N . . N
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Option Type: 8-bit option type identifier as defined in Section 6. Figure 1: IPv6 Hop-by-Hop and Destination Option Format for
Carrying IOAM Data- Fields
Option-Type: 8-bit option type identifier as defined in Section 6.
Opt Data Len: 8-bit unsigned integer. Length of this option, in Opt Data Len: 8-bit unsigned integer. Length of this option, in
octets, not including the first 2 octets. octets, not including the first 2 octets.
Reserved: 8-bit field MUST be set to zero by the source. Reserved: 8-bit field MUST be set to zero by the source.
IOAM-Option-Type: Abbreviated to "IOAM-Opt-Type" in the diagram IOAM Option-Type: Abbreviated to "IOAM Opt-Type" in the diagram
above: 8-bit field as defined in section 4.1 of [RFC9197]. above: 8-bit field as defined in Section 4.1 of [RFC9197].
Option Data: Variable-length field. Option-Type-specific data.
IOAM Option data is inserted as follows: Option Data: Variable-length field. The data is specific to the
Option-Type, as detailed below.
1. Pre-allocated Trace Option: The IOAM Preallocated Trace Option- Pre-allocated Trace Option: The IOAM Pre-allocated Trace Option-
Type defined in Section 4.4 of [RFC9197] is represented as an Type, defined in Section 4.4 of [RFC9197], is represented as an
IPv6 option in the hop-by-hop extension header: IPv6 option in the hop-by-hop extension header:
Option Type: TBD_1_1 8-bit identifier of the IPv6 Option Type Option-Type: 0x31 (8-bit identifier of the IPv6 Option-Type
for IOAM. for IOAM).
IOAM Type: IOAM Pre-allocated Trace Option-Type. IOAM Type: IOAM Pre-allocated Trace Option-Type.
2. Proof of Transit Option: The IOAM POT Option-Type defined in Proof of Transit Option-Type: The IOAM POT Option-Type, defined
Section 4.5 of [RFC9197] is represented as an IPv6 option in the in Section 4.5 of [RFC9197], is represented as an IPv6 option
hop-by-hop extension header: in the hop-by-hop extension header:
Option Type: TBD_1_1 8-bit identifier of the IPv6 Option Type Option-Type: 0x31 (8-bit identifier of the IPv6 Option-Type
for IOAM. for IOAM).
IOAM Type: IOAM POT Option-Type. IOAM Type: IOAM POT Option-Type.
3. Edge to Edge Option: The IOAM E2E option defined in Section 4.6 Edge-to-Edge Option: The IOAM E2E Option, defined in Section 4.6
[RFC9197] is represented as an IPv6 option in destination of [RFC9197], is represented as an IPv6 option in destination
extension header: extension header:
Option Type: TBD_1_0 8-bit identifier of the IPv6 Option Type Option-Type: 0x11 (8-bit identifier of the IPv6 Option-Type
for IOAM. for IOAM).
IOAM Type: IOAM E2E Option-Type. IOAM Type: IOAM E2E Option-Type.
4. Direct Export (DEX) Option: The IOAM Direct Export Option-Type Direct Export (DEX) Option: The IOAM Direct Export Option-Type,
defined in Section 3.2 of [RFC9326] is represented as an IPv6 defined in Section 3.2 of [RFC9326], is represented as an IPv6
option in the hop-by-hop extension header: option in the hop-by-hop extension header:
Option Type: TBD_1_0 8-bit identifier of the IPv6 Option Type Option-Type: 0x11 (8-bit identifier of the IPv6 Option-Type
for IOAM. for IOAM).
IOAM Type: IOAM Direct Export (DEX) Option-Type. IOAM Type: IOAM Direct Export (DEX) Option-Type.
All the IOAM IPv6 options defined here have alignment requirements. All the IOAM IPv6 options defined here have alignment requirements.
Specifically, they all require 4n alignment. This ensures that Specifically, they all require alignment on multiples of 4 bytes.
fields specified in [RFC9197] are aligned at a multiple-of-4 offset This ensures that fields specified in [RFC9197] are aligned at a
from the start of the hop-by-hop and destination options header. multiple-of-4 offset from the start of the hop-by-hop and destination
options header.
IPv6 options can have a maximum length of 255 octets. Consequently, IPv6 options can have a maximum length of 255 octets. Consequently,
the total length of IOAM Option-Types including all data fields is the total length of IOAM Option-Types including all data fields is
also limited to 255 octets when encapsulated into IPv6. also limited to 255 octets when encapsulated into IPv6.
4. IOAM Deployment In IPv6 Networks 4. IOAM Deployment in IPv6 Networks
4.1. Considerations for IOAM deployment and implementation in IPv6 4.1. Considerations for IOAM Deployment and Implementation in IPv6
networks Networks
IOAM deployments in IPv6 networks MUST take the following IOAM deployments in IPv6 networks MUST take the following
considerations and requirements into account: considerations and requirements into account.
C1 IOAM MUST be deployed in an IOAM-Domain. An IOAM-Domain is a set C1: IOAM MUST be deployed in an IOAM-Domain. An IOAM-Domain is a
of nodes that use IOAM. An IOAM-Domain is bounded by its 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 perimeter or edge. The set of nodes forming an IOAM-Domain may
connected to the same physical infrastructure (e.g., a service be connected to the same physical infrastructure (e.g., a
provider's network). They may also be remotely connected to each service provider's network). They may also be remotely
other (e.g., an enterprise VPN or an overlay). It is expected connected to each other (e.g., an enterprise VPN or an overlay).
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 [RFC9197]) for more the same administrative entity. Please refer to [RFC9197] for
details on IOAM-Domains. more details on IOAM-Domains.
C2 Implementations of IOAM MUST ensure that the addition of IOAM C2: Implementations of IOAM MUST ensure that the addition of IOAM
data fields does not alter the way routers forward packets or the Data-Fields does not alter the way routers forward packets or
forwarding decisions they make. Packets with added IOAM the forwarding decisions they make. Packets with added IOAM
information must follow the same path within the domain as an information must follow the same path within the domain as an
identical packet without IOAM information would, even in the identical packet without IOAM information would, even in the
presence of Equal-Cost Multi-Path (ECMP). This behavior is presence of Equal-Cost Multipath (ECMP). This behavior is
important for deployments where IOAM data fields are only added important for deployments where IOAM Data-Fields are only added
"on-demand". Implementations of IOAM MUST ensure that ECMP "on-demand". Implementations of IOAM MUST ensure that ECMP
behavior for packets with and without IOAM data fields is the behavior for packets with and without IOAM Data-Fields is the
same. In order for IOAM to work in IPv6 networks, IOAM MUST be same. In order for IOAM to work in IPv6 networks, IOAM MUST be
explicitly enabled per interface on every node within the IOAM explicitly enabled per interface on every node within the IOAM-
domain. Unless a particular interface is explicitly enabled Domain. Unless a particular interface is explicitly enabled
(i.e., explicitly configured) for IOAM, a router MUST ignore IOAM (i.e., explicitly configured) for IOAM, a router MUST ignore
Options. IOAM Options.
C3 In order to maintain the integrity of packets in an IOAM domain, C3: In order to maintain the integrity of packets in an IOAM-Domain,
the Maximum Transmission Unit (MTU) of transit routers and the Maximum Transmission Unit (MTU) of transit routers and
switches must be configured to a value that does not lead to an switches must be configured to a value that does not lead to an
ICMP Packet Too Big error message being sent to the originator and "ICMP Packet Too Big" error message being sent to the originator
the packet being dropped. The PMTU tolerance range must be and the packet being dropped. The PMTU tolerance range must be
identified and IOAM encapsulation operations or data field identified, and IOAM encapsulation operations or data field
insertion must not exceed this range. Control of the MTU is insertion must not exceed this range. Control of the MTU is
critical to the proper operation of IOAM. The PMTU tolerance must critical to the proper operation of IOAM. The PMTU tolerance
be identified through configuration and IOAM operations must not must be identified through configuration, and IOAM operations
exceed the packet size beyond PMTU. must not exceed the packet size beyond PMTU.
C4 [RFC8200] precludes insertion of IOAM data directly into the C4: [RFC8200] precludes insertion of IOAM data directly into the
original IPv6 header of in-flight packets. IOAM deployments which original IPv6 header of in-flight packets. IOAM deployments
do not encapsulate/decapsulate IOAM on the host but desire to that do not encapsulate/decapsulate IOAM on the host but desire
encapsulate/decapsulate IOAM on transit nodes MUST add an to encapsulate/decapsulate IOAM on transit nodes MUST add an
additional IPv6 header to the original packet. IOAM data is added additional IPv6 header to the original packet. IOAM data is
to this additional IPv6 header. added to this additional IPv6 header.
4.2. IOAM domains bounded by hosts 4.2. IOAM-Domains Bounded by Hosts
For deployments where the IOAM domain is bounded by hosts, hosts will For deployments where the IOAM-Domain is bounded by hosts, hosts will
perform the operation of IOAM data field encapsulation and perform the operation of IOAM Data-Field encapsulation and
decapsulation, i.e., hosts will place the IOAM data fields directly decapsulation, i.e., hosts will place the IOAM Data-Fields directly
in the IPv6 header or remove the IOAM data fields directly from the 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 IPv6 header. IOAM data is carried in IPv6 packets as hop-by-hop or
destination options as specified in this document. destination options as specified in this document.
4.3. IOAM domains bounded by network devices 4.3. IOAM-Domains Bounded by Network Devices
For deployments where the IOAM domain is bounded by network devices, For deployments where the IOAM-Domain is bounded by network devices,
network devices such as routers form the edge of an IOAM domain. network devices such as routers form the edge of an IOAM-Domain.
Network devices will perform the operation of IOAM data field Network devices will perform the operation of IOAM Data-Field
encapsulation and decapsulation. Network devices will encapsulate encapsulation and decapsulation. Network devices will encapsulate
IOAM data fields in an additional, outer, IPv6 header which carries IOAM Data-Fields in an additional, outer, IPv6 header that carries
the IOAM data fields. the IOAM Data-Fields.
5. Security Considerations 5. Security Considerations
This document describes the encapsulation of IOAM data fields in This document describes the encapsulation of IOAM Data-Fields in
IPv6. For general IOAM security considerations, see [RFC9197]. IPv6. For general IOAM security considerations, see [RFC9197].
Security considerations of the specific IOAM data fields for each Security considerations of the specific IOAM Data-Fields for each
case (i.e., Trace, Proof of Transit, and E2E) are also described and case (i.e., Trace, POT, and E2E) are also described and defined in
defined in [RFC9197]. [RFC9197].
As this document describes new options for IPv6, the security As this document describes new options for IPv6, the security
considerations of [RFC8200] and [RFC8250] apply. considerations of [RFC8200] and [RFC8250] apply.
From a network-protection perspective, there is an assumed trust From a network-protection perspective, there is an assumed trust
model such that any node that adds IOAM to a packet, removes IOAM model such that any node that adds IOAM to a packet, removes IOAM
from a packet, or modifies IOAM data fields of a packet is assumed to from a packet, or modifies IOAM Data-Fields of a packet is assumed to
be allowed to do so. By default, packets that include IPv6 extension be allowed to do so. By default, packets that include IPv6 extension
headers with IOAM information MUST NOT be leaked through the headers with IOAM information MUST NOT be leaked through the
boundaries of the IOAM-Domain. boundaries of the IOAM-Domain.
IOAM-Domain boundary routers MUST filter any incoming traffic from IOAM-Domain boundary routers MUST filter any incoming traffic from
outside the IOAM-Domain that contains IPv6 extension headers with outside the IOAM-Domain that contains IPv6 extension headers with
IOAM information. IOAM-Domain boundary routers MUST also filter any IOAM information. IOAM-Domain boundary routers MUST also filter any
outgoing traffic leaving the IOAM-Domain that contains IPv6 extension outgoing traffic leaving the IOAM-Domain that contains IPv6 extension
headers with IOAM information. headers with IOAM information.
In the general case, an IOAM node only adds, removes, or modifies an In the general case, an IOAM node only adds, removes, or modifies an
IPv6 extension header with IOAM information, if the directive to do IPv6 extension header with IOAM information, if the directive to do
so comes from a trusted source and the directive is validated. so comes from a trusted source and the directive is validated.
Problems may occur if the above behaviors are not implemented or if Problems may occur if the above behaviors are not implemented or if
the assumed trust model is violated (e.g., through a security 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
[RFC9197], the security considerations associated with IPv6 extension [RFC9197], the security considerations associated with IPv6 extension
headers listed in [RFC9098] apply. headers listed in [RFC9098] apply.
5.1. Applicability of AH 5.1. Applicability of Authentication Header (AH)
The network devices in an IOAM-Domain are trusted to add, update and The network devices in an IOAM-Domain are trusted to add, update, and
remove IOAM options according to the constraints specified in remove IOAM options according to the constraints specified in
[RFC8200]. IOAM domain does not rely on the Authentication Header [RFC8200]. IOAM-Domain does not rely on the AH as defined in
(AH) as defined in [RFC4302] to secure IOAM options. The use of IOAM [RFC4302] to secure IOAM options. The use of IOAM options with AH
options with AH and its processing is not defined in this document. and its processing are not defined in this document. Future
Future documents may define the use of IOAM with AH and its documents may define the use of IOAM with AH and its processing.
processing.
6. IANA Considerations 6. IANA Considerations
This draft requests the following IPv6 Option Type assignments from IANA has assigned the IPv6 Option-Types from the "Destination Options
the destination options and hop-by-hop options sub-registry of and Hop-by-Hop Options" subregistry of "Internet Protocol Version 6
Internet Protocol Version 6 (IPv6) Parameters. (IPv6) Parameters" <https://www.iana.org/assignments/
ipv6-parameters/>.
http://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#ipv6-parameters-2
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
7. Acknowledgements +=======+===================+===================+===========+
| Hex | Binary Value | Description | Reference |
| Value +=====+=====+=======+ | |
| | act | chg | rest | | |
+=======+=====+=====+=======+===================+===========+
| 0x11 | 00 | 0 | 10001 | IOAM Destination | RFC 9486 |
| | | | | Option and IOAM | |
| | | | | Hop-by-Hop Option | |
+-------+-----+-----+-------+-------------------+-----------+
| 0x31 | 00 | 1 | 10001 | IOAM Destination | RFC 9486 |
| | | | | Option and IOAM | |
| | | | | Hop-by-Hop Option | |
+-------+-----+-----+-------+-------------------+-----------+
The authors would like to thank Tom Herbert, Eric Vyncke, Nalini Table 1
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
[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.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 9, line 25 skipping to change at line 370
Ed., "Data Fields for In Situ Operations, Administration, Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>. May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326, Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022, DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>. <https://www.rfc-editor.org/info/rfc9326>.
8.2. Informative References 7.2. Informative References
[I-D.kitamura-ipv6-record-route] [IPV6-RECORD-ROUTE]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Kitamura, H., "Record Route for IPv6 (RR6) Hop-by-Hop
Option Extension", Work in Progress, Internet-Draft, Option Extension", Work in Progress, Internet-Draft,
draft-kitamura-ipv6-record-route-00, November 2000, draft-kitamura-ipv6-record-route-00, 17 November 2000,
<https://tools.ietf.org/id/draft-kitamura-ipv6-record- <https://datatracker.ietf.org/doc/html/draft-kitamura-
route-00.txt>. ipv6-record-route-00>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>. <https://www.rfc-editor.org/info/rfc8250>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>. September 2021, <https://www.rfc-editor.org/info/rfc9098>.
Contributors Acknowledgements
This document was the collective effort of several authors. The text
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.
* Carlos Pignataro
* Hannes Gredler
* John Leddy
* Stephen Youell
* Tal Mizrahi
* Aviv Kfir
* Barak Gafni
* Petr Lapukhov
* Mickey Spiegel
* Suresh Krishnan The authors would like to thank Tom Herbert, Éric 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 [IPV6-RECORD-ROUTE]. The
authors would like to acknowledge the work done by the author Hiroshi
Kitamura and people involved in writing it.
* Rajiv Asati Contributors
* Mark Smith This document was the collective effort of several authors. The text
and content were contributed by the editors and the coauthors listed
below.
Contributors' Addresses Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States of America
Email: cpignata@cisco.com
Carlos Pignataro Hannes Gredler
Cisco Systems, Inc. RtBrick Inc.
7200-11 Kit Creek Road Email: hannes@rtbrick.com
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
Hannes Gredler John Leddy
RtBrick Inc. Email: john@leddy.net
Email: hannes@rtbrick.com
John Leddy Stephen Youell
Email: john@leddy.net JP Morgan Chase
Stephen Youell 25 Bank Street
JP Morgan Chase London
25 Bank Street E14 5JP
London E14 5JP United Kingdom
United Kingdom Email: stephen.youell@jpmorgan.com
Email: stephen.youell@jpmorgan.com
Tal Mizrahi Tal Mizrahi
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
Israel Israel
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Aviv Kfir Aviv Kfir
Mellanox Technologies, Inc. Mellanox Technologies, Inc.
350 Oakmead Parkway, Suite 100 350 Oakmead Parkway, Suite 100
Sunnyvale, CA 94085 Sunnyvale, CA 94085
U.S.A. United States of America
Email: avivk@mellanox.com Email: avivk@mellanox.com
Barak Gafni Barak Gafni
Mellanox Technologies, Inc. Mellanox Technologies, Inc.
350 Oakmead Parkway, Suite 100 350 Oakmead Parkway, Suite 100
Sunnyvale, CA 94085 Sunnyvale, CA 94085
U.S.A. United States of America
Email: gbarak@mellanox.com Email: gbarak@mellanox.com
Petr Lapukhov Petr Lapukhov
Facebook Facebook
1 Hacker Way 1 Hacker Way
Menlo Park, CA 94025 Menlo Park, CA 94025
US United States of America
Email: petr@fb.com Email: petr@fb.com
Mickey Spiegel Mickey Spiegel
Barefoot Networks, an Intel company Barefoot Networks, an Intel company
4750 Patrick Henry Drive 4750 Patrick Henry Drive
Santa Clara, CA 95054 Santa Clara, CA 95054
US United States of America
Email: mickey.spiegel@intel.com Email: mickey.spiegel@intel.com
Suresh Krishnan Suresh Krishnan
Kaloom Kaloom
Email: suresh@kaloom.com Email: suresh@kaloom.com
Rajiv Asati Rajiv Asati
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US United States of America
Email: rajiva@cisco.com Email: rajiva@cisco.com
Mark Smith Mark Smith
PO BOX 521 PO BOX 521
HEIDELBERG, VIC 3084 Heidelberg VIC 3084
AU Australia
Email: markzzzsmith+id@gmail.com Email: markzzzsmith+id@gmail.com
Authors' Addresses Authors' Addresses
Shwetha Bhandari (editor) Shwetha Bhandari (editor)
Thoughtspot Thoughtspot
3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 3rd Floor, Indiqube Orion
Bangalore, KARNATAKA 560 102 24th Main Rd, Garden Layout, HSR Layout
Bangalore 560 102
Karnataka
India India
Email: shwetha.bhandari@thoughtspot.com Email: shwetha.bhandari@thoughtspot.com
Frank Brockners (editor) Frank Brockners (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Hansaallee 249, 3rd Floor Hansaallee 249, 3rd Floor
40549 DUESSELDORF 40549 Duesseldorf
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
 End of changes. 82 change blocks. 
297 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.48.