rfc-xmldiff draft-ietf-ippm-2330-ipv6-06.original.xml draft-ietf-ippm-2330-ipv6-06.xml

<?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-06"
     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="30" month="June" 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 minimal IP 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. Example 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", "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>
    </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 originally desired to
      do.</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 <xref target="RFC6398"/>, 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 class C (a designation which has no relationship to address
      assignments, of course).</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 and routers 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 (or router'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, 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="RFC4944"/>) and Robust Header
      Compression (ROHC, <xref target="RFC3095"/>). IPv6 over Low-Power
      Wireless Area Networks (6LowPAN), as defined in <xref target="RFC4944"/>
      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 Destination Option
      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. This point simply encourages measurement system designers to
          be prepared for the unexpected, and to notify users when such events
          occur. There are issues with Extension Header insertion and deletion
          of course, such as exceeding the path MTU due to insertion, etc.</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. Example
      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. As we completed our journey,
      Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh
      Krishnan all contributed useful suggestions.</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.4944'?>

      <?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.6398'?>

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

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

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

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

      <?rfc ?>

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

<?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-06" ipr="pre5378Trust200902" updates="2330" obsoletes="" submissionType="IETF" {http://www.w3.org/XML/1998/namespace}lang="en" number="XXXX" consensus="yes">
- <front>
  - <title abbrev="IPPM IPv6 Update">
    - IPv6, IPv4 and Coexistence Updates for IPPM's the Active Metric Framework of IP Performance Metrics (IPPM)
    - </title>
  - <author fullname="Al Morton" initials="A." surname="Morton">
    - <organization>
      - AT&T Labs
      - </organization>
    - <address>
      - <postal>
        
        <street>
        
        200 Laurel Avenue South
        
        </street>
        
        <city>
        
        Middletown
        
        </city>
        
        <region>
        
        NJ
        
        </region>
        
        <code>
        
        07748
        
        </code>
        
        <country>
        
        USA United States of America
        
        </country>
        
        </postal>
      - <phone>
        
        +1 732 420 1571
        
        </phone>
      - <facsimile>
        
        +1 732 368 1192
        
        </facsimile>
      - <email>
        
        acmorton@att.com
        
        </email>
      - <--[rfced] The following URI does not seem to work. Please update or remove.
        
        ORIGINAL:
        http://home.comcast.net/~acmacm/
        -->
      - <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 United States of America
        
        </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 India
        
        </country>
        
        </postal>
      - <phone>
        
        +91 9449834401
        
        </phone>
      - <email>
        
        vinayakh@gmail.com
        
        </email>
      - <uri>
        
        http://www.vinayakhegde.com
        
        </uri>
      - </address>
    - </author>
  - <date day="30" month="June" "August" year="2018"/>
  - <-- [rfced] Please insert any keywords (beyond those that appear in
    the title) for use on https://www.rfc-editor.org/search.
    -->
  - <keyword>
    - example
    - </keyword>
  - <abstract>
    - <t>
      - This memo updates the IP Performance Metrics (IPPM) Framework framework defined by 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 minimal IP packet, and augments distinguishing aspects of packets, aspects, referred to as Type-P type p, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 co-existence coexistence can challenge measurements within the scope of the IPPM Framework. framework. Example use cases include, but are not limited to to, IPv4-IPv6 translation, NAT, or and 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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14<xref target="RFC2119" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/> when, and only when, they appear in all capitals, as shown here.
      - </t>
    - </note>
  - </front>
- <middle>
  - <section title="Introduction" numbered="true" toc="default">
    - <t>
      - The IETF IP Performance Metrics (IPPM) working group first created a framework for metric development in <xref target="RFC2330" format="default" pageno="false"/>. 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" format="default" pageno="false"/>, "false"/> and in several areas related to active stream measurement of modern networks with reactive properties <xref target="RFC7312" format="default" pageno="false"/>.
      - </t>
    - <t>
      - The IPPM framework <xref target="RFC2330" format="default" pageno="false"/> recognized (in section Section 13) that many aspects of an IP packets packet can influence its processing during transfer across the network.
      - </t>
    - <t>
      - In Section 15 of <xref target="RFC2330" format="default" pageno="false"/>, the notion of a "standard-formed" packet is defined. However, the definition was never updated to include IPv6, as the original authors originally desired to do.
      - </t>
    - <t>
      - In particular, IPv6 Extension Headers and protocols which that use IPv6 header compression are growing in use. This memo seeks to provide the needed updates.
      - </t>
    - </section>
  - <section title="Requirements Language" numbered="true" toc="default">
    - <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" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/> when, and only when, they appear in all capitals, as shown here.
      - </t>
    - </section>
  - <section title="Scope" numbered="true" toc="default">
    - <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 packets, and make them part of the IPPM performance metric framework.
      - </t>
    - <t>
      - The scope is to update key sections of <xref target="RFC2330" format="default" pageno="false"/>, adding considerations that will aid the development of new measurement methodologies intended for today's IP networks. Specifically, this memo expands the Type-P type-p examples in section Section 13 of <xref target="RFC2330" format="default" pageno="false"/> and expands the definition (in section 15 of <xref target="RFC2330" format="default" pageno="false"/>) Section 15) of a standard-formed packet to include IPv6 header aspects and other features.
      - </t>
    - <t>
      - Other topics in <xref target="RFC2330" format="default" pageno="false"/> which that 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" Type P" numbered="true" toc="default">
    - <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 as well as higher-layer protocol headers and their values. Consider an IP-connectivity metric: one obtains different results depending on whether one is interested in in, for example, 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. 16. In some circumstances circumstances, these distinctions will result in special treatment of packets in intermediate nodes and end systems (for -- for example, if Diffserv <xref target="RFC2474" format="default" pageno="false"/>, ECN Explicit Congestion Notification (ECN) <xref target="RFC3168" format="default" pageno="false"/>, Router Alert <xref target="RFC6398" format="default" pageno="false"/>, Hop-by-hop Hop-by-Hop extensions <xref target="RFC7045" format="default" pageno="false"/>, or Flow Labels <xref target="RFC6437" format="default" pageno="false"/> are used, or in the presence of firewalls or RSVP reservations). reservations.
      - </t>
    - <t>
      - Because of this distinction, we introduce the generic notion of a "packet of Type-P", 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 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 involved, the metric, the metric's name will include either a specific type or a phrase such as "Type-P". "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 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" format="default" pageno="false"/>), 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 Source-to-Destination path. For example, the packet length will change if IP headers are converted to the alternate version/address family, family or if
        <--[rfced] Does the second sentence here state conditions that are always
        true or give examples of what might be true in some cases? Please clarify.
        
        ORIGINAL:
        Even header fields like TTL/Hop Limit that typically change in transit may
        be relevant to specific tests. For example, Neighbor Discovery
        Protocol (NDP) [RFC4861] packets are transmitted with the 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.
        
        PERHAPS:
        Even header fields like TTL/Hop Limit that typically change in transit may
        be relevant to specific tests. For example, Neighbor Discovery
        Protocol (NDP) [RFC4861] packets could be transmitted with the Hop Limit
        value set to 255, while 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.
        
        -->
        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 example, Neighbor Discovery Protocol (NDP) <xref target="RFC4861" format="default" pageno="false"/> packets are transmitted with the 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 type-p definition, for this particular test test, the correct Hop Limit value is of high relevance and MUST be part of the Type-P 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" format="default" pageno="false"/>, repeatability may be improved to some degree.
      - </t>
    - <t>
      - A closely related note: it 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 class C (a designation which that has no relationship to address assignments, of course).
      - </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 and routers often use flow identifiers, computed as hashes of (specific parts of) 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 (or router'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. 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" numbered="true" toc="default">
    - <t>
      - Unless otherwise stated, all metric definitions that concern IP packets include an implicit assumption that the packet is *standard-formed*. 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 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" format="default" pageno="false"/> and updates) packet to be standard-formed, the following additional criteria are REQUIRED:
      - <list style="symbols">
        
        <t>
        
        The version field is 4 4.
        
        </t>
        
        <--[rfced] This bullet point seems to contain two different
        requirements. Please check whether they should each have their own bullet
        point or remain together.
        
        ORIGINAL:
        The Internet Header Length (IHL) value is >= 5; the checksum is
        correct.
        -->
        
        <t>
        
        The Internet Header Length (IHL) value is >= 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" format="default" pageno="false"/> 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, specified in <xref target="IANA-6P" format="default" pageno="false"/>.
        
        </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, (6LowPAN) <xref target="RFC4944" format="default" pageno="false"/>) "false"/> and Robust Header Compression (ROHC, (ROHC) <xref target="RFC3095" format="default" pageno="false"/>). IPv6 over Low-Power Wireless Area Networks (6LowPAN), "false"/>. 6LowPAN, as defined in <xref target="RFC4944" format="default" pageno="false"/> and updated by <xref target="RFC6282" format="default" pageno="false"/> with header compression and <xref target="RFC6775" format="default" pageno="false"/> 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 an MTU smaller than the minimum IPv6 MTU. Fragmentation and re-assembly reassembly 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 type p by ROHC and 6LowPAN, as well 6LowPAN requires substantial work, as do requirements with respect to the concept of standard-formed packets for these two protocols requires substantial work. Because of protocols. For these reasons reasons, we consider ROHC and 6LowPAN packets to be out of the scope for of the standard-formed packet evaluation.
      - </t>
    - <t>
      - The topic of IPv6 Extension Headers brings current controversies into focus focus, as noted by <xref target="RFC6564" format="default" pageno="false"/> and <xref target="RFC7045" format="default" pageno="false"/>. However, measurement use cases in the context of the IPPM framework like framework, such as in-situ OAM <xref target="I-D.ietf-ippm-ioam-data" "IOAM-DATA" format="default" pageno="false"/> in enterprise environments environments, can benefit from inspection, modification, addition addition, or deletion of IPv6 extension headers in hosts along the measurement path.
      - </t>
    - <t>
      - <xref target="RFC8250" format="default" pageno="false"/> endorses the use of the IPv6 Destination Option 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 suboptimal path, and measurements may be unreliable or unrepeatable. The packet (if it arrives) may be standard-formed, with a corresponding Type-P. type p.
        
        </t>
        
        <t>
        
        Extension Header modification: In Hop-by-Hop headers, some TLV encoded 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. 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 from, the header chain. The resulting packet may be standard-formed, with a corresponding Type-P. type p. This point simply encourages measurement system designers to be prepared for the unexpected, unexpected and to notify users when such events occur. There are issues with Extension Header insertion and deletion deletion, of course, such as exceeding the path MTU due to insertion, etc.
        
        </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, measurement and REQUIRES a new Type-P 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 <= B <= 65535; and if B is the payload length in octets, then B <= (65535-IP header size in octets, including any Extension Headers). The jumbograms defined in <xref target="RFC2675" format="default" pageno="false"/> 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" format="default" pageno="false"/>) or Packetization Layer Path MTU Discovery (PLPMTUD, <xref target="RFC4821" format="default" pageno="false"/>) is recommended to prevent fragmentation.
      - </t>
    - <t>
      - So, for example, one might imagine defining an IP connectivity 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 effect 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" format="default" pageno="false"/> 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 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 Transition, and Compression Techniques" numbered="true" toc="default">
    - <t>
      - This memo adds the key considerations for utilizing IPv6 in two critical conventions of the IPPM Framework, framework, namely packets of Type-P type p and standard-formed packets. The need for co-existence coexistence of IPv4 and IPv6 has originated transitioning standards like the Framework framework for IPv4/IPv6 Translation in <xref target="RFC6144" format="default" pageno="false"/> or IP/ICMP Translation Algorithms in <xref target="RFC7915" format="default" pageno="false"/> and <xref target="RFC7757" format="default" pageno="false"/>.
      - </t>
    - <t>
      - The definition and execution of measurements within the context of the IPPM Framework 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 type p along the path. All these changes MUST be reported. Example 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, type p, too. Consequently, hosts along the measurement path may treat packets differently because of the Type-P 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 an unpredictable impact on latency measurement (in terms of the amount of additional time added), added) and possibly other types of measurements. It is not usually possible to control this impact (as as testers may not have any control of the underlying network or middleboxes). middleboxes. There is a possibility that stateful NAT will lead to unstable performance for a flow with specific Type-P, 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 type p for testing - testing; for example 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 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, 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 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 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 interpacket 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" numbered="true" toc="default">
    - <t>
      - The security considerations that apply to any active measurement of live paths are relevant here as well. See <xref target="RFC4656" format="default" pageno="false"/> and <xref target="RFC5357" format="default" pageno="false"/>.
      - </t>
    - <t>
      - When considering the 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 that 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 framework <xref target="RFC7594" format="default" pageno="false"/>, which covers active and passive techniques.
      - </t>
    - </section>
  - <section anchor="IANA" title="IANA Considerations" numbered="true" toc="default">
    - <t>
      - This memo makes document has no requests of IANA. IANA actions.
      - </t>
    - </section>
  - <section anchor="Acknowledgements" title="Acknowledgements" numbered="true" toc="default">
    - <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. As we completed our journey, Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh Krishnan all contributed useful suggestions.
      - </t>
    - </section>
  - </middle>
- <back>
  - <references title="Normative References">
    - <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791">
      - <front>
        
        <title>
        
        Internet Protocol
        
        </title>
        
        <author initials="J." surname="Postel" fullname="J. Postel">
        
        <organization/>
        
        </author>
        
        <date year="1981" month="September"/>
        
        </front>
      - <seriesInfo name="STD" value="5"/>
      - <seriesInfo name="RFC" value="791"/>
      - <seriesInfo name="DOI" value="10.17487/RFC0791"/>
      - </reference>
    - <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
      - <front>
        
        <title>
        
        Key words for use in RFCs to Indicate Requirement Levels
        
        </title>
        
        <author initials="S." surname="Bradner" fullname="S. Bradner">
        
        <organization/>
        
        </author>
        
        <date year="1997" month="March"/>
        
        <abstract>
        
        <t>
        
        In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="BCP" value="14"/>
      - <seriesInfo name="RFC" value="2119"/>
      - <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      - </reference>
    - <reference anchor="RFC2330" target="https://www.rfc-editor.org/info/rfc2330">
      - <front>
        
        <title>
        
        Framework for IP Performance Metrics
        
        </title>
        
        <author initials="V." surname="Paxson" fullname="V. Paxson">
        
        <organization/>
        
        </author>
        
        <author initials="G." surname="Almes" fullname="G. Almes">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Mahdavi" fullname="J. Mahdavi">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Mathis" fullname="M. Mathis">
        
        <organization/>
        
        </author>
        
        <date year="1998" month="May"/>
        
        <abstract>
        
        <t>
        
        The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="2330"/>
      - <seriesInfo name="DOI" value="10.17487/RFC2330"/>
      - </reference>
    - <reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2474">
      - <front>
        
        <title>
        
        Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
        
        </title>
        
        <author initials="K." surname="Nichols" fullname="K. Nichols">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Blake" fullname="S. Blake">
        
        <organization/>
        
        </author>
        
        <author initials="F." surname="Baker" fullname="F. Baker">
        
        <organization/>
        
        </author>
        
        <author initials="D." surname="Black" fullname="D. Black">
        
        <organization/>
        
        </author>
        
        <date year="1998" month="December"/>
        
        <abstract>
        
        <t>
        
        This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="2474"/>
      - <seriesInfo name="DOI" value="10.17487/RFC2474"/>
      - </reference>
    - <reference anchor="RFC2675" target="https://www.rfc-editor.org/info/rfc2675">
      - <front>
        
        <title>
        
        IPv6 Jumbograms
        
        </title>
        
        <author initials="D." surname="Borman" fullname="D. Borman">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Deering" fullname="S. Deering">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Hinden" fullname="R. Hinden">
        
        <organization/>
        
        </author>
        
        <date year="1999" month="August"/>
        
        <abstract>
        
        <t>
        
        This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="2675"/>
      - <seriesInfo name="DOI" value="10.17487/RFC2675"/>
      - </reference>
    - <?rfc ?>
    - <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168">
      - <front>
        
        <title>
        
        The Addition of Explicit Congestion Notification (ECN) to IP
        
        </title>
        
        <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Floyd" fullname="S. Floyd">
        
        <organization/>
        
        </author>
        
        <author initials="D." surname="Black" fullname="D. Black">
        
        <organization/>
        
        </author>
        
        <date year="2001" month="September"/>
        
        <abstract>
        
        <t>
        
        This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="3168"/>
      - <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      - </reference>
    - <reference anchor="RFC3095" target="https://www.rfc-editor.org/info/rfc3095">
      - <front>
        
        <title>
        
        RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
        
        </title>
        
        <author initials="C." surname="Bormann" fullname="C. Bormann">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Burmeister" fullname="C. Burmeister">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Degermark" fullname="M. Degermark">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Fukushima" fullname="H. Fukushima">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Hannu" fullname="H. Hannu">
        
        <organization/>
        
        </author>
        
        <author initials="L-E." surname="Jonsson" fullname="L-E. Jonsson">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Koren" fullname="T. Koren">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Le" fullname="K. Le">
        
        <organization/>
        
        </author>
        
        <author initials="Z." surname="Liu" fullname="Z. Liu">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Martensson" fullname="A. Martensson">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Svanbro" fullname="K. Svanbro">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Wiebke" fullname="T. Wiebke">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Yoshimura" fullname="T. Yoshimura">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Zheng" fullname="H. Zheng">
        
        <organization/>
        
        </author>
        
        <date year="2001" month="July"/>
        
        <abstract>
        
        <t>
        
        This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="3095"/>
      - <seriesInfo name="DOI" value="10.17487/RFC3095"/>
      - </reference>
    - <reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4944">
      - <front>
        
        <title>
        
        Transmission of IPv6 Packets over IEEE 802.15.4 Networks
        
        </title>
        
        <author initials="G." surname="Montenegro" fullname="G. Montenegro">
        
        <organization/>
        
        </author>
        
        <author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Hui" fullname="J. Hui">
        
        <organization/>
        
        </author>
        
        <author initials="D." surname="Culler" fullname="D. Culler">
        
        <organization/>
        
        </author>
        
        <date year="2007" month="September"/>
        
        <abstract>
        
        <t>
        
        This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="4944"/>
      - <seriesInfo name="DOI" value="10.17487/RFC4944"/>
      - </reference>
    - <reference anchor="RFC4656" target="https://www.rfc-editor.org/info/rfc4656">
      - <front>
        
        <title>
        
        A One-way Active Measurement Protocol (OWAMP)
        
        </title>
        
        <author initials="S." surname="Shalunov" fullname="S. Shalunov">
        
        <organization/>
        
        </author>
        
        <author initials="B." surname="Teitelbaum" fullname="B. Teitelbaum">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Karp" fullname="A. Karp">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Boote" fullname="J. Boote">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Zekauskas" fullname="M. Zekauskas">
        
        <organization/>
        
        </author>
        
        <date year="2006" month="September"/>
        
        <abstract>
        
        <t>
        
        The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="4656"/>
      - <seriesInfo name="DOI" value="10.17487/RFC4656"/>
      - </reference>
    - <reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4821">
      - <front>
        
        <title>
        
        Packetization Layer Path MTU Discovery
        
        </title>
        
        <author initials="M." surname="Mathis" fullname="M. Mathis">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Heffner" fullname="J. Heffner">
        
        <organization/>
        
        </author>
        
        <date year="2007" month="March"/>
        
        <abstract>
        
        <t>
        
        This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="4821"/>
      - <seriesInfo name="DOI" value="10.17487/RFC4821"/>
      - </reference>
    - <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861">
      - <front>
        
        <title>
        
        Neighbor Discovery for IP version 6 (IPv6)
        
        </title>
        
        <author initials="T." surname="Narten" fullname="T. Narten">
        
        <organization/>
        
        </author>
        
        <author initials="E." surname="Nordmark" fullname="E. Nordmark">
        
        <organization/>
        
        </author>
        
        <author initials="W." surname="Simpson" fullname="W. Simpson">
        
        <organization/>
        
        </author>
        
        <author initials="H." surname="Soliman" fullname="H. Soliman">
        
        <organization/>
        
        </author>
        
        <date year="2007" month="September"/>
        
        <abstract>
        
        <t>
        
        This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="4861"/>
      - <seriesInfo name="DOI" value="10.17487/RFC4861"/>
      - </reference>
    - <reference anchor="RFC5357" target="https://www.rfc-editor.org/info/rfc5357">
      - <front>
        
        <title>
        
        A Two-Way Active Measurement Protocol (TWAMP)
        
        </title>
        
        <author initials="K." surname="Hedayat" fullname="K. Hedayat">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Krzanowski" fullname="R. Krzanowski">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Morton" fullname="A. Morton">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Yum" fullname="K. Yum">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Babiarz" fullname="J. Babiarz">
        
        <organization/>
        
        </author>
        
        <date year="2008" month="October"/>
        
        <abstract>
        
        <t>
        
        The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5357"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5357"/>
      - </reference>
    - <reference anchor="RFC5644" target="https://www.rfc-editor.org/info/rfc5644">
      - <front>
        
        <title>
        
        IP Performance Metrics (IPPM): Spatial and Multicast
        
        </title>
        
        <author initials="E." surname="Stephan" fullname="E. Stephan">
        
        <organization/>
        
        </author>
        
        <author initials="L." surname="Liang" fullname="L. Liang">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Morton" fullname="A. Morton">
        
        <organization/>
        
        </author>
        
        <date year="2009" month="October"/>
        
        <abstract>
        
        <t>
        
        The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5644"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5644"/>
      - </reference>
    - <reference anchor="RFC5835" target="https://www.rfc-editor.org/info/rfc5835">
      - <front>
        
        <title>
        
        Framework for Metric Composition
        
        </title>
        
        <author initials="A." surname="Morton" fullname="A. Morton" role="editor">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Van den Berghe" fullname="S. Van den Berghe" role="editor">
        
        <organization/>
        
        </author>
        
        <date year="2010" month="April"/>
        
        <abstract>
        
        <t>
        
        This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5835"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5835"/>
      - </reference>
    - <reference anchor="RFC6144" target="https://www.rfc-editor.org/info/rfc6144">
      - <front>
        
        <title>
        
        Framework for IPv4/IPv6 Translation
        
        </title>
        
        <author initials="F." surname="Baker" fullname="F. Baker">
        
        <organization/>
        
        </author>
        
        <author initials="X." surname="Li" fullname="X. Li">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Bao" fullname="C. Bao">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Yin" fullname="K. Yin">
        
        <organization/>
        
        </author>
        
        <date year="2011" month="April"/>
        
        <abstract>
        
        <t>
        
        This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="6144"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6144"/>
      - </reference>
    - <reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc6282">
      - <front>
        
        <title>
        
        Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
        
        </title>
        
        <author initials="J." surname="Hui" fullname="J. Hui" role="editor">
        
        <organization/>
        
        </author>
        
        <author initials="P." surname="Thubert" fullname="P. Thubert">
        
        <organization/>
        
        </author>
        
        <date year="2011" month="September"/>
        
        <abstract>
        
        <t>
        
        This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="6282"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6282"/>
      - </reference>
    - <reference anchor="RFC6398" target="https://www.rfc-editor.org/info/rfc6398">
      - <front>
        
        <title>
        
        IP Router Alert Considerations and Usage
        
        </title>
        
        <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur" role="editor">
        
        <organization/>
        
        </author>
        
        <date year="2011" month="October"/>
        
        <abstract>
        
        <t>
        
        The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="BCP" value="168"/>
      - <seriesInfo name="RFC" value="6398"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6398"/>
      - </reference>
    - <reference anchor="RFC6437" target="https://www.rfc-editor.org/info/rfc6437">
      - <front>
        
        <title>
        
        IPv6 Flow Label Specification
        
        </title>
        
        <author initials="S." surname="Amante" fullname="S. Amante">
        
        <organization/>
        
        </author>
        
        <author initials="B." surname="Carpenter" fullname="B. Carpenter">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Jiang" fullname="S. Jiang">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Rajahalme" fullname="J. Rajahalme">
        
        <organization/>
        
        </author>
        
        <date year="2011" month="November"/>
        
        <abstract>
        
        <t>
        
        This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.
        
        </t>
        
        <t>
        
        The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="6437"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6437"/>
      - </reference>
    - <reference anchor="RFC6564" target="https://www.rfc-editor.org/info/rfc6564">
      - <front>
        
        <title>
        
        A Uniform Format for IPv6 Extension Headers
        
        </title>
        
        <author initials="S." surname="Krishnan" fullname="S. Krishnan">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Woodyatt" fullname="J. Woodyatt">
        
        <organization/>
        
        </author>
        
        <author initials="E." surname="Kline" fullname="E. Kline">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Hoagland" fullname="J. Hoagland">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Bhatia" fullname="M. Bhatia">
        
        <organization/>
        
        </author>
        
        <date year="2012" month="April"/>
        
        <abstract>
        
        <t>
        
        In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="6564"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6564"/>
      - </reference>
    - <reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6775">
      - <front>
        
        <title>
        
        Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
        
        </title>
        
        <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti">
        
        <organization/>
        
        </author>
        
        <author initials="E." surname="Nordmark" fullname="E. Nordmark">
        
        <organization/>
        
        </author>
        
        <author initials="C." surname="Bormann" fullname="C. Bormann">
        
        <organization/>
        
        </author>
        
        <date year="2012" month="November"/>
        
        <abstract>
        
        <t>
        
        The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="6775"/>
      - <seriesInfo name="DOI" value="10.17487/RFC6775"/>
      - </reference>
    - <reference anchor="RFC7045" target="https://www.rfc-editor.org/info/rfc7045">
      - <front>
        
        <title>
        
        Transmission and Processing of IPv6 Extension Headers
        
        </title>
        
        <author initials="B." surname="Carpenter" fullname="B. Carpenter">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Jiang" fullname="S. Jiang">
        
        <organization/>
        
        </author>
        
        <date year="2013" month="December"/>
        
        <abstract>
        
        <t>
        
        Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7045"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7045"/>
      - </reference>
    - <?rfc ?>
    - <reference anchor="RFC7312" target="https://www.rfc-editor.org/info/rfc7312">
      - <front>
        
        <title>
        
        Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)
        
        </title>
        
        <author initials="J." surname="Fabini" fullname="J. Fabini">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Morton" fullname="A. Morton">
        
        <organization/>
        
        </author>
        
        <date year="2014" month="August"/>
        
        <abstract>
        
        <t>
        
        To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7312"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7312"/>
      - </reference>
    - <reference anchor="RFC7757" target="https://www.rfc-editor.org/info/rfc7757">
      - <front>
        
        <title>
        
        Explicit Address Mappings for Stateless IP/ICMP Translation
        
        </title>
        
        <author initials="T." surname="Anderson" fullname="T. Anderson">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Leiva Popper" fullname="A. Leiva Popper">
        
        <organization/>
        
        </author>
        
        <date year="2016" month="February"/>
        
        <abstract>
        
        <t>
        
        This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7757"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7757"/>
      - </reference>
    - <reference anchor="RFC7915" target="https://www.rfc-editor.org/info/rfc7915">
      - <front>
        
        <title>
        
        IP/ICMP Translation Algorithm
        
        </title>
        
        <author initials="C." surname="Bao" fullname="C. Bao">
        
        <organization/>
        
        </author>
        
        <author initials="X." surname="Li" fullname="X. Li">
        
        <organization/>
        
        </author>
        
        <author initials="F." surname="Baker" fullname="F. Baker">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Anderson" fullname="T. Anderson">
        
        <organization/>
        
        </author>
        
        <author initials="F." surname="Gont" fullname="F. Gont">
        
        <organization/>
        
        </author>
        
        <date year="2016" month="June"/>
        
        <abstract>
        
        <t>
        
        This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7915"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7915"/>
      - </reference>
    - <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
      - <front>
        
        <title>
        
        Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
        
        </title>
        
        <author initials="B." surname="Leiba" fullname="B. Leiba">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="May"/>
        
        <abstract>
        
        <t>
        
        RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="BCP" value="14"/>
      - <seriesInfo name="RFC" value="8174"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      - </reference>
    - <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200">
      - <front>
        
        <title>
        
        Internet Protocol, Version 6 (IPv6) Specification
        
        </title>
        
        <author initials="S." surname="Deering" fullname="S. Deering">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Hinden" fullname="R. Hinden">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="July"/>
        
        <abstract>
        
        <t>
        
        This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="STD" value="86"/>
      - <seriesInfo name="RFC" value="8200"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8200"/>
      - </reference>
    - <reference anchor="RFC8201" target="https://www.rfc-editor.org/info/rfc8201">
      - <front>
        
        <title>
        
        Path MTU Discovery for IP version 6
        
        </title>
        
        <author initials="J." surname="McCann" fullname="J. McCann">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Deering" fullname="S. Deering">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Mogul" fullname="J. Mogul">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Hinden" fullname="R. Hinden" role="editor">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="July"/>
        
        <abstract>
        
        <t>
        
        This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="STD" value="87"/>
      - <seriesInfo name="RFC" value="8201"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8201"/>
      - </reference>
    - <reference anchor="RFC8250" target="https://www.rfc-editor.org/info/rfc8250">
      - <front>
        
        <title>
        
        IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
        
        </title>
        
        <author initials="N." surname="Elkins" fullname="N. Elkins">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Hamilton" fullname="R. Hamilton">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Ackermann" fullname="M. Ackermann">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="September"/>
        
        <abstract>
        
        <t>
        
        To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="8250"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8250"/>
      - </reference>
    - </references>
  - <references title="Informative References">
    - <reference anchor="RFC7594" target="https://www.rfc-editor.org/info/rfc7594">
      - <front>
        
        <title>
        
        A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
        
        </title>
        
        <author initials="P." surname="Eardley" fullname="P. Eardley">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Morton" fullname="A. Morton">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Bagnulo" fullname="M. Bagnulo">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Burbridge" fullname="T. Burbridge">
        
        <organization/>
        
        </author>
        
        <author initials="P." surname="Aitken" fullname="P. Aitken">
        
        <organization/>
        
        </author>
        
        <author initials="A." surname="Akhter" fullname="A. Akhter">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="September"/>
        
        <abstract>
        
        <t>
        
        Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7594"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7594"/>
      - </reference>
    - <-- draft-ietf-ippm-ioam-data-03 exists -->
    - <reference anchor="I-D.ietf-ippm-ioam-data" "IOAM-DATA" >
      - <front>
        
        <title>
        
        Data Fields for In-situ OAM
        
        </title>
        
        <author initials="F" surname="Brockners" fullname="Frank Brockners">
        
        <organization/>
        
        </author>
        
        <author initials="S" surname="Bhandari" fullname="Shwetha Bhandari">
        
        <organization/>
        
        </author>
        
        <author initials="C" surname="Pignataro" fullname="Carlos Pignataro">
        
        <organization/>
        
        </author>
        
        <author initials="H" surname="Gredler" fullname="Hannes Gredler">
        
        <organization/>
        
        </author>
        
        <author initials="J" surname="Leddy" fullname="John Leddy">
        
        <organization/>
        
        </author>
        
        <author initials="S" surname="Youell" fullname="Stephen Youell">
        
        <organization/>
        
        </author>
        
        <author initials="T" surname="Mizrahi" fullname="Tal Mizrahi">
        
        <organization/>
        
        </author>
        
        <author initials="D" surname="Mozes" fullname="David Mozes">
        
        <organization/>
        
        </author>
        
        <author initials="P" surname="Lapukhov" fullname="Petr Lapukhov">
        
        <organization/>
        
        </author>
        
        <author initials="R" surname="Chang" fullname="Remy Chang">
        
        <organization/>
        
        </author>
        
        <author initials="d" surname="daniel.bernier@bell.ca" fullname="daniel.bernier@bell.ca">
        
        <organization/>
        
        </author>
        
        <author initials="J" surname="Lemon" fullname="John Lemon">
        
        <organization/>
        
        </author>
        
        <date month="June" day="27" year="2018"/>
        
        <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 discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be embedded into a variety of transports such as NSH, Segment Routing, Geneve, native IPv6 (via extension header), or IPv4. In-situ OAM can be used to complement OAM mechanisms based on e.g. ICMP or other types of probe packets.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="Internet-Draft" "Work in Progress," value="draft-ietf-ippm-ioam-data-03"/>
      - <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ippm-ioam-data-03.txt"/>
      - </reference>
    - <reference anchor="IANA-6P" quote-title="true" target="https://www.iana.org/assignments/ipv6-parameters">
      - <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>
  - <section anchor="Acknowledgements" title="Acknowledgements" numbered="no" toc="default">
    - <t>
      - The authors thank Brian Carpenter for identifying the lack of IPv6 coverage in IPPM's framework and listing additional distinguishing factors for packets of type p. Both Brian and Fred Baker discussed many of the interesting aspects of IPv6 with the coauthors, leading to a more solid first draft: thank you both. Thanks to Bill Jouris for an editorial pass through the pre-00 text. As we completed our journey, Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh Krishnan all contributed useful suggestions.
      - </t>
    - </section>
  - </back>
- </rfc>

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" number="XXXX" submissionType="IETF"
     ipr="pre5378Trust200902" updates="2330" consensus="yes">
  <front>
    <title abbrev="IPPM IPv6 Update">IPv6, IPv4 and Coexistence Updates for
    the Active Metric Framework of IP Performance Metrics (IPPM)</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>United States of America</country>
        </postal>

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

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

        <email>acmorton@att.com</email>
<!--[rfced] The following URI does not seem to work. Please update or remove.

ORIGINAL:
http://home.comcast.net/~acmacm/
--> 

        <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>United States of America</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 month="August" year="2018"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>


    <abstract>
      <t>This memo updates the IP Performance Metrics (IPPM) framework defined
      by RFC 2330 with new considerations for measurement methodology and testing. It
      updates the definition of standard-formed packets to include
      IPv6 packets, deprecates the definition of minimal IP packet, and
      augments distinguishing aspects, referred to as type p, for
      test packets in RFC 2330. This memo identifies that IPv4-IPv6
      coexistence can challenge measurements within the scope of the IPPM
      framework. Example use cases include, but are not limited to, IPv4-IPv6
      translation, NAT, and 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>

  </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 an IP packet 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 originally desired to
      do.</t>

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

<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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>

</section>

    <section title="Scope">
      <t>The purpose of this memo is to expand the coverage of IPPM metrics to
      include IPv6, 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 and expands the definition (in Section 15)
      of a standard-formed packet to include IPv6 header aspects and other
      features.</t>

      <t>Other topics in <xref target="RFC2330"/> that 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, as well as higher-layer protocol headers and
      their values. Consider an IP-connectivity metric: one obtains different
      results depending on whether one is interested in, for example, connectivity for
      packets destined for well-known TCP ports or unreserved UDP ports,
      those with invalid IPv4 checksums, or those with TTL or Hop Limit of 16. 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"/>, Explicit Congestion Notification (ECN) <xref target="RFC3168"/>, Router Alert <xref target="RFC6398"/>, 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, 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

<!--[rfced] Does the second sentence here state conditions that are always
true or give examples of what might be true in some cases? Please clarify.

ORIGINAL:
Even header fields like TTL/Hop Limit that typically change in transit may
be relevant to specific tests.  For example, Neighbor Discovery
Protocol (NDP) [RFC4861] packets are transmitted with the 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.

PERHAPS:
Even header fields like TTL/Hop Limit that typically change in transit may
be relevant to specific tests.  For example, Neighbor Discovery
Protocol (NDP) [RFC4861] packets could be transmitted with the Hop Limit
value set to 255, while 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.

--> 
      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 the 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 class C (a designation that has no relationship to address
      assignments, of course).</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 and routers often use flow identifiers, computed as
      hashes (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 (or router'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>

<!--[rfced] This bullet point seems to contain two different
requirements. Please check whether they should each have their own bullet
point or remain together.

ORIGINAL:
The Internet Header Length (IHL) value is >= 5; the checksum is
correct.
--> 
          <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, 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="RFC4944"/> and Robust Header
      Compression (ROHC) <xref target="RFC3095"/>. 6LowPAN, as defined in <xref target="RFC4944"/>
      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 an MTU smaller than the minimum IPv6 MTU. Fragmentation and
      reassembly 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 requires substantial work, as do requirements
      with respect to the concept of standard-formed packets for these two
      protocols. For these reasons, we
      consider ROHC and 6LowPAN packets to be out of the scope of 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,
      such as in-situ OAM <xref target="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 the IPv6 Destination Option
      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
          suboptimal 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. This point simply encourages measurement system designers to
          be prepared for the unexpected and notify users when such events
          occur. There are issues with Extension Header insertion and deletion,
          of course, such as exceeding the path MTU due to insertion, etc.</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 effect
      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 coexistence 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 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. Example
      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 an
          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
          interpacket 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
          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 the 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
      that 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 document has no IANA actions.</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 include='reference.RFC.3168'?>

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

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

      <?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.6398'?>

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

<!-- draft-ietf-ippm-ioam-data-03 exists -->
<reference anchor='IOAM-DATA'>
<front>
<title>Data Fields for In-situ OAM</title>

<author initials='F' surname='Brockners' fullname='Frank Brockners'>
    <organization />
</author>

<author initials='S' surname='Bhandari' fullname='Shwetha Bhandari'>
    <organization />
</author>

<author initials='C' surname='Pignataro' fullname='Carlos Pignataro'>
    <organization />
</author>

<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
    <organization />
</author>

<author initials='J' surname='Leddy' fullname='John Leddy'>
    <organization />
</author>

<author initials='S' surname='Youell' fullname='Stephen Youell'>
    <organization />
</author>

<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
    <organization />
</author>

<author initials='D' surname='Mozes' fullname='David Mozes'>
    <organization />
</author>

<author initials='P' surname='Lapukhov' fullname='Petr Lapukhov'>
    <organization />
</author>

<author initials='R' surname='Chang' fullname='Remy Chang'>
    <organization />
</author>

<author initials='d' surname='daniel.bernier@bell.ca' fullname='daniel.bernier@bell.ca'>
    <organization />
</author>

<author initials='J' surname='Lemon' fullname='John Lemon'>
    <organization />
</author>

<date month='June' day='27' year='2018' />


</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-ippm-ioam-data-03' />

</reference>


      <reference anchor="IANA-6P" target="https://www.iana.org/assignments/ipv6-parameters">
        <front>
          <title>Internet Protocol Version 6 (IPv6) Parameters</title>

          <author fullname="IANA" initials="" surname="IANA">

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

          <date />
        </front>

      </reference>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
      <t>The authors thank Brian Carpenter for identifying the lack of IPv6
      coverage in IPPM's framework and listing additional distinguishing
      factors for packets of type p. Both Brian and Fred Baker discussed many
      of the interesting aspects of IPv6 with the coauthors, leading to a
      more solid first draft: thank you both. Thanks to Bill Jouris for an
      editorial pass through the pre-00 text. As we completed our journey,
      Nevil Brownlee, Mike Heard, Spencer Dawkins, Warren Kumari, and Suresh
      Krishnan all contributed useful suggestions.</t>
    </section>

  </back>
</rfc>