<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!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/reference.RFC.2119.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC5036 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8200 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!ENTITY RFC8250 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8250.xml">
<!ENTITY RFC1772 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1772.xml">
<!ENTITY RFC4193 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY I-D.draft-ietf-ippm-ioam-data SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-ioam-data-04.xml">
<!ENTITY I-D.draft-ioametal-ippm-6man-ioam-ipv6-options SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ioametal-ippm-6man-ioam-ipv6-options-01.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-ioametal-ippm-6man-ioam-ipv6-deployment-03"
     ipr="trust200902">
  <front>
    <title abbrev="In-situ OAM IPv6 encapsulation">Deployment Considerations
    for In-situ OAM with IPv6 Options</title>

    <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Sarjapura Marathalli Outer Ring
          Road</street>

          <city>Bangalore, KARNATAKA 560 087</city>

          <country>India</country>
        </postal>

        <email>shwethab@cisco.com</email>
      </address>
    </author>

    <author fullname="Frank Brockners" initials="F." surname="Brockners">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Kaiserswerther Str. 115,</street>

          <!-- Reorder these if your country does things differently -->

          <city>RATINGEN</city>

          <region>NORDRHEIN-WESTFALEN</region>

          <code>40880</code>

          <country>Germany</country>
        </postal>

        <email>fbrockne@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
      <organization abbrev="">Huawei Network.IO Innovation Lab</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>Israel</country>
        </postal>

        <email>tal.mizrahi.phd@gmail.com</email>
      </address>
    </author>

    <author fullname="Aviv Kfir" initials="A." surname="Kfir">
      <organization abbrev="">Mellanox Technologies, Inc.</organization>

      <address>
        <postal>
          <street>350 Oakmead Parkway, Suite 100</street>

          <city>Sunnyvale, CA</city>

          <code>94085</code>

          <country>U.S.A.</country>
        </postal>

        <email>avivk@mellanox.com</email>
      </address>
    </author>

    <author fullname="Barak Gafni" initials="B." surname="Gafni">
      <organization abbrev="">Mellanox Technologies, Inc.</organization>

      <address>
        <postal>
          <street>350 Oakmead Parkway, Suite 100</street>

          <city>Sunnyvale, CA</city>

          <code>94085</code>

          <country>U.S.A.</country>
        </postal>

        <email>gbarak@mellanox.com</email>
      </address>
    </author>

    <author fullname="Mickey Spiegel" initials="M." surname="Spiegel">
      <organization abbrev="">Barefoot Networks, an Intel
      company</organization>

      <address>
        <postal>
          <street>4750 Patrick Henry Drive</street>

          <city>Santa Clara, CA</city>

          <code>95054</code>

          <country>US</country>
        </postal>

        <email>mickey.spiegel@intel.com</email>
      </address>
    </author>

    <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
      <organization abbrev="">Kaloom</organization>

      <address>
        <email>suresh@kaloom.com</email>
      </address>
    </author>

    <author fullname="Mark Smith" initials="M." surname="Smith">
      <address>
        <postal>
          <street>PO BOX 521</street>

          <city>HEIDELBERG, VIC</city>

          <code>3084</code>

          <country>AU</country>
        </postal>

        <email>markzzzsmith+id@gmail.com</email>
      </address>
    </author>

    <date day="29" month="March" year="2020"/>

    <area>Transport Area, Internet</area>

    <workgroup>ippm,6man</workgroup>

    <abstract>
      <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 IOAM can be enabled in an IPv6 network.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <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. <xref
      target="I-D.ioametal-ippm-6man-ioam-ipv6-options"/> defines how IOAM
      data fields are encapsulated in the IPv6 <xref target="RFC8200"/>. This
      document discusses deployment options for networks which leverage IOAM
      data fields encapsulated in the IPv6 protocol.</t>

      <t>Deployment considerations differ, whether the IOAM domain starts and
      ends on hosts or whether the IOAM encapsulating and decapsulating nodes
      are network devices that forward traffic, such as routers.</t>
    </section>

    <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 title="Abbreviations">
        <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 Operations, Administration, and
            Maintenance</t>

            <t hangText="ION:">IOAM Overlay Network</t>

            <t hangText="OAM:">Operations, Administration, and Maintenance</t>

            <t hangText="POT:">Proof of Transit</t>
          </list></t>
      </section>
    </section>

    <section anchor="v6_requirement"
             title="Considerations for IOAM deployment in IPv6 networks">
      <t>IOAM deployment in an IPv6 network should take the following
      considerations and requirements into account:<list style="hanging">
          <t hangText="C1">It is desirable that the addition of IOAM data
          fields neither changes the way routers forward the packets, nor the
          forwarding decision the routers takes. The packet with the added OAM
          information should follow the same path within the domain that the
          same packet without the OAM information would follow within the
          domain even in the presence of ECMP. Such a behavior is particularly
          interesting for deployments where IOAM data fields are only added
          "on-demand", e.g. to provide further insights in case of undesired
          network behavior for certain flows. Implementations of IOAM should
          ensure that ECMP behavior for packets with and without IOAM data
          fields is the same.</t>

          <t hangText="C2">Given that IOAM data fields increase the total size
          of the packet, the size of the packet including the IOAM data could
          exceed the PMTU. In particular, the incremental trace IOAM HbH
          Option, which is proposed to support hardware implementations of
          IOAM, changes Option Data Length en-route. Operators of an IOAM
          domain are to ensure that the addition of OAM information does not
          lead to fragmentation of the packet, e.g. by configuring the MTU of
          transit routers and switches to a sufficiently high value. Careful
          control of the MTU in a network is one of the reasons why IOAM is
          considered a domain specific feature, see also <xref
          target="I-D.ietf-ippm-ioam-data"/>. In addition, the PMTU tolerance
          range in the IOAM domain should be identified (e.g. through
          configuration) and IOAM encapsulation operations and/or IOAM data
          field insertion (in case of incremental tracing) should not be
          performed if it exceeds the packet size beyond PMTU.</t>

          <t hangText="C3">Packets with IOAM data or associated ICMP errors,
          should not arrive at destinations which have no knowledge of IOAM.
          Consider using IOAM in transit devices; misleading ICMP errors due
          to addition and/or presence of OAM data in the packet can confuse a
          source of the packet that did not insert the OAM information.</t>

          <t hangText="C4">OAM data leaks may affect the forwarding behavior
          and state of network elements outside an IOAM domain. IOAM domains
          SHOULD provide a mechanism to prevent data leaks or be able to
          assure that upon leak network elements outside the domain are not
          affected i.e they continue to process other valid packets.</t>

          <t hangText="C5">The source of that inserted and leaked the IOAM
          data must be easy to identify for the purpose of troubleshooting,
          due to the high complexity of troubleshooting a source that inserted
          the IOAM data and did not remove it when the packet traversed across
          an AS. Such a troubleshooting process may require coordination
          between multiple operators, complicated configuration verification,
          packet capture analysis, etc.</t>

          <t hangText="C6">Compliance with <xref target="RFC8200"/> would
          require OAM data to be encapsulated instead of header/option
          insertion directly into in-flight packets using the original IPv6
          header.</t>
        </list></t>
    </section>

    <section title="IOAM domains bounded by hosts">
      <t>For deployments where the IOAM domain is bounded by hosts, hosts will
      perform the operation of IOAM data field encapsulation and
      decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or
      Destination options, see <xref
      target="I-D.ioametal-ippm-6man-ioam-ipv6-options"/>.</t>
    </section>

    <section title="IOAM domains bounded by network devices">
      <t>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 will perform the operation of IOAM data field encapsulation and
      decapsulation.</t>

      <section title="Deployment options">
        <t>This section lists out possible deployment options that can be
        employed to meet the requirements listed in <xref
        target="v6_requirement"/>.</t>

        <section title="IPv6-in-IPv6 encapsulation">
          <t>Leverage an IPv6-in-IPv6 approach: Preserve the original IP
          packet and add an IPv6 header including IOAM data fields in an
          extension header in front of it, to forward traffic within and
          across the IOAM domain. The overlay network formed by the additional
          IPv6 header with the IOAM data fields included in an extension
          header is referred to as IOAM Overlay Network (ION) in this
          document. <list style="numbers">
              <t>Perform an IPv6-in-IPv6 approach. The source address of the
              outer IPv6 header is that of the IOAM encapsulating node. The
              destination address of the outer IPv6 header is the same as the
              inner IPv6 destination address, i.e. the destination address of
              the packet does not change.</t>

              <t>To simplify debugging in case of leaked IOAM data fields in
              packets, consider a new IOAM E2E destination option to identify
              the Source IOAM domain (AS, v6 prefix). Insert this option into
              the IOAM destination options EH attached to the outer IPv6
              header. This additional information would allow for easy
              identification of an AS operator that is the source of packets
              with leaked IOAM information. Note that leaked packets with IOAM
              data fields would only occur in case a router would be
              misconfigured. <xref
              target="I-D.ioametal-ippm-6man-ioam-ipv6-options"/> requires
              that by default, packets with extension headers which carry IOAM
              data fields are dropped unless the router's interfaces are
              explicitly configured for IOAM.</t>

              <t>All the IOAM options are defined with type "00 - skip over
              this option and continue processing the header. So presence of
              the options must not cause packet drop in the network elements
              that do not understand the option. In addition <xref
              target="I-D.ietf-6man-hbh-header-handling"/> should be
              considered.</t>
            </list></t>
        </section>

        <section title="IP-in-IPv6 encapsulation with ULA">
          <t>The "IP-in-IPv6 encapsulation with ULA" <xref target="RFC4193"/>
          approach can be used to apply IOAM to an IPv6 as well as an IPv4
          network. In addition, it fulfills requirement C4 (avoid leaks) by
          using ULA for the ION. Similar to the IPv6-in-IPv6 encapsulation
          approach above, the original IP packet is preserved. An IPv6 header
          including IOAM data fields in an extension header is added in front
          of it, to forward traffic within and across the IOAM domain. IPv6
          addresses for the ION, i.e. the outer IPv6 addresses are assigned
          from the ULA space. Addressing and routing in the ION are to be
          configured so that the IP-in-IPv6 encapsulated packets follow the
          same path as the original, non-encapsulated packet would have taken.
          This would create an internal IPv6 forwarding topology using the
          IOAM domain's interior ULA address space which is parallel with the
          forwarding topology that exists with the non-IOAM address space (the
          topology and address space that would be followed by packets that do
          not have supplemental IOAM information). Establishment and
          maintenance of the parallel IOAM ULA forwarding topology could be
          automated, e.g. similar to how LDP <xref target="RFC5036"/> is used
          in MPLS to establish and maintain an LSP forwarding topology that is
          parallel to the network's IGP forwarding topology.</t>

          <t>Transit across the ION could leverage the transit approach for
          traffic between BGP border routers, as described in <xref
          target="RFC1772"/>, "A.2.3 Encapsulation". Assuming that the
          operational guidelines specified in Section 4 of <xref
          target="RFC4193"/> are properly followed, the probability of leaks
          in this approach will be almost close to zero. If the packets do
          leak through IOAM egress device misconfiguration or partial IOAM
          egress device failure, the packets' ULA destination address is
          invalid outside of the IOAM domain. There is no exterior destination
          to be reached, and the packets will be dropped when they encounter
          either a router external to the IOAM domain that has a packet filter
          that drops packets with ULA destinations, or a router that does not
          have a default route.</t>
        </section>

        <section title="x-in-IPv6 Encapsulation that is used Independently">
          <t>In some cases it is desirable to monitor a domain that uses an
          overlay network that is deployed independently of the need for IOAM,
          e.g., an overlay network that runs Geneve-in-IPv6, or VXLAN-in-IPv6.
          In this case IOAM can be encapsulated in as an extension header in
          the tunnel (outer) IPv6 header. Thus, the tunnel encapsulating node
          is also the IOAM encapsulating node, and the tunnel end point is
          also the IOAM decapsulating node.</t>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This document discusses the deployment of IOAM with IPv6 options.
      Security considerations of the specific IOAM data fields are described
      in <xref target="I-D.ietf-ippm-ioam-data"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>There are no IANA considerations that apply to this document.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Mark Smith, 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 <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>

    <!---->

    <!-- -->
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC8174;

      &RFC1772;

      &I-D.draft-ietf-ippm-ioam-data;

      &I-D.draft-ioametal-ippm-6man-ioam-ipv6-options;
    </references>

    <references title="Informative References">
      &RFC8200;

      &RFC8250;

      &RFC4193;

      &RFC5036;

      <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>

      <reference anchor="I-D.ietf-6man-hbh-header-handling">
        <front>
          <title>IPv6 Hop-by-Hop Options Extension Header</title>

          <author fullname="Fred Baker" initials="F" surname="Baker"/>

          <author fullname="R. Bonica" initials="R" surname="Bonica"/>

          <date day="16" month="March" year="2016"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
