<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-ippm-2330-ipv6-05"
     ipr="pre5378Trust200902" updates="2330">
  <front>
    <title abbrev="IPPM IPv6 Update">IPv6, IPv4 and Coexistence Updates for
    IPPM's Active Metric Framework</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri>http://home.comcast.net/~acmacm/</uri>
      </address>
    </author>

    <author fullname="Joachim Fabini" initials="J." surname="Fabini">
      <organization>TU Wien</organization>

      <address>
        <postal>
          <street>Gusshausstrasse 25/E389</street>

          <city>Vienna</city>

          <region/>

          <code>1040</code>

          <country>Austria</country>
        </postal>

        <phone>+43 1 58801 38813</phone>

        <facsimile>+43 1 58801 38898</facsimile>

        <email>Joachim.Fabini@tuwien.ac.at</email>

        <uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri>
      </address>
    </author>

    <author fullname="Nalini Elkins" initials="N." surname="Elkins">
      <organization>Inside Products, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city>Carmel Valley</city>

          <region>CA</region>

          <code>93924</code>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>nalini.elkins@insidethestack.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Michael S. Ackermann" initials="M." surname="Ackermann">
      <organization>Blue Cross Blue Shield of Michigan</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>mackermann@bcbsm.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Vinayak Hegde" initials="V." surname="Hegde">
      <organization>Consultant</organization>

      <address>
        <postal>
          <street>Brahma Sun City, Wadgaon-Sheri</street>

          <city>Pune</city>

          <region>Maharashtra</region>

          <code>411014</code>

          <country>INDIA</country>
        </postal>

        <phone>+91 9449834401</phone>

        <email>vinayakh@gmail.com</email>

        <uri>http://www.vinayakhegde.com</uri>
      </address>
    </author>

    <date day="24" month="May" year="2018"/>

    <abstract>
      <t>This memo updates the IP Performance Metrics (IPPM) Framework RFC
      2330 with new considerations for measurement methodology and testing. It
      updates the definition of standard-formed packets in RFC 2330 to include
      IPv6 packets, deprecates the definition of minimum standard-formed
      packet, and augments distinguishing aspects of packets, referred to as
      Type-P for test packets in RFC 2330. This memo identifies that IPv4-IPv6
      co-existence can challenge measurements within the scope of the IPPM
      Framework. Exemplary use cases include, but are not limited to IPv4-IPv6
      translation, NAT, or protocol encapsulation. IPv6 header compression and
      use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are
      considered and excluded from the standard-formed packet evaluation.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119"/>
      and updated by <xref target="RFC8174"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IETF IP Performance Metrics (IPPM) working group first created a
      framework for metric development in <xref target="RFC2330"/>. This
      framework has stood the test of time and enabled development of many
      fundamental metrics. It has been updated in the area of metric
      composition <xref target="RFC5835"/>, and in several areas related to
      active stream measurement of modern networks with reactive properties
      <xref target="RFC7312"/>.</t>

      <t>The IPPM framework <xref target="RFC2330"/> recognized (in section
      13) that many aspects of IP packets can influence its processing during
      transfer across the network.</t>

      <t>In Section 15 of <xref target="RFC2330"/>, the notion of a
      "standard-formed" packet is defined. However, the definition was never
      updated to include IPv6, as the original authors planned.</t>

      <t>In particular, IPv6 Extension Headers and protocols which use IPv6
      header compression are growing in use. This memo seeks to provide the
      needed updates.</t>
    </section>

    <section title="Scope">
      <t>The purpose of this memo is to expand the coverage of IPPM metrics to
      include IPv6, and to highlight additional aspects of test packets and
      make them part of the IPPM performance metric framework.</t>

      <t>The scope is to update key sections of <xref target="RFC2330"/>,
      adding considerations that will aid the development of new measurement
      methodologies intended for today's IP networks. Specifically, this memo
      expands the Type-P examples in section 13 of <xref target="RFC2330"/>
      and expands the definition (in section 15 of <xref target="RFC2330"/>)
      of a standard-formed packet to include IPv6 header aspects and other
      features.</t>

      <t>Other topics in <xref target="RFC2330"/> which might be updated or
      augmented are deferred to future work. This includes the topics of
      passive and various forms of hybrid active/passive measurements.</t>
    </section>

    <section title="Packets of Type-P">
      <t>A fundamental property of many Internet metrics is that the measured
      value of the metric depends on characteristics of the IP packet(s) used
      to make the measurement. Potential influencing factors include IP header
      fields and their values, but also higher-layer protocol headers and
      their values. Consider an IP-connectivity metric: one obtains different
      results depending on whether one is interested in connectivity for
      packets destined for well-known TCP ports or unreserved UDP ports, or
      those with invalid IPv4 checksums, or those with TTL or Hop Limit of 16,
      for example. In some circumstances these distinctions will result in
      special treatment of packets in intermediate nodes and end systems (for
      example, if Diffserv <xref target="RFC2474"/>, ECN <xref
      target="RFC3168"/>, Router Alert, Hop-by-hop extensions <xref
      target="RFC7045"/>, or Flow Labels <xref target="RFC6437"/> are used, or
      in the presence of firewalls or RSVP reservations).</t>

      <t>Because of this distinction, we introduce the generic notion of a
      "packet of Type-P", where in some contexts P will be explicitly defined
      (i.e., exactly what type of packet we mean), partially defined (e.g.,
      "with a payload of B octets"), or left generic. Thus we may talk about
      generic IP-Type-P-connectivity or more specific
      IP-port-HTTP-connectivity. Some metrics and methodologies may be
      fruitfully defined using generic Type-P definitions which are then made
      specific when performing actual measurements.</t>

      <t>Whenever a metric's value depends on the type of the packets involved
      in the metric, the metric's name will include either a specific type or
      a phrase such as "Type-P". Thus we will not define an "IP-connectivity"
      metric but instead an "IP-Type-P-connectivity" metric and/or perhaps an
      "IP-port-HTTP-connectivity" metric. This naming convention serves as an
      important reminder that one must be conscious of the exact type of
      traffic being measured.</t>

      <t>If the information constituting Type-P at the Source is found to have
      changed at the Destination (or at a measurement point between the Source
      and Destination, as in <xref target="RFC5644"/>), then the modified
      values MUST be noted and reported with the results. Some modifications
      occur according to the conditions encountered in transit (such as
      congestion notification) or due to the requirements of segments of the
      Source to Destination path. For example, the packet length will change
      if IP headers are converted to the alternate version/address family, or
      if optional Extension Headers are added or removed. Even header fields
      like TTL/Hop Limit that typically change in transit may be relevant to
      specific tests. For example Neighbor Discovery Protocol (NDP) <xref
      target="RFC4861"/> packets are transmitted with Hop Limit value set to
      255, and the validity test specifies that the Hop Limit MUST have a
      value of 255 at the receiver, too. So, while other tests may
      intentionally exclude the TTL/Hop Limit value from their Type-P
      definition, for this particular test the correct Hop Limit value is of
      high relevance and MUST be part of the Type-P definition.</t>

      <t>Local policies in intermediate nodes based on examination of IPv6
      Extension Headers may affect measurement repeatability. If intermediate
      nodes follow the recommendations of <xref target="RFC7045"/>,
      repeatability may be improved to some degree.</t>

      <t>A closely related note: it would be very useful to know if a given
      Internet component (like host, link, or path) treats equally a class C
      of different types of packets. If so, then any one of those types of
      packets can be used for subsequent measurement of the component. This
      suggests we devise a metric or suite of metrics that attempt to
      determine C.</t>

      <t>Load balancing over parallel paths is one particular example where
      such a class C would be more complex to determine in IPPM measurements.
      Load balancers often use flow identifiers, computed as hashes of
      (specific parts of) the packet header, for deciding among the available
      parallel paths a packet will traverse. Packets with identical hashes are
      assigned to the same flow and forwarded to the same resource in the load
      balancer's pool. The presence of a load balancer on the measurement
      path, as well as the specific headers and fields that are used for the
      forwarding decision, are not known when measuring the path as a
      black-box. Potential assessment scenarios include the measurement of one
      of the parallel paths, and the measurement of all available parallel
      paths that the load balancer can use. Knowledge of a load balancer's
      flow definition (alternatively: its class C specific treatment in terms
      of header fields in scope of hash operations) is therefore a
      prerequisite for repeatable measurements. A path may have more than one
      stage of load balancing, adding to class C definition complexity.</t>
    </section>

    <section title="Standard-Formed Packets">
      <t>Unless otherwise stated, all metric definitions that concern IP
      packets include an implicit assumption that the packet is
      *standard-formed*. A packet is standard-formed if it meets all of the
      following REQUIRED criteria:</t>

      <t><list style="hanging">
          <t hangText="+">It includes a valid IP header: see below for
          version-specific criteria.</t>

          <t hangText="+">It is not an IP fragment.</t>

          <t hangText="+">The Source and Destination addresses correspond to
          the intended Source and Destination, including Multicast Destination
          addresses.</t>

          <t hangText="+">If a transport header is present, it contains a
          valid checksum and other valid fields.</t>
        </list>For an IPv4 (<xref target="RFC0791"/> and updates) packet to be
      standard-formed, the following additional criteria are REQUIRED:<list
          style="symbols">
          <t>The version field is 4</t>

          <t>The Internet Header Length (IHL) value is &gt;= 5; the checksum
          is correct.</t>

          <t>Its total length as given in the IPv4 header corresponds to the
          size of the IPv4 header plus the size of the payload.</t>

          <t>Either the packet possesses sufficient TTL to travel from the
          Source to the Destination if the TTL is decremented by one at each
          hop, or it possesses the maximum TTL of 255.</t>

          <t>It does not contain IP options unless explicitly noted.</t>
        </list></t>

      <t>For an IPv6 (<xref target="RFC8200"/> and updates) packet to be
      standard-formed, the following criteria are REQUIRED:<list
          style="symbols">
          <t>The version field is 6.</t>

          <t>Its total length corresponds to the size of the IPv6 header (40
          octets) plus the length of the payload as given in the IPv6
          header.</t>

          <t>The payload length value for this packet (including Extension
          Headers) conforms to the IPv6 specifications.</t>

          <t>Either the packet possesses sufficient Hop Limit to travel from
          the Source to the Destination if the Hop Limit is decremented by one
          at each hop, or it possesses the maximum Hop Limit of 255.</t>

          <t>Either the packet does not contain IP Extension Headers, or it
          contains the correct number and type of headers as specified in the
          packet, and the headers appear in the standard-conforming order
          (Next Header).</t>

          <t>All parameters used in the header and Extension Headers are found
          in the IANA Registry of Internet Protocol Version 6 (IPv6)
          Parameters, partly specified in <xref target="IANA-6P"/>.</t>
        </list></t>

      <t>Two mechanisms require some discussion in the context of
      standard-formed packets, namely IPv6 over Low-Power Wireless Area
      Networks (6LowPAN, <xref target="RFC4494"/>) and Robust Header
      Compression (ROHC, <xref target="RFC3095"/>). IPv6 over Low-Power
      Wireless Area Networks (6LowPAN), as defined in <xref target="RFC4494"/>
      and updated by <xref target="RFC6282"/> with header compression and
      <xref target="RFC6775"/> with neighbor discovery optimizations proposes
      solutions for using IPv6 in resource-constrained environments. An
      adaptation layer enables the transfer of IPv6 packets over networks
      having a MTU smaller than the minimum IPv6 MTU. Fragmentation and
      re-assembly of IPv6 packets, as well as the resulting state that would
      be stored in intermediate nodes, poses substantial challenges to
      measurements. Likewise, ROHC operates statefully in compressing headers
      on subpaths, storing state in intermediate hosts. The modification of
      measurement packets' Type-P by ROHC and 6LowPAN, as well as requirements
      with respect to the concept of standard-formed packets for these two
      protocols requires substantial work. Because of these reasons we
      consider ROHC and 6LowPAN packets to be out of the scope for the
      standard-formed packet evaluation.</t>

      <t>The topic of IPv6 Extension Headers brings current controversies into
      focus as noted by <xref target="RFC6564"/> and <xref target="RFC7045"/>.
      However, measurement use cases in the context of the IPPM framework like
      in-situ OAM <xref target="I-D.ietf-ippm-ioam-data"/> in enterprise
      environments can benefit from inspection, modification, addition or
      deletion of IPv6 extension headers in hosts along the measurement
      path.</t>

      <t><xref target="RFC8250"/> endorses the use of IPv6 extension headers
      for measurement purposes, consistent with other approved IETF
      specifications.</t>

      <t>The following additional considerations apply when IPv6 Extension
      Headers are present:</t>

      <t><list style="symbols">
          <t>Extension Header inspection: Some intermediate nodes may inspect
          Extension Headers or the entire IPv6 packet while in transit. In
          exceptional cases, they may drop the packet or route via a
          sub-optimal path, and measurements may be unreliable or
          unrepeatable. The packet (if it arrives) may be standard-formed,
          with a corresponding Type-P.</t>

          <t>Extension Header modification: In Hop-by-Hop headers, some TLV
          encoded options may be permitted to change at intermediate nodes
          while in transit. The resulting packet may be standard-formed, with
          a corresponding Type-P.</t>

          <t>Extension Header insertion or deletion: Although such behavior is
          not endorsed by current standards, it is possible that Extension
          Headers could be added to, or removed from the header chain. The
          resulting packet may be standard-formed, with a corresponding
          Type-P.</t>

          <t>A change in packet length (from the corresponding packet observed
          at the Source) or header modification is a significant factor in
          Internet measurement, and REQUIRES a new Type-P to be reported with
          the test results.</t>
        </list>It is further REQUIRED that if a packet is described as having
      a "length of B octets", then 0 &lt;= B &lt;= 65535; and if B is the
      payload length in octets, then B &lt;= (65535-IP header size in octets,
      including any Extension Headers). The jumbograms defined in <xref
      target="RFC2675"/> are not covered by the above length analysis, but if
      the IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a
      packet with corresponding length MUST be considered standard-formed. In
      practice, the path MTU will restrict the length of standard-formed
      packets that can successfully traverse the path. Path MTU Discovery for
      IP version 6 (PMTUD, <xref target="RFC8201"/>) or Packetization Layer
      Path MTU Discovery (PLPMTUD, <xref target="RFC4821"/>) is recommended to
      prevent fragmentation.</t>

      <t>So, for example, one might imagine defining an IP connectivity metric
      as "IP-type-P-connectivity for standard-formed packets with the IP
      Diffserv field set to 0", or, more succinctly, "IP-type-P-connectivity
      with the IP Diffserv Field set to 0", since standard-formed is already
      implied by convention. Changing the contents of a field, such as the
      Diffserv Code Point, ECN bits, or Flow Label may have a profound affect
      on packet handling during transit, but does not affect a packet's status
      as standard-formed. Likewise, the addition, modification, or deletion of
      extension headers may change the handling of packets in transit
      hosts.</t>

      <t><xref target="RFC2330"/> defines the "minimal IP packet from A to B"
      as a particular type of standard-formed packet often useful to consider.
      When defining IP metrics no packet smaller or simpler than this can be
      transmitted over a correctly operating IP network. However, the concept
      of the minimal IP packet has not been employed (since typical active
      measurement systems employ a transport layer and a payload) and its
      practical use is limited. Therefore, this memo deprecates the concept of
      the "minimal IP packet from A to B".</t>
    </section>

    <section title="NAT, IPv4-IPv6 Transition and Compression Techniques">
      <t>This memo adds the key considerations for utilizing IPv6 in two
      critical conventions of the IPPM Framework, namely packets of Type-P and
      standard-formed packets. The need for co-existence of IPv4 and IPv6 has
      originated transitioning standards like the Framework for IPv4/IPv6
      Translation in <xref target="RFC6144"/> or IP/ICMP Translation
      Algorithms in <xref target="RFC7915"/> and <xref target="RFC7757"/>.</t>

      <t>The definition and execution of measurements within the context of
      the IPPM Framework is challenged whenever such translation mechanisms
      are present along the measurement path. In particular use cases like
      IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header
      compression may result in modification of the measurement packet's
      Type-P along the path. All these changes MUST be reported. Exemplary
      consequences include, but are not limited to:</t>

      <t><list style="symbols">
          <t>Modification or addition of headers or header field values in
          intermediate nodes. IPv4-IPv6 transitioning or IPv6 header
          compression mechanisms may result in changes of the measurement
          packets' Type-P, too. Consequently, hosts along the measurement path
          may treat packets differently because of the Type-P modification.
          Measurements at observation points along the path may also need
          extra context to uniquely identify a packet.</t>

          <t>Network Address Translators (NAT) on the path can have
          unpredictable impact on latency measurement (in terms of the amount
          of additional time added), and possibly other types of measurements.
          It is not usually possible to control this impact (as testers may
          not have any control of the underlying network or middleboxes).
          There is a possibility that stateful NAT will lead to unstable
          performance for a flow with specific Type-P, since state needs to be
          created for the first packet of a flow, and state may be lost later
          if the NAT runs out of resources. However, this scenario does not
          invalidate the Type-P for testing - for example the purpose of a
          test might be exactly to quantify the NAT's impact on delay
          variation. The presence of NAT may mean that the measured
          performance of Type-P will change between the source and the
          destination. This can cause an issue when attempting to correlate
          measurements conducted on segments of the path that include or
          exclude the NAT. Thus, it is a factor to be aware of when conducting
          measurements.</t>

          <t>Variable delay due to internal state. One side effect of changes
          due to IPv4-IPv6 transitioning mechanisms is the variable delay that
          intermediate nodes spend for header modifications. Similar to NAT
          the allocation of internal state and establishment of context within
          intermediate nodes may cause variable delays, depending on the
          measurement stream pattern and position of a packet within the
          stream. For example the first packet in a stream will typically
          trigger allocation of internal state in an intermediate IPv4-IPv6
          transition host. Subsequent packets can benefit from lower
          processing delay due to the existing internal state. However, large
          inter-packet delays in the measurement stream may result in the
          intermediate host deleting the associated state and needing to
          re-establish it on arrival of another stream packet. It is worth
          noting that this variable delay due to internal state allocation in
          intermediate nodes can be an explicit use case for measurements.</t>

          <t>Variable delay due to packet length. IPv4-IPv6 transitioning or
          header compression mechanisms modify the length of measurement
          packets. The modification of the packet size may or may not change
          the way how the measurement path treats the packets.</t>
        </list></t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations that apply to any active measurement of
      live paths are relevant here as well. See <xref target="RFC4656"/> and
      <xref target="RFC5357"/>.</t>

      <t>When considering privacy of those involved in measurement or those
      whose traffic is measured, the sensitive information available to
      potential observers is greatly reduced when using active techniques
      which are within this scope of work. Passive observations of user
      traffic for measurement purposes raise many privacy issues. We refer the
      reader to the privacy considerations described in the Large Scale
      Measurement of Broadband Performance (LMAP) Framework <xref
      target="RFC7594"/>, which covers active and passive techniques.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo makes no requests of IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank Brian Carpenter for identifying the lack of IPv6
      coverage in IPPM's Framework, and for listing additional distinguishing
      factors for packets of Type-P. Both Brian and Fred Baker discussed many
      of the interesting aspects of IPv6 with the co-authors, leading to a
      more solid first draft: thank you both. Thanks to Bill Jouris for an
      editorial pass through the pre-00 text.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.0791'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2330'?>

      <?rfc include='reference.RFC.2474'?>

      <?rfc include='reference.RFC.2675'?>

      <?rfc ?>

      <?rfc include='reference.RFC.3168'?>

      <?rfc include='reference.RFC.3095'?>

      <?rfc include='reference.RFC.4494'?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.4821'?>

      <?rfc include='reference.RFC.4861'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.5644'?>

      <?rfc include='reference.RFC.5835'?>

      <?rfc include='reference.RFC.6144'?>

      <?rfc include='reference.RFC.6282'?>

      <?rfc include='reference.RFC.6437'?>

      <?rfc include='reference.RFC.6564'?>

      <?rfc include='reference.RFC.6775'?>

      <?rfc include='reference.RFC.7045'?>

      <?rfc include='reference.RFC.7312'?>

      <?rfc include='reference.RFC.7757'?>

      <?rfc include='reference.RFC.7915'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8200'?>

      <?rfc include='reference.RFC.8201'?>

      <?rfc include='reference.RFC.8250'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7594'?>

      <?rfc include='reference.I-D.ietf-ippm-ioam-data'?>

      <reference anchor="IANA-6P">
        <front>
          <title>IANA Internet Protocol Version 6 (IPv6) Parameters</title>

          <author fullname="IANA" initials="" surname="IANA">
            <!-- fullname="Internet Assigned Numbers Authority" -->

            <organization>IANA</organization>
          </author>

          <date day="" month="January" year="2018"/>
        </front>

        <seriesInfo name="Internet Assigned Numbers Authority"
                    value="https://www.iana.org/assignments/ipv6-parameters"/>
      </reference>
    </references>
  </back>
</rfc>
