doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc8250.txt b/doc/rfc/rfc8250.txt
new file mode 100644
index 0000000..5c8e4ca
--- /dev/null
+++ b/doc/rfc/rfc8250.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         N. Elkins
+Request for Comments: 8250                               Inside Products
+Category: Standards Track                                    R. Hamilton
+ISSN: 2070-1721                               Chemical Abstracts Service
+                                                            M. Ackermann
+                                                           BCBS Michigan
+                                                          September 2017
+
+
+    IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8250.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 1]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Background ......................................................3
+      1.1. Terminology ................................................3
+      1.2. Rationale for Defined Solution .............................4
+      1.3. IPv6 Transition Technologies ...............................4
+   2. Measurement Information Derived from PDM ........................5
+      2.1. Round-Trip Delay ...........................................5
+      2.2. Server Delay ...............................................5
+   3. Performance and Diagnostic Metrics Destination Option Layout ....6
+      3.1. Destination Options Header .................................6
+      3.2. Performance and Diagnostic Metrics Destination Option ......6
+           3.2.1. PDM Layout ..........................................6
+           3.2.2. Base Unit for Time Measurement ......................8
+      3.3. Header Placement ...........................................9
+      3.4. Header Placement Using IPsec ESP Mode ......................9
+           3.4.1. Using ESP Transport Mode ...........................10
+           3.4.2. Using ESP Tunnel Mode ..............................10
+      3.5. Implementation Considerations .............................10
+           3.5.1. PDM Activation .....................................10
+           3.5.2. PDM Timestamps .....................................10
+      3.6. Dynamic Configuration Options .............................11
+      3.7. Information Access and Storage ............................11
+   4. Security Considerations ........................................11
+      4.1. Resource Consumption and Resource Consumption Attacks .....11
+      4.2. Pervasive Monitoring ......................................12
+      4.3. PDM as a Covert Channel ...................................12
+      4.4. Timing Attacks ............................................13
+   5. IANA Considerations ............................................13
+   6. References .....................................................14
+      6.1. Normative References ......................................14
+      6.2. Informative References ....................................14
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 2]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   Appendix A. Context for PDM .......................................15
+     A.1. End-User Quality of Service (QoS) ..........................15
+     A.2. Need for a Packet Sequence Number (PSN) ....................15
+     A.3. Rationale for Defined Solution .............................15
+     A.4. Use PDM with Other Headers .................................16
+   Appendix B. Timing Considerations .................................16
+     B.1. Calculations of Time Differentials .........................16
+     B.2. Considerations of This Time-Differential Representation ....18
+       B.2.1. Limitations with This Encoding Method ..................18
+       B.2.2. Loss of Precision Induced by Timer Value Truncation ....19
+   Appendix C. Sample Packet Flows ...................................20
+     C.1. PDM Flow - Simple Client-Server Traffic ....................20
+       C.1.1. Step 1 .................................................20
+       C.1.2. Step 2 .................................................21
+       C.1.3. Step 3 .................................................21
+       C.1.4. Step 4 .................................................23
+       C.1.5. Step 5 .................................................24
+     C.2. Other Flows ................................................24
+       C.2.1. PDM Flow - One-Way Traffic .............................24
+       C.2.2. PDM Flow - Multiple-Send Traffic .......................25
+       C.2.3. PDM Flow - Multiple-Send Traffic with Errors ...........26
+   Appendix D. Potential Overhead Considerations .....................28
+   Acknowledgments ...................................................30
+   Authors' Addresses ................................................30
+
+1.  Background
+
+   To assess performance problems, measurements based on optional
+   sequence numbers and timing may be embedded in each packet.  Such
+   measurements may be interpreted in real time or after the fact.
+
+   As defined in RFC 8200 [RFC8200], destination options are carried by
+   the IPv6 Destination Options extension header.  Destination options
+   include optional information that need be examined only by the IPv6
+   node given as the destination address in the IPv6 header, not by
+   routers or other "middleboxes".  This document specifies the
+   Performance and Diagnostic Metrics (PDM) destination option.  The
+   field limits, calculations, and usage in measurement of the PDM
+   Destination Options header are included in this document.
+
+1.1.  Terminology
+
+   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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 3]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+1.2.  Rationale for Defined Solution
+
+   The current IPv6 specification does not provide timing, nor does it
+   provide a similar field in the IPv6 main header or in any extension
+   header.  The IPv6 PDM destination option provides such fields.
+
+   Advantages include:
+
+   1. Real measure of actual transactions.
+
+   2. Ability to span organizational boundaries with consistent
+      instrumentation.
+
+   3. No time synchronization needed between session partners.
+
+   4. Ability to handle all transport protocols (TCP, UDP, the Stream
+      Control Transmission Protocol (SCTP), etc.) in a uniform way.
+
+   PDM provides the ability to determine quickly if the (latency)
+   problem is in the network or in the server (application).  That is,
+   it is a fast way to do triage.  For more information on the
+   background and usage of PDM, see Appendix A.
+
+1.3.  IPv6 Transition Technologies
+
+   In the path to full implementation of IPv6, transition technologies
+   such as translation or tunneling may be employed.  It is possible
+   that an IPv6 packet containing PDM may be dropped if using IPv6
+   transition technologies.  For example, an implementation using a
+   translation technique (IPv6 to IPv4) that does not support or
+   recognize the IPv6 Destination Options extension header may simply
+   drop the packet rather than translating it without the extension
+   header.
+
+   It is also possible that some devices in the network may not
+   correctly handle multiple IPv6 extension headers, including the IPv6
+   Destination Option.  For example, adding the PDM header to a packet
+   may push the Layer 4 information to a point in the packet where it
+   is not visible to filtering logic, and the packet may be dropped.
+   This kind of situation is expected to become rare over time.
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 4]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+2.  Measurement Information Derived from PDM
+
+   Each packet contains information about the sender and receiver.  In
+   IP, the identifying information is called a "5-tuple".
+
+   The 5-tuple consists of:
+
+      SADDR: IP address of the sender
+      SPORT: Port for the sender
+      DADDR: IP address of the destination
+      DPORT: Port for the destination
+      PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)
+
+   PDM contains the following base fields (scale fields intentionally
+   left out):
+
+      PSNTP   : Packet Sequence Number This Packet
+      PSNLR   : Packet Sequence Number Last Received
+      DELTATLR: Delta Time Last Received
+      DELTATLS: Delta Time Last Sent
+
+   Other fields for storing time scaling factors are also in PDM and
+   will be described in Section 3.
+
+   This information, combined with the 5-tuple, allows the measurement
+   of the following metrics:
+
+   1. Round-trip delay
+
+   2. Server delay
+
+2.1.  Round-Trip Delay
+
+   Round-trip *network* delay is the delay for packet transfer from a
+   source host to a destination host and then back to the source host.
+   This measurement has been defined, and its advantages and
+   disadvantages are discussed in "A Round-trip Delay Metric for IPPM"
+   [RFC2681].
+
+2.2.  Server Delay
+
+   Server delay is the interval between when a packet is received by a
+   device and the first corresponding packet is sent back in response.
+   This may be "server processing time".  It may also be a delay caused
+   by acknowledgments.  Server processing time includes the time taken
+   by the combination of the stack and application to return the
+   response.  The stack delay may be related to network performance.  If
+   this aggregate time is seen as a problem and there is a need to make
+
+
+
+Elkins, et al.               Standards Track                    [Page 5]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   a clear distinction between application processing time and stack
+   delay, including that caused by the network, then more client-based
+   measurements are needed.
+
+3.  Performance and Diagnostic Metrics Destination Option Layout
+
+3.1.  Destination Options Header
+
+   The IPv6 Destination Options extension header [RFC8200] is used to
+   carry optional information that needs to be examined only by a
+   packet's destination node(s).  The Destination Options header is
+   identified by a Next Header value of 60 in the immediately preceding
+   header and is defined in RFC 8200 [RFC8200].  The IPv6 Performance
+   and Diagnostic Metrics (PDM) destination option is implemented as an
+   IPv6 Option carried in the Destination Options header.  PDM does not
+   require time synchronization.
+
+3.2.  Performance and Diagnostic Metrics Destination Option
+
+3.2.1.  PDM Layout
+
+   The IPv6 PDM destination option contains the following fields:
+
+      SCALEDTLR: Scale for Delta Time Last Received
+      SCALEDTLS: Scale for Delta Time Last Sent
+      PSNTP    : Packet Sequence Number This Packet
+      PSNLR    : Packet Sequence Number Last Received
+      DELTATLR : Delta Time Last Received
+      DELTATLS : Delta Time Last Sent
+
+   PDM has alignment requirements.  Following the convention in IPv6,
+   these options are aligned in a packet so that multi-octet values
+   within the Option Data field of each option fall on natural
+   boundaries (i.e., fields of width n octets are placed at an integer
+   multiple of n octets from the start of the header, for n = 1, 2, 4,
+   or 8) [RFC8200].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 6]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   The PDM destination option is encoded in type-length-value (TLV)
+   format as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Option Type  | Option Length |    ScaleDTLR  |     ScaleDTLS |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   PSN This Packet             |  PSN Last Received            |
+      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Delta Time Last Received    |  Delta Time Last Sent         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Option Type
+
+         0x0F
+
+         In keeping with RFC 8200 [RFC8200], the two high-order bits of
+         the Option Type field are encoded to indicate specific
+         processing of the option; for the PDM destination option, these
+         two bits MUST be set to 00.
+
+         The third high-order bit of the Option Type field specifies
+         whether or not the Option Data of that option can change
+         en route to the packet's final destination.
+
+         In PDM, the value of the third high-order bit MUST be 0.
+
+      Option Length
+
+         8-bit unsigned integer.  Length of the option, in octets,
+         excluding the Option Type and Option Length fields.  This field
+         MUST be set to 10.
+
+      Scale Delta Time Last Received (SCALEDTLR)
+
+         8-bit unsigned integer.  This is the scaling value for the
+         Delta Time Last Received (DELTATLR) field.  The possible values
+         are from 0 to 255.  See Appendix B for further discussion on
+         timing considerations and formatting of the scaling values.
+
+      Scale Delta Time Last Sent (SCALEDTLS)
+
+         8-bit signed integer.  This is the scaling value for the Delta
+         Time Last Sent (DELTATLS) field.  The possible values are from
+         0 to 255.
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 7]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+      Packet Sequence Number This Packet (PSNTP)
+
+         16-bit unsigned integer.  This field will wrap.  It is intended
+         for use while analyzing packet traces.
+
+         This field is initialized at a random number and incremented
+         monotonically for each packet of the session flow of the
+         5-tuple.  The random-number initialization is intended to make
+         it harder to spoof and insert such packets.
+
+         Operating systems MUST implement a separate packet sequence
+         number counter per 5-tuple.
+
+      Packet Sequence Number Last Received (PSNLR)
+
+         16-bit unsigned integer.  This is the PSNTP of the packet last
+         received on the 5-tuple.
+
+         This field is initialized to 0.
+
+      Delta Time Last Received (DELTATLR)
+
+         16-bit unsigned integer.  The value is set according to the
+         scale in SCALEDTLR.
+
+         Delta Time Last Received =
+            (send time packet n - receive time packet (n - 1))
+
+      Delta Time Last Sent (DELTATLS)
+
+         16-bit unsigned integer.  The value is set according to the
+         scale in SCALEDTLS.
+
+         Delta Time Last Sent =
+            (receive time packet n - send time packet (n - 1))
+
+3.2.2.  Base Unit for Time Measurement
+
+   A time differential is always a whole number in a CPU; it is the unit
+   specification -- hours, seconds, nanoseconds -- that determines what
+   the numeric value means.  For PDM, the base time unit is 1 attosecond
+   (asec).  This allows for a common unit and scaling of the time
+   differential among all IP stacks and hardware implementations.
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 8]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   Note that PDM provides the ability to measure both time differentials
+   that are extremely small and time differentials in a Delay/Disruption
+   Tolerant Networking (DTN) environment where the delays may be very
+   great.  To store a time differential in just 16 bits that must range
+   in this way will require some scaling of the time-differential value.
+
+   One issue is the conversion from the native time base in the CPU
+   hardware of whatever device is in use to some number of attoseconds.
+   It might seem that this will be an astronomical number, but the
+   conversion is straightforward.  It involves multiplication by an
+   appropriate power of 10 to change the value into a number of
+   attoseconds.  Then, to scale the value so that it fits into DELTATLR
+   or DELTATLS, the value is shifted by a number of bits, retaining the
+   16 high-order or most significant bits.  The number of bits shifted
+   becomes the scaling factor, stored as SCALEDTLR or SCALEDTLS,
+   respectively.  For additional information on this process, see
+   Appendix B.
+
+3.3.  Header Placement
+
+   The PDM destination option is placed as defined in RFC 8200
+   [RFC8200].  There may be a choice of where to place the Destination
+   Options header.  If using Encapsulating Security Payload (ESP) mode,
+   please see Section 3.4 of this document regarding the placement of
+   the PDM Destination Options header.
+
+   For each IPv6 packet header, PDM MUST NOT appear more than once.
+   However, an encapsulated packet MAY contain a separate PDM associated
+   with each encapsulated IPv6 header.
+
+3.4.  Header Placement Using IPsec ESP Mode
+
+   IPsec ESP is defined in [RFC4303] and is widely used.  Section 3.1.1
+   of [RFC4303] discusses the placement of Destination Options headers.
+
+   The placement of PDM is different, depending on whether ESP is used
+   in tunnel mode or transport mode.
+
+   In the ESP case, no 5-tuple is available, as there are no port
+   numbers.  ESP flow should be identified only by using SADDR, DADDR,
+   and PROTC.  The Security Parameter Index (SPI) numbers SHOULD be
+   ignored when considering the flow over which PDM information is
+   measured.
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                    [Page 9]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+3.4.1.  Using ESP Transport Mode
+
+   Note that destination options may be placed before or after ESP, or
+   both.  If using PDM in ESP transport mode, PDM MUST be placed after
+   the ESP header so as not to leak information.
+
+3.4.2.  Using ESP Tunnel Mode
+
+   Note that in both the outer set of IP headers and the inner set of IP
+   headers, destination options may be placed before or after ESP, or
+   both.  A tunnel endpoint that creates a new packet may decide to use
+   PDM independently of the use of PDM of the original packet to enable
+   delay measurements between the two tunnel endpoints.
+
+3.5.  Implementation Considerations
+
+3.5.1.  PDM Activation
+
+   An implementation should provide an interface to enable or disable
+   the use of PDM.  This specification recommends having PDM off by
+   default.
+
+   PDM MUST NOT be turned on merely if a packet is received with a PDM
+   header.  The received packet could be spoofed by another device.
+
+3.5.2.  PDM Timestamps
+
+   The PDM timestamps are intended to isolate wire time from server or
+   host time but may necessarily attribute some host processing time to
+   network latency.
+
+   Section 10.2 of RFC 2330 [RFC2330] ("Framework for IP Performance
+   Metrics") describes two notions of "wire time".  These notions are
+   only defined in terms of an Internet host H observing an Internet
+   link L at a particular location:
+
+   +  For a given IP packet P, the "wire arrival time" of P at H on L is
+      the first time T at which any bit of P has appeared at H's
+      observational position on L.
+
+   +  For a given IP packet P, the "wire exit time" of P at H on L is
+      the first time T at which all the bits of P have appeared at H's
+      observational position on L.
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 10]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   This specification does not define H's exact observational position
+   on L.  That is left for the deployment setups to define.  However,
+   the position where PDM timestamps are taken SHOULD be as close to the
+   physical network interface as possible.  Not all implementations will
+   be able to achieve the ideal level of measurement.
+
+3.6.  Dynamic Configuration Options
+
+   If the PDM Destination Options header is used, then it MAY be turned
+   on for all packets flowing through the host, applied to an upper-
+   layer protocol (TCP, UDP, SCTP, etc.), a local port, or IP address
+   only.  These are at the discretion of the implementation.
+
+3.7.  Information Access and Storage
+
+   Measurement information provided by PDM may be made accessible for
+   higher layers or the user itself.  Similar to activating the use of
+   PDM, the implementation may also provide an interface to indicate if
+   received.
+
+   PDM information may be stored, if desired.  If a packet with PDM
+   information is received and the information should be stored, the
+   upper layers may be notified.  Furthermore, the implementation should
+   define a configurable maximum lifetime after which the information
+   can be removed as well as a configurable maximum amount of memory
+   that should be allocated for PDM information.
+
+4.  Security Considerations
+
+   PDM may introduce some new security weaknesses.
+
+4.1.  Resource Consumption and Resource Consumption Attacks
+
+   PDM needs to calculate the deltas for time and keep track of the
+   sequence numbers.  This means that control blocks that reside in
+   memory may be kept at the end hosts per 5-tuple.
+
+   A limit on how much memory is being used SHOULD be implemented.
+
+   Without a memory limit, any time that a control block is kept in
+   memory, an attacker can try to misuse the control blocks to cause
+   excessive resource consumption.  This could be used to compromise the
+   end host.
+
+   PDM is used only at the end hosts, and memory is used only at the end
+   host and not at routers or middleboxes.
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 11]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+4.2.  Pervasive Monitoring
+
+   Since PDM passes in the clear, a concern arises as to whether the
+   data can be used to fingerprint the system or somehow obtain
+   information about the contents of the payload.
+
+   Let us discuss fingerprinting of the end host first.  It is possible
+   that seeing the pattern of deltas or the absolute values could give
+   some information as to the speed of the end host -- that is, if it is
+   a very fast system or an older, slow device.  This may be useful to
+   the attacker.  However, if the attacker has access to PDM, the
+   attacker also has access to the entire packet and could make such a
+   deduction based merely on the time frames elapsed between packets
+   WITHOUT PDM.
+
+   As far as deducing the content of the payload, in terms of the
+   application-level information such as web page, user name, user
+   password, and so on, it appears to us that PDM is quite unhelpful in
+   this regard.  Having said that, the ability to separate wire time
+   from processing time may potentially provide an attacker with
+   additional information.  It is conceivable that an attacker could
+   attempt to deduce the type of application in use by noting the server
+   time and payload length.  Some encryption algorithms attempt to
+   obfuscate the packet length to avoid just such vulnerabilities.  In
+   the future, encryption algorithms may wish to obfuscate the server
+   time as well.
+
+4.3.  PDM as a Covert Channel
+
+   PDM provides a set of fields in the packet that could be used to leak
+   data.  But there is no real reason to suspect that PDM would be
+   chosen rather than another part of the payload or another extension
+   header.
+
+   A firewall or another device could sanity-check the fields within
+   PDM, but randomly assigned sequence numbers and delta times might be
+   expected to vary widely.  The biggest problem, though, is how an
+   attacker would get access to PDM in the first place to leak data.
+   The attacker would have to either compromise the end host or have a
+   Man in the Middle (MitM).  It is possible that either one could
+   change the fields, but the other end host would then get sequence
+   numbers and deltas that don't make any sense.
+
+   It is conceivable that someone could compromise an end host and make
+   it start sending packets with PDM without the knowledge of the host.
+   But, again, the bigger problem is the compromise of the end host.
+   Once that is done, the attacker probably has better ways to
+   leak data.
+
+
+
+Elkins, et al.               Standards Track                   [Page 12]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   Having said that, if a PDM-aware middlebox or an implementation
+   (destination host) detects some number of "nonsensical" sequence
+   numbers or timing information, it could take action to block this
+   traffic, discard it, or send an alert.
+
+4.4.  Timing Attacks
+
+   The fact that PDM can help in the separation of node processing time
+   from network latency brings value to performance monitoring.  Yet, it
+   is this very characteristic of PDM that may be misused to make
+   certain new types of timing attacks against protocols and
+   implementations possible.
+
+   Depending on the nature of the cryptographic protocol used, it may be
+   possible to leak the credentials of the device.  For example, if an
+   attacker can see that PDM is being used, then the attacker might use
+   PDM to launch a timing attack against the keying material used by the
+   cryptographic protocol.
+
+   An implementation may want to be sure that PDM is enabled only for
+   certain IP addresses or only for some ports.  Additionally, the
+   implementation SHOULD require an explicit restart of monitoring after
+   a certain time period (for example, after 1 hour) to make sure that
+   PDM is not accidentally left on (for example, after debugging has
+   been done).
+
+   Even so, if using PDM, a user "Consent to be Measured" SHOULD be a
+   prerequisite for using PDM.  Consent is common in enterprises and
+   with some subscription services.  The actual content of "Consent to
+   be Measured" will differ by site, but it SHOULD make clear that the
+   traffic is being measured for Quality of Service (QoS) and to assist
+   in diagnostics, as well as to make clear that there may be potential
+   risks of certain vulnerabilities if the traffic is captured during a
+   diagnostic session.
+
+5.  IANA Considerations
+
+   IANA has registered a Destination Option Type assignment with the act
+   bits set to 00 and the chg bit set to 0 from the "Destination Options
+   and Hop-by-Hop Options" sub-registry of the "Internet Protocol
+   Version 6 (IPv6) Parameters" registry [RFC2780] at
+   <https://www.iana.org/assignments/ipv6-parameters/>.
+
+   Hex Value     Binary Value      Description                 Reference
+                 act  chg  rest
+   ---------------------------------------------------------------------
+   0x0F          00   0    01111   Performance and             RFC 8250
+                                   Diagnostic Metrics (PDM)
+
+
+
+Elkins, et al.               Standards Track                   [Page 13]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122,
+              DOI 10.17487/RFC1122, October 1989,
+              <https://www.rfc-editor.org/info/rfc1122>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
+              Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
+              September 1999, <https://www.rfc-editor.org/info/rfc2681>.
+
+   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+              Values In the Internet Protocol and Related Headers",
+              BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
+              <https://www.rfc-editor.org/info/rfc2780>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <https://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+              RFC 2119 Key Words", BCP 14, RFC 8174,
+              DOI 10.17487/RFC8174, May 2017,
+              <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+6.2.  Informative References
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              DOI 10.17487/RFC2330, May 1998,
+              <https://www.rfc-editor.org/info/rfc2330>.
+
+   [TCPM]     Scheffenegger, R., Kuehlewind, M., and B. Trammell,
+              "Encoding of Time Intervals for the TCP Timestamp Option",
+              Work in Progress, draft-trammell-tcpm-timestamp-
+              interval-01, July 2013.
+
+
+
+Elkins, et al.               Standards Track                   [Page 14]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+Appendix A.  Context for PDM
+
+A.1.  End-User Quality of Service (QoS)
+
+   The timing values in PDM embedded in the packet will be used to
+   estimate QoS as experienced by an end-user device.
+
+   For many applications, the key user performance indicator is response
+   time.  When the end user is an individual, he is generally
+   indifferent to what is happening along the network; what he really
+   cares about is how long it takes to get a response back.  But this is
+   not just a matter of individuals' personal convenience.  In many
+   cases, rapid response is critical to the business being conducted.
+
+   Low, reliable, and acceptable response times are not just "nice to
+   have".  On many networks, the impact can be financial hardship or can
+   endanger human life.  In some cities, the emergency police contact
+   system operates over IP; all levels of law enforcement use IP
+   networks; transactions on our stock exchanges are settled using IP
+   networks.  The critical nature of such activities to our daily lives
+   and financial well-being demands a simple solution to support
+   response-time measurements.
+
+A.2.  Need for a Packet Sequence Number (PSN)
+
+   While performing network diagnostics on an end-to-end connection, it
+   often becomes necessary to isolate the factors along the network path
+   responsible for problems.  Diagnostic data may be collected at
+   multiple places along the path (if possible), or at the source and
+   destination.  Then, in post-collection processing, the diagnostic
+   data corresponding to each packet at different observation points
+   must be matched for proper measurements.  A sequence number in each
+   packet provides a sufficient basis for the matching process.  If
+   need be, the timing fields may be used along with the sequence number
+   to ensure uniqueness.
+
+   This method of data collection along the path is of special use for
+   determining where packet loss or packet corruption is happening.
+
+   The packet sequence number needs to be unique in the context of the
+   session (5-tuple).
+
+A.3.  Rationale for Defined Solution
+
+   One of the important functions of PDM is to allow you to quickly
+   dispatch the right set of diagnosticians.  Within network or server
+   latency, there may be many components.  The job of the diagnostician
+   is to rule each one out until the culprit is found.
+
+
+
+Elkins, et al.               Standards Track                   [Page 15]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   PDM will fit into this diagnostic picture by quickly telling you how
+   to escalate.  PDM will point to either the network area or the server
+   area.  Within the server latency, PDM does not tell you whether the
+   bottleneck is in the IP stack, the application, or buffer allocation.
+   Within the network latency, PDM does not tell you which of the
+   network segments or middleboxes is at fault.
+
+   What PDM does tell you is whether the problem is in the network or
+   the server.
+
+A.4.  Use PDM with Other Headers
+
+   For diagnostics, one may want to use PDM with other headers (Layer 2,
+   Layer 3, etc).  For example, if PDM is used by a technician (or tool)
+   looking at a packet capture, within the packet capture, they would
+   have available to them the Layer 2 header, IP header (v6 or v4), TCP
+   header, UDP header, ICMP header, SCTP header, or other headers.  All
+   information would be looked at together to make sense of the packet
+   flow.  The technician or processing tool could analyze, report, or
+   ignore the data from PDM, as necessary.
+
+   For an example of how PDM can help with TCP retransmission problems,
+   please look at Appendix C.
+
+Appendix B.  Timing Considerations
+
+B.1.  Calculations of Time Differentials
+
+   When SCALEDTLR or SCALEDTLS is used, it means that the description of
+   the processing applies equally to SCALEDTLR and SCALEDTLS.
+
+   The time counter in a CPU is a binary whole number representing a
+   number of milliseconds (msec), microseconds (usec), or even
+   picoseconds (psec).  Representing one of these values as attoseconds
+   (asec) means multiplying by 10 raised to some exponent.  Refer to
+   this table of equalities:
+
+      Base value        = # of sec      = # of asec     1000s of asec
+      ---------------   -------------   -------------   -------------
+      1 second          1 sec           10**18 asec     1000**6 asec
+      1 millisecond     10**-3  sec     10**15 asec     1000**5 asec
+      1 microsecond     10**-6  sec     10**12 asec     1000**4 asec
+      1 nanosecond      10**-9  sec     10**9  asec     1000**3 asec
+      1 picosecond      10**-12 sec     10**6  asec     1000**2 asec
+      1 femtosecond     10**-15 sec     10**3  asec     1000**1 asec
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 16]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   For example, if you have a time differential expressed in
+   microseconds, since each microsecond is 10**12 asec, you would
+   multiply your time value by 10**12 to obtain the number of
+   attoseconds.  If your time differential is expressed in nanoseconds,
+   you would multiply by 10**9 to get the number of attoseconds.
+
+   The result is a binary value that will need to be shortened by a
+   number of bits so it will fit into the 16-bit PDM delta field.
+
+   The next step is to divide by 2 until the value is contained in just
+   16 significant bits.  The exponent of the value in the last column of
+   the table is useful here; the initial scaling factor is that exponent
+   multiplied by 10.  This is the minimum number of low-order bits to be
+   shifted out or discarded.  It represents dividing the time value by
+   1024 raised to that exponent.
+
+   The resulting value may still be too large to fit into 16 bits but
+   can be normalized by shifting out more bits (dividing by 2) until the
+   value fits into the 16-bit delta field.  The number of extra bits
+   shifted out is then added to the scaling factor.  The scaling factor
+   -- the total number of low-order bits dropped -- is the SCALEDTLR or
+   SCALEDTLS value.
+
+   For example, say an application has these start and finish timer
+   values (hexadecimal values, in microseconds):
+
+      Finish:      27C849234 usec    (02:57:58.997556)
+      -Start:      27C83F696 usec    (02:57:58.957718)
+      ==========   ==============    ==========================
+      Difference   9B9E usec         0.039838 sec or 39838 usec
+
+   To convert this differential value to binary attoseconds, multiply
+   the number of microseconds by 10**12.  Divide by 1024**4, or simply
+   discard 40 bits from the right.  The result is 36232, or 8D88 in hex,
+   with a scaling factor or SCALEDTLR/SCALEDTLS value of 40.
+
+   For another example, presume the time differential is larger, say
+   32.311072 seconds, which is 32311072 usec.  Each microsecond is
+   10**12 asec, so multiply by 10**12, giving the hexadecimal value
+   1C067FCCAE8120000.  Using the initial scaling factor of 40, drop the
+   last 10 characters (40 bits) from that string, giving 1C067FC.  This
+   will not fit into a delta field, as it is 25 bits long.  Shifting the
+   value to the right another 9 bits results in a delta value of E033,
+   with a resulting scaling factor of 49.
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 17]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   When the time-differential value is a small number, regardless of the
+   time unit, the exponent trick given above is not useful in
+   determining the proper scaling value.  For example, if the time
+   differential is 3 seconds and you want to convert that directly, you
+   would follow this path:
+
+     3 seconds = 3*10**18 asec (decimal)
+               = 29A2241AF62C0000 asec (hexadecimal)
+
+   If you just truncate the last 60 bits, you end up with a delta value
+   of 2 and a scaling factor of 60, when what you really wanted was a
+   delta value with more significant digits.  The most precision with
+   which you can store this value in 16 bits is A688, with a scaling
+   factor of 46.
+
+B.2.  Considerations of This Time-Differential Representation
+
+   There are two considerations to be taken into account with this
+   representation of a time differential.  The first is whether there
+   are any limitations on the maximum or minimum time differential that
+   can be expressed using the method of a delta value and a scaling
+   factor.  The second is the amount of imprecision introduced by this
+   method.
+
+B.2.1.  Limitations with This Encoding Method
+
+   The DELTATLS and DELTATLR fields store only the 16 most significant
+   bits of the time-differential value.  Thus, the range, excluding the
+   scaling factor, is from 0 to 65535, or a maximum of 2**16 - 1.  This
+   method is further described in [TCPM].
+
+   The actual magnitude of the time differential is determined by the
+   scaling factor.  SCALEDTLR and SCALEDTLS are 8-bit unsigned integers,
+   so the scaling factor ranges from 0 to 255.  The smallest number that
+   can be represented would have a value of 1 in the delta field and a
+   value of 0 in the associated scale field.  This is the representation
+   for 1 attosecond.  Clearly, this allows PDM to measure extremely
+   small time differentials.
+
+   On the other end of the scale, the maximum delta value is 65535, or
+   FFFF in hexadecimal.  If the maximum scale value of 255 is used, the
+   time differential represented is 65535*2**255, which is over
+   3*10**55 years -- essentially, forever.  So, there appears to be no
+   real limitation to the time differential that can be represented.
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 18]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+B.2.2.  Loss of Precision Induced by Timer Value Truncation
+
+   As PDM specifies the DELTATLR and DELTATLS values as 16-bit unsigned
+   integers, any time that the precision is greater than those 16 bits,
+   there will be truncation of the trailing bits, with an accompanying
+   loss of precision in the value.
+
+   Any time-differential value smaller than 65536 asec can be stored
+   exactly in DELTATLR or DELTATLS, because the representation of this
+   value requires at most 16 bits.
+
+   Since the time-differential values in PDM are measured in
+   attoseconds, the range of values that would be truncated to the same
+   encoded value is 2**((Scale) - 1) asec.
+
+   For example, the smallest time differential that would be truncated
+   to fit into a delta field is
+
+      1 0000 0000 0000 0000 = 65536 asec
+
+   This value would be encoded as a delta value of 8000 (hexadecimal)
+   with a scaling factor of 1.  The value
+
+      1 0000 0000 0000 0001 = 65537 asec
+
+   would also be encoded as a delta value of 8000 with a scaling factor
+   of 1.  This actually is the largest value that would be truncated to
+   that same encoded value.  When the scale value is 1, the value range
+   is calculated as 2**1 - 1, or 1 asec, which you can see is the
+   difference between these minimum and maximum values.
+
+   The scaling factor is defined as the number of low-order bits
+   truncated to reduce the size of the resulting value so it fits into a
+   16-bit delta field.  If, for example, you had to truncate 12 bits,
+   the loss of precision would depend on the bits you truncated.  The
+   range of these values would be
+
+      0000 0000 0000 = 0 asec
+
+         to
+
+      1111 1111 1111 = 4095 asec
+
+   So, the minimum loss of precision would be 0 asec, where the delta
+   value exactly represents the time differential, and the maximum loss
+   of precision would be 4095 asec.  As stated above, the scaling factor
+   of 12 means that the maximum loss of precision is 2**12 - 1 asec, or
+   4095 asec.
+
+
+
+Elkins, et al.               Standards Track                   [Page 19]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   Compare this loss of precision to the actual time differential.  The
+   range of actual time-differential values that would incur this loss
+   of precision is from
+
+   1000 0000 0000 0000 0000 0000 0000 = 2**27 asec or 134217728 asec
+
+      to
+
+   1111 1111 1111 1111 1111 1111 1111 = 2**28 - 1 asec or 268435455 asec
+
+   Granted, these are small values, but the point is that any value
+   between these two values will have a maximum loss of precision of
+   4095 asec, or about 0.00305% for the first value, as encoded, and at
+   most 0.001526% for the second.  These maximum-loss percentages are
+   consistent for all scaling values.
+
+Appendix C.  Sample Packet Flows
+
+C.1.  PDM Flow - Simple Client-Server Traffic
+
+   Below is a sample simple flow for PDM with one packet sent from
+   Host A and one packet received by Host B.  PDM does not require time
+   synchronization between Host A and Host B.  The calculations to
+   derive meaningful metrics for network diagnostics are shown below
+   each packet sent or received.
+
+C.1.1.  Step 1
+
+   Packet 1 is sent from Host A to Host B.  The time for Host A is set
+   initially to 10:00AM.
+
+   The time and packet sequence number are saved by the sender
+   internally.  The packet sequence number and delta times are sent in
+   the packet.
+
+      Packet 1
+
+                 +----------+             +----------+
+                 |          |             |          |
+                 |   Host   | ----------> |   Host   |
+                 |    A     |             |    B     |
+                 |          |             |          |
+                 +----------+             +----------+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 20]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+      PDM Contents:
+
+      PSNTP    : Packet Sequence Number This Packet:     25
+      PSNLR    : Packet Sequence Number Last Received:   -
+      DELTATLR : Delta Time Last Received:               -
+      SCALEDTLR: Scale of Delta Time Last Received:      0
+      DELTATLS : Delta Time Last Sent:                   -
+      SCALEDTLS: Scale of Delta Time Last Sent:          0
+
+      Internally, within the sender, Host A, it must keep:
+
+      Packet Sequence Number of the last packet sent:     25
+      Time the last packet was sent:                10:00:00
+
+   Note: The initial PSNTP from Host A starts at a random number -- in
+   this case, 25.  The time in these examples is shown in seconds for
+   the sake of simplicity.
+
+C.1.2.  Step 2
+
+   Packet 1 is received at Host B.  Its time is set to 1 hour later than
+   Host A -- in this case, 11:00AM.
+
+   Internally, within the receiver, Host B, it must note the following:
+
+      Packet Sequence Number of the last packet received:    25
+      Time the last packet was received                 :    11:00:03
+
+   Note: This timestamp is in Host B time.  It has nothing whatsoever to
+   do with Host A time.  The packet sequence number of the last packet
+   received will become PSNLR, which will be sent out in the packet sent
+   by Host B in the next step.  The timestamp of the packet last
+   received (as noted above) will be used as input to calculate the
+   DELTATLR value to be sent out in the packet sent by Host B in the
+   next step.
+
+C.1.3.  Step 3
+
+   Packet 2 is sent by Host B to Host A.  Note that the initial packet
+   sequence number (PSNTP) from Host B starts at a random number -- in
+   this case, 12.  Before sending the packet, Host B does a calculation
+   of deltas.  Since Host B knows when it is sending the packet and it
+   knows when it received the previous packet, it can do the following
+   calculation:
+
+      DELTATLR = send time (packet 2) - receive time (packet 1)
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 21]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   Note: Both the send time and the receive time are saved internally in
+   Host B.  They do not travel in the packet.  Only the change in values
+   (delta) is in the packet.  This is the DELTATLR value.
+
+   Assume that within Host B we have the following:
+
+      Packet Sequence Number of the last packet received:     25
+      Time the last packet was received:                      11:00:03
+      Packet Sequence Number of this packet:                  12
+      Time this packet is being sent:                         11:00:07
+
+   A delta value to be sent out in the packet can now be calculated.
+   DELTATLR becomes:
+
+      4 seconds = 11:00:07 - 11:00:03 = 3782DACE9D900000 asec
+
+   This is the derived metric: server delay.  The time scaling factors
+   must be converted; in this case, the time differential is DE0B, and
+   the scaling factor is 2E, or 46 in decimal.  Then, these values,
+   along with the packet sequence numbers, will be sent to Host A as
+   follows:
+
+      Packet 2
+
+                 +----------+             +----------+
+                 |          |             |          |
+                 |   Host   | <---------- |   Host   |
+                 |    A     |             |    B     |
+                 |          |             |          |
+                 +----------+             +----------+
+
+      PDM Contents:
+
+      PSNTP    : Packet Sequence Number This Packet:    12
+      PSNLR    : Packet Sequence Number Last Received:  25
+      DELTATLR : Delta Time Last Received:              DE0B (4 seconds)
+      SCALEDTLR: Scale of Delta Time Last Received:     2E (46 decimal)
+      DELTATLS : Delta Time Last Sent:                   -
+      SCALEDTLS: Scale of Delta Time Last Sent:          0
+
+   The metric left to be calculated is the round-trip delay.  This will
+   be calculated by Host A when it receives packet 2.
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 22]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+C.1.4.  Step 4
+
+   Packet 2 is received at Host A.  Remember that its time is set to
+   1 hour earlier than Host B.  Internally, it must note the following:
+
+      Packet Sequence Number of the last packet received: 12
+      Time the last packet was received                 : 10:00:12
+
+   Note: This timestamp is in Host A time.  It has nothing whatsoever to
+   do with Host B time.
+
+   So, Host A can now calculate total end-to-end time.  That is:
+
+      End-to-End Time = Time Last Received - Time Last Sent
+
+   For example, packet 25 was sent by Host A at 10:00:00.  Packet 12 was
+   received by Host A at 10:00:12, so:
+
+      End-to-End time = 10:00:12 - 10:00:00 or 12 (server and network
+      round-trip delay combined).
+
+      This time may also be called "total overall Round-Trip Time
+      (RTT)", which includes network RTT and host response time.
+
+   We will call this derived metric "Delta Time Last Sent" (DELTATLS).
+
+   Round-trip delay can now be calculated.  The formula is:
+
+      Round-trip delay =
+         (Delta Time Last Sent - Delta Time Last Received)
+
+   Or:
+
+      Round-trip delay = 12 - 4 or 8
+
+   At this point, the only problem is that all metrics are in Host A
+   only and not exposed in a packet.  To do that, we need a third
+   packet.
+
+   Note: This simple example assumes one send and one receive.  That is
+   done only for purposes of explaining the function of PDM.  In cases
+   where there are multiple packets returned, one would take the time in
+   the last packet in the sequence.  The calculations of such timings
+   and intelligent processing are the function of post-processing of
+   the data.
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 23]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+C.1.5.  Step 5
+
+   Packet 3 is sent from Host A to Host B.
+
+                 +----------+             +----------+
+                 |          |             |          |
+                 |   Host   | ----------> |   Host   |
+                 |    A     |             |    B     |
+                 |          |             |          |
+                 +----------+             +----------+
+
+      PDM Contents:
+
+      PSNTP    : Packet Sequence Number This Packet:   26
+      PSNLR    : Packet Sequence Number Last Received: 12
+      DELTATLR : Delta Time Last Received:              0
+      SCALEDTLS: Scale of Delta Time Last Received      0
+      DELTATLS : Delta Time Last Sent:               A688 (scaled value)
+      SCALEDTLR: Scale of Delta Time Last Received:    30 (48 decimal)
+
+   To calculate two-way delay, any packet-capture device may look at
+   these packets and do what is necessary.
+
+C.2.  Other Flows
+
+   What has been discussed so far is a simple flow with one packet sent
+   and one returned.  Let's look at how PDM may be useful in other types
+   of flows.
+
+C.2.1.  PDM Flow - One-Way Traffic
+
+   The flow on a particular session may not be a send-receive paradigm.
+   Let us consider some other situations.  In the case of a one-way
+   flow, one might see the following.
+
+   Note: The time is expressed in generic units for simplicity.  That
+   is, these values do not represent a number of attoseconds,
+   microseconds, or any other real units of time.
+
+   Packet   Sender      PSN            PSN        Delta Time  Delta Time
+                     This Packet    Last Recvd    Last Recvd  Last Sent
+   =====================================================================
+   1        Server       1              0              0            0
+   2        Server       2              0              0            5
+   3        Server       3              0              0           12
+   4        Server       4              0              0           20
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 24]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   What does this mean, and how is it useful?
+
+   In a one-way flow, only the Delta Time Last Sent will be seen as
+   used.  Recall that Delta Time Last Sent is the difference between the
+   send of one packet from a device and the next.  This is a measure of
+   throughput for the sender -- according to the sender's point of view.
+   That is, it is a measure of how fast the application itself (with
+   stack time included) is able to send packets.
+
+   How might this be useful?  If one is having a performance issue at
+   the client and sees that packet 2, for example, is sent after 5 time
+   units from the server but takes 10 times that long to arrive at the
+   destination, then one may safely conclude that there are delays in
+   the path, other than at the server, that may be causing the delivery
+   issue for that packet.  Such delays may include the network links,
+   middleboxes, etc.
+
+   True one-way traffic is quite rare.  What people often mean by
+   "one-way" traffic is an application such as FTP where a group of
+   packets (for example, a TCP window size worth) is sent and the sender
+   then waits for acknowledgment.  This type of flow would actually fall
+   into the "multiple-send" traffic model.
+
+C.2.2.  PDM Flow - Multiple-Send Traffic
+
+   Assume that two packets are sent from the server and then an ACK is
+   sent from the client.  For example, a TCP flow will do this, per
+   RFC 1122 [RFC1122], Section 4.2.3.  Packets 1 and 2 are sent from the
+   server, and then an ACK is sent from the client.  Packet 4 starts a
+   second sequence from the server.
+
+   Packet   Sender      PSN            PSN       Delta Time  Delta Time
+                    This Packet    Last Recvd    Last Recvd  Last Sent
+   =====================================================================
+   1        Server       1              0              0           0
+   2        Server       2              0              0           5
+   3        Client       1              2             20           0
+   4        Server       3              1             10          15
+
+   How might this be used?
+
+   Notice that in packet 3, the client has a Delta Time Last Received
+   value of 20.  Recall that:
+
+      DELTATLR = send time (packet 3) - receive time (packet 2)
+
+   So, what does one know now?  In this case, Delta Time Last Received
+   is the processing time for the client to send the next packet.
+
+
+
+Elkins, et al.               Standards Track                   [Page 25]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   How to interpret this depends on what is actually being sent.
+   Remember that PDM is not being used in isolation; rather, it is used
+   to supplement the fields found in other headers.  Let's take two
+   examples:
+
+   1. The client is sending a standalone TCP ACK.  One would find this
+      by looking at the payload length in the IPv6 header and the TCP
+      Acknowledgment field in the TCP header.  So, in this case, the
+      client is taking 20 time units to send back the ACK.  This may or
+      may not be interesting.
+
+   2. The client is sending data with the packet.  Again, one would find
+      this by looking at the payload length in the IPv6 header and the
+      TCP Acknowledgment field in the TCP header.  So, in this case, the
+      client is taking 20 time units to send back data.  This may
+      represent "User Think Time".  Again, this may or may not be
+      interesting in isolation.  But if there is a performance problem
+      receiving data at the server, then, taken in conjunction with RTT
+      or other packet timing information, this information may be quite
+      interesting.
+
+   Of course, one also needs to look at the PSN Last Received field to
+   make sure of the interpretation of this data -- that is, to make sure
+   that the Delta Time Last Received corresponds to the packet of
+   interest.
+
+   The benefits of PDM are that such information is now available in a
+   uniform manner for all applications and all protocols without
+   extensive changes required to applications.
+
+C.2.3.  PDM Flow - Multiple-Send Traffic with Errors
+
+   Let us now look at a case of how PDM may be able to help in a case of
+   TCP retransmission and add to the information that is sent in the TCP
+   header.
+
+   Assume that three packets are sent with each send from the server.
+
+   From the server, this is what is seen:
+
+   Pkt Sender    PSN        PSN      Delta Time  Delta Time  TCP   Data
+               This Pkt  Last Recvd  Last Recvd  Last Sent   SEQ   Bytes
+   =====================================================================
+   1   Server      1        0           0           0        123   100
+   2   Server      2        0           0           5        223   100
+   3   Server      3        0           0           5        333   100
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 26]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   The client, however, does not receive all the packets.  From the
+   client, this is what is seen for the packets sent from the server:
+
+   Pkt Sender    PSN        PSN      Delta Time  Delta Time  TCP   Data
+               This Pkt  Last Recvd  Last Recvd  Last Sent   SEQ   Bytes
+   =====================================================================
+   1   Server     1         0           0           0        123   100
+   2   Server     3         0           0           5        333   100
+
+   Let's assume that the server now retransmits the packet.  (Obviously,
+   a duplicate acknowledgment sequence for fast retransmit or a
+   retransmit timeout would occur.  To illustrate the point, these
+   packets are being left out.)
+
+   So, if a TCP retransmission is done, then from the client, this is
+   what is seen for the packets sent from the server:
+
+   Pkt Sender    PSN        PSN      Delta Time  Delta Time  TCP   Data
+              This Pkt   Last Recvd  Last Recvd  Last Sent   SEQ   Bytes
+   =====================================================================
+   1   Server    4          0           0           30       223   100
+
+   The server has resent the old packet 2 with a TCP sequence number
+   of 223.  The retransmitted packet now has a PSN This Packet
+   value of 4.
+
+   The Delta Time Last Sent is 30 -- in other words, the time between
+   sending the packet with a PSN of 3 and this current packet.
+
+   Let's say that packet 4 is lost again.  Then, after some amount of
+   time (RTO), the packet with a TCP sequence number of 223 is resent.
+
+   From the client, this is what is seen for the packets sent from the
+   server:
+
+   Pkt Sender    PSN        PSN     Delta Time  Delta Time  TCP   Data
+              This Pkt  Last Recvd  Last Recvd  Last Sent   SEQ   Bytes
+   ====================================================================
+   1   Server    5         0           0           60       223   100
+
+   If this packet now arrives at the destination, one has a very good
+   idea that packets exist that are being sent from the server as
+   retransmissions and not arriving at the client.  This is because the
+   PSN of the resent packet from the server is 5 rather than 4.  If we
+   had used the TCP sequence number alone, we would never have seen this
+   situation.  The TCP sequence number in all situations is 223.
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 27]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   This situation would be experienced by the user of the application
+   (the human being actually sitting somewhere) as "hangs" or long
+   delays between packets.  On large networks, to diagnose problems such
+   as these where packets are lost somewhere on the network, one has to
+   take multiple traces to find out exactly where.
+
+   The first thing to do is to start with doing a trace at the client
+   and the server, so that we can see if the server sent a particular
+   packet and the client received it.  If the client did not receive it,
+   then we start tracking back to trace points at the router right after
+   the server and the router right before the client.  Did they get
+   these packets that the server has sent?  This is a time-consuming
+   activity.
+
+   With PDM, we can speed up the diagnostic time because we may be able
+   to use only the trace taken at the client to see what the server is
+   sending.
+
+Appendix D.  Potential Overhead Considerations
+
+   One might wonder about the potential overhead of PDM.  First, PDM is
+   entirely optional.  That is, a site may choose to implement PDM or
+   not, as they wish.  If they are happy with the costs of PDM versus
+   the benefits, then the choice should be theirs.
+
+   Below is a table outlining the potential overhead in terms of
+   additional time to deliver the response to the end user for various
+   assumed RTTs:
+
+   Bytes         RTT         Bytes        Bytes      New     Overhead
+   in Packet                Per Millisec  in PDM     RTT
+   ====================================================================
+   1000       1000 milli         1        16     1016.000  16.000 milli
+   1000        100 milli        10        16      101.600   1.600 milli
+   1000         10 milli       100        16       10.160   0.160 milli
+   1000          1 milli      1000        16        1.016   0.016 milli
+
+   Below are two examples of actual RTTs for packets traversing large
+   enterprise networks.
+
+   The first example is for packets going to multiple business partners:
+
+   Bytes         RTT         Bytes        Bytes      New     Overhead
+   in Packet                Per Millisec  in PDM     RTT
+   ====================================================================
+   1000        17 milli        58         16       17.360   0.360 milli
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 28]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+   The second example is for packets at a large enterprise customer
+   within a data center.  Notice that the scale is now in microseconds
+   rather than milliseconds:
+
+   Bytes        RTT          Bytes        Bytes      New     Overhead
+   in Packet                Per Microsec  in PDM     RTT
+   ====================================================================
+   1000       20 micro         50         16       20.320   0.320 micro
+
+   As with other diagnostic tools, such as packet traces, a certain
+   amount of processing time will be required to create and process PDM.
+   Since PDM is lightweight (has only a few variables), we expect the
+   processing time to be minimal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 29]
+
+RFC 8250               IPv6 PDM Destination Option        September 2017
+
+
+Acknowledgments
+
+   The authors would like to thank Keven Haining, Al Morton, Brian
+   Trammell, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick
+   Troth for their comments and assistance.  We would also like to thank
+   Tero Kivinen and Jouni Korhonen for their detailed and perceptive
+   reviews.
+
+Authors' Addresses
+
+   Nalini Elkins
+   Inside Products, Inc.
+   36A Upper Circle
+   Carmel Valley, CA  93924
+   United States of America
+
+   Phone: +1 831 659 8360
+   Email: nalini.elkins@insidethestack.com
+   URI:   http://www.insidethestack.com
+
+
+   Robert M. Hamilton
+   Chemical Abstracts Service
+   A Division of the American Chemical Society
+   2540 Olentangy River Road
+   Columbus, Ohio  43202
+   United States of America
+
+   Phone: +1 614 447 3600 x2517
+   Email: rhamilton@cas.org
+   URI:   http://www.cas.org
+
+
+   Michael S. Ackermann
+   Blue Cross Blue Shield of Michigan
+   P.O. Box 2888
+   Detroit, Michigan  48231
+   United States of America
+
+   Phone: +1 310 460 4080
+   Email: mackermann@bcbsm.com
+   URI:   http://www.bcbsm.com
+
+
+
+
+
+
+
+
+
+Elkins, et al.               Standards Track                   [Page 30]
+