]>
In-situ OAM IPv6
OptionsCisco Systems, Inc.Cessna Business Park, Sarjapura Marathalli Outer Ring
RoadBangalore, KARNATAKA 560 087Indiashwethab@cisco.comCisco Systems, Inc.Hansaallee 249, 3rd FloorDUESSELDORFNORDRHEIN-WESTFALEN40549Germanyfbrockne@cisco.comCisco Systems, Inc.7200-11 Kit Creek RoadResearch Triangle ParkNC27709United Statescpignata@cisco.comRtBrick Inc.hannes@rtbrick.comComcastJohn_Leddy@cable.comcast.comJP Morgan Chase25 Bank StreetLondonE14 5JPUnited Kingdomstephen.youell@jpmorgan.comHuawei Network.IO Innovation LabIsraeltal.mizrahi.phd@gmail.comMellanox Technologies, Inc.350 Oakmead Parkway, Suite 100Sunnyvale, CA94085U.S.A.avivk@mellanox.comMellanox Technologies, Inc.350 Oakmead Parkway, Suite 100Sunnyvale, CA94085U.S.A.gbarak@mellanox.comFacebook1 Hacker WayMenlo Park, CA94025USpetr@fb.comBarefoot Networks4750 Patrick Henry DriveSanta Clara, CA95054USmspiegel@barefootnetworks.comKaloomsuresh@kaloom.comTransport Area, Internet
ippm,6manIn-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 IOAM data fields are encapsulated in IPv6.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 IOAM data fields are encapsulated in the IPv6 .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 when,
and only when, they appear in all capitals, as shown here.Abbreviations used in this document:Edge-to-EdgeIn-situ Operations, Administration, and
MaintenanceOperations, Administration, and MaintenanceProof of TransitIOAM data is carried in IPv6 packets as Hop-by-Hop or Destination
options. One IPv6 Destination Options and Hop-by-Hop Options Type
codepoint is assigned for IOAM. Multiple options with the same Option
Type MAY appear in the same Hop-by-Hop Options or Destination Options
header, with varying content. This mechanism of in-situ OAM in IPv6 is
used to enhance diagnostics of IPv6 networks. It complements other
mechanisms proposed to enhance diagnostics of IPv6 networks, such as the
IPv6 Performance and Diagnostic Metrics Destination Option described in
.IPv6 Hop-by-Hop and Destination Option format for carrying in-situ
OAM data fields:8-bit identifier of the type of
option.8-bit unsigned integer. Length of the
Reserved and Option Data field of this option, in octets.8-bit field MUST be set to zero upon
transmission and ignored upon reception.8-bit field as defined in section 7.2 in
.Variable-length field.
Option-Type-specific data.In-situ OAM Options are inserted as Option data as follows:Pre-allocated Tracing Option: The in-situ OAM Preallocated
Tracing option defined in is represented as a IPv6
option in hop by hop extension header:
001xxxxx 8-bit identifier of the
IOAM type of option. xxxxx=TBD.IOAM Pre-allocated Trace Option
Type.Incremental Tracing Option: The in-situ OAM Incremental Tracing
option defined in is
represented as a IPv6 option in hop by hop extension header:
001xxxxx 8-bit identifier of the
IOAM type of option. xxxxx=TBD.IOAM Incremental Trace Option Type.Proof of Transit Option: The in-situ OAM POT option defined in
is represented as a
IPv6 option in hop by hop extension header:
001xxxxx 8-bit identifier of the
IOAM type of option. xxxxx=TBD.IOAM POT Option Type.Edge to Edge Option: The in-situ OAM E2E option defined in is represented as a IPv6
option in IPv6 option in destination options extension header:
000xxxxx 8-bit identifier of the
IOAM type of option. xxxxx=TBD.IOAM E2E Option Type.All the in-situ OAM IPv6 options defined here have alignment
requirements. Specifically, they all require 4n alignment. This ensures
that 4 octet fields specified in
such as transit delay are
aligned at a multiple-of-4 offset from the start of the Hop-by-Hop
Options header. In addition, to maintain IPv6 extension header 8-octet
alignment and avoid the need to add or remove padding at every hop, the
Trace-Type for Incremental Tracing Option in IPv6 MUST be selected such
that the IOAM node data length is a multiple of 8-octets.This document describes the encapsulation of IOAM data fields in
IPv6. Security considerations of the specific IOAM data fields for each
case (i.e., Trace, Proof of Transit, and E2E) are described in defined
in .As this document describes new options for IPv6 , these are similar
to the security considerations of and the
new weakness documented in .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.http://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#ipv6-parameters-2The 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, and Andrew Yourtchenko for the comments and advice. For the
IPv6 encapsulation, this document leverages concepts described in . The authors would like
to acknowledge the work done by the author Hiroshi Kitamura and people
involved in writing it.
&RFC2119;
&RFC8174;
&I-D.draft-ietf-ippm-ioam-data;
&RFC8200;
&RFC8250;
Record Route for IPv6 (PR6) Hop-by-Hop Option
Extension