INTERNET-DRAFT N. Elkins B. Jouris Intended Status: Proposed Standard Inside Products Expires: April 2014 October 15, 2013 IPv6 Performance and Diagnostic Metrics Destination Option draft-elkins-6man-ipv6-pdm-dest-option-03 Abstract To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. The base metrics are: packet sequence number and packet timestamp. Metrics derived from these will be described separately. This document solves these problems with a new destination option, the Performance and Diagnostic Metrics destination option (PDM). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Elkins Expires April 18, 2014 [Page 1] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Performance and Diagnostic Metrics Destination Options . . . . 3 2.1 Destination Options Header . . . . . . . . . . . . . . . . 3 2.2 PDM Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Performance and Diagnostic Metrics Destination Option (Type 1) . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Performance and Diagnostic Metrics Destination Option (Type 2) . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Header Placement . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Implementation Considerations . . . . . . . . . . . . . . . 9 2.6.1 Dynamic Configuration Options . . . . . . . . . . . . . 9 2.6.2 Data Length Filtering . . . . . . . . . . . . . . . . . 10 2.6.3 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . 10 3 Sample Implementation Flow (PDM 1) . . . . . . . . . . . . . . . 10 3.1 Step 1 (PDM 1) . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Step 2 (PDM 1) . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Step 3 (PDM 1) . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Step 4 (PDM 1) . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Step 5 (PDM 1) . . . . . . . . . . . . . . . . . . . . . . . 13 4 Sample Implementation Flow (PDM 2) . . . . . . . . . . . . . . . 13 4.1 Step 1 (PDM 2) . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Step 2 (PDM 2) . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Step 3 (PDM 2) . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Step 4 (PDM 2) . . . . . . . . . . . . . . . . . . . . . . . 16 4.5 Step 5 (PDM 2) . . . . . . . . . . . . . . . . . . . . . . . 16 5 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2 Informative References . . . . . . . . . . . . . . . . . . . 17 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Elkins Expires April 18, 2014 [Page 2] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 1 Introduction To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmissions are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. The base metrics are: packet sequence number and packet timestamp. For background, please see draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM], draft-elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], draft-elkins-v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], draft- elkins-v6ops-ipv6-end-to-end-rt-needed-01 [ELKRSP] and draft-elkins- ippm-pdm-metrics-01 [ELKIPPM]. These drafts are companions to this document. As discussed in the above Internet Drafts, current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, and/or do not provide timely data. This document provides a solution for these problems. As defined in RFC2460 [RFC2460], 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 "middle boxes". This document specifies a new destination option, the Performance and Diagnostic Metrics destination option (PDM). 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Performance and Diagnostic Metrics Destination Options 2.1 Destination Options Header The IPv6 Destination Options Header is used to carry optional information that need 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 RFC2460 [RFC2460]. 2.2 PDM Types Elkins Expires April 18, 2014 [Page 3] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the Destination Options Header (Next Header value = 60). Two types of PDM are defined. PDM type 1 requires time synchronization. PDM type 2 does not require time synchronization. PDM type 1 and PDM type 2 are mutually exclusive. That is, a 5-tuple can either both send PDM type 1 or both send PDM type 2. 2.3 Performance and Diagnostic Metrics Destination Option (Type 1) PDM type 1 is used to facilitate diagnostics by including a packet sequence number and timestamp. The PDM type 1 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 | PSN This Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + TimeStamp This Packet (64-bit) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Last Packet | Reserved | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + TimeStamp Last Packet (64-bit) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] Option Length Elkins Expires April 18, 2014 [Page 4] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 22. Packet Sequence Number This Packet (PSNTP) 16-bit unsigned integer. This field will wrap. It is intended for human use. Initialized at a random number and monotonically incremented for packet on the 5-tuple. The 5-tuple consists of the source and destination IP addresses, the source and destination ports, and the upper layer protocol (ex. TCP, ICMP, etc). Operating systems MUST implement a separate packet sequence number counter per 5-tuple. Operating systems MUST NOT implement a single counter for all connections. Note: This is consistent with the current implementation of the IPID field in IPv4 for many, but not all, stacks. TimeStamp This Packet (TSTP) A 64-bit unsigned integer field containing a timestamp that this packet was sent by the source node. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 32 bits of the field, and the remaining 32 bits resolve to picoseconds. This follows timestamp formats used in Network Time Protocol (NTP) [RFC5905] and SEND [RFC3971]. A discussion of why NTP is used in preference to Precision Time Protocol (PTP) is in draft-elkins-v6ops- ipv6-end-to-end-rt-needed-01 [ELKRSP]. A discussion of how to implement NTP for use with the PDM header is in draft-ackermann- tictoc-pdm-ntp-usage-00 [ACKPDM]. Implementation note: This format is compatible with the usual representation of time under UNIX, although the number of bits available for the integer and fraction parts in different Unix implementations vary. Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSN of the packet last received Elkins Expires April 18, 2014 [Page 5] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 on the 5-tuple. TimeStamp Last Received (TSLR) A 64-bit unsigned integer field containing a timestamp. This is the timestamp of the packet last received on the 5-tuple. Format is the same as TSTP. 2.4 Performance and Diagnostic Metrics Destination Option (Type 2) The second type of IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is as follows. PDM type 1 and PDM type 2 are mutually exclusive. That is, a 5-tuple can either both send PDM type 1 or both send PDM type 2. PDM type 2 contains the following fields: PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTALR : Delta Last Received PSNLS : Packet Sequence Number Last Sent DELTALS : Delta Last Sent PDM destination option type 2 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 | PSN This Packet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Last Received | PSN Last Sent | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Last Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] Option Length Elkins Expires April 18, 2014 [Page 6] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 22. Packet Sequence Number This Packet (PSNTP) 16-bit unsigned integer. This field will wrap. It is intended for human use. Initialized at a random number and monotonically incremented for packet on the 5-tuple. The 5-tuple consists of the source and destination IP addresses, the source and destination ports, and the upper layer protocol (ex. TCP, ICMP, etc). Operating systems MUST implement a separate packet sequence number counter per 5-tuple. Operating systems MUST NOT implement a single counter for all connections. Note: This is consistent with the current implementation of the IPID field in IPv4 for many, but not all, stacks. Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSN of the packet last received on the 5-tuple. Packet Sequence Number Last Sent (PSNLS) 16-bit unsigned integer. This is the PSN of the packet last sent on the 5-tuple. Delta Last Received (DELTALR) A 32-bit unsigned integer field. This is server delay. DELTALR = Send time packet 2 - Receive time packet 1 The value is in nanoseconds. Delta Last Sent (DELTALS) A 32-bit unsigned integer field. This is round trip or end-to-end time. Elkins Expires April 18, 2014 [Page 7] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 Delta Last Sent = Receive time packet 2 - Send time packet 1 The value is in nanoseconds. Option Type The two highest-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. This indicates the following processing requirements: 00 - skip over this option and continue processing the header. RFC2460 [RFC2460] defines other values for the Option Type field. These MUST NOT be used in the PDM. The other values are as follows: 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. In keeping with RFC2460 [RFC2460], the third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. In the PDM, the value of the third-highest-order bit MUST be 0. The possible values are as follows: 0 - Option Data does not change en-route 1 - Option Data may change en-route The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type. That is, a particular option is identified by a full 8-bit Option Type, not just the low-order 5 bits of an Option Type. 2.5 Header Placement Elkins Expires April 18, 2014 [Page 8] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 The PDM destination option MUST be placed as follows: - Before the upper-layer header. That is, this is the last extension header. This follows the order defined in RFC2460 [RFC2460] IPv6 header Hop-by-Hop Options header Destination Options header Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header upper-layer header For each IPv6 packet header, the PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header. The inclusion of a PDM in a packet affects the receiving node's processing of only this single packet. No state is created or modified in the receiving node as a result of receiving a PDM in a packet. 2.6 Implementation Considerations The PDM destination options extension header SHOULD be turned on by each stack on a host node. 2.6.1 Dynamic Configuration Options If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed. If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an Elkins Expires April 18, 2014 [Page 9] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP address only. These are at the discretion of the implementation. The PDM MUST NOT be changed dynamically via packet flow as this may create potential security violation or DoS attack by numerous packets turning the header on and off. As with all other destination options extension headers, the PDM is for destination nodes only. As specified above, intermediate devices MUST neither set nor modify this field. 2.6.2 Data Length Filtering Different results for derived metrics, such as, server delay, will be obtained if calculations are done including or excluding packets which have a data length of 0 or 1. Some protocols, for example, TCP, provide acknowledgements which have a length of 0. Keep-alive packets have a data length of 0 or 1. Operating systems may provide the user a choice of whether to include or exclude packets with a 0 or 1 byte data length. 2.6.3 5-tuple Aging Within the operating system, metrics must be kept on a 5-tuple basis. As discussed before, these are: PSNTP : Packet Sequence Number This Packet TSTP : Timestamp This Packet PSNLR : Packet Sequence Number Last Received TSLR : Timestamp Last Received PROTC : Protocol for Upper Layer (ex. TCP, UDP, ICMP, etc) The question comes of when to stop keeping data or restarting the numbering for a 5-tuple. For example, in the case of TCP, at some point, the connection will terminate. Keeping data in control blocks forever, will have unfortunate consequences for the operating system. So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol [RFC0793]. The choice of aging parameter is left up to the implementation. 3 Sample Implementation Flow (PDM 1) Following is a sample simple flow for PDM type 1 with one packet sent from Host A and one packet received by Host B. The calculations to derive meaningful metrics for network diagnostics from these fields Elkins Expires April 18, 2014 [Page 10] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 is described in draft-elkins-ippm-pdm-metrics-00 [ELKIPPM]. Time synchronization is required between Host A and Host B. Each packet, in addition to the PDM contains information on the sender and receiver. This is the 5-tuple consisting of: SADDR : IP address of the sender SPORT : Port for sender DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) It should be understood that the packet identification information is in each packet. We will not repeat that in each of the following steps. 3.1 Step 1 (PDM 1) Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The timestamp and packet sequence number are sent in the PDM. The initial PSNTP from Host A starts at a random number. In this case, 25. The sub-second portion of the timestamp has been omitted for the sake of simplicity. Packet 1 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM 1 Contents: PSNTP : Packet Sequence Number This Packet: 25 TSTP : Timestamp This Packet: 10:00:00 PSNLR : Packet Sequence Number Last Received: - TSLR : Timestamp Last Received: - 3.2 Step 2 (PDM 1) Packet 1 is received by Host B. The time for Host B was synchronized with Host A. Both were set initially to 10:00AM. Elkins Expires April 18, 2014 [Page 11] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 The timestamp and PSN for the received packet are placed in the PSNLR and TSLR fields. These are from the point of view of B. That is, they indicate when the packet from A was received and which packet it was. The PDM is not sent at this point. It is only prepared. It will be sent when the response to packet 1 is sent by Host B. Packet 1 Received +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM 1 Contents: PSNTP : Packet Sequence Number This Packet: - TSTP : Timestamp This Packet: - PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received: 10:00:03 3.3 Step 3 (PDM 1) Packet 2 is sent from Host B to Host A. The initial PSNTP from Host B starts at a random number. In this case, 12. Packet 2 +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM 1 Contents: PSNTP : Packet Sequence Number This Packet: 12 TSTP : Timestamp This Packet: 10:00:07 PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received: 10:00:03 3.4 Step 4 (PDM 1) Packet 2 is received by Host A. Elkins Expires April 18, 2014 [Page 12] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 The timestamp and PSN for the received packet are placed in the PSNLR and TSLR fields. These are from the point of view of A. That is, they indicate when the packet from B was received and which packet it was. The PDM is not sent at this point. It is only prepared. It will be sent when the NEXT packet to Host B is sent by Host A. If there is no next packet for the 5-tuple, as may be the case for UDP, then this value will be missing. Packet 2 Received +----------+ +----------+ | | | | | Host | <---------- | Host | | A | | B | | | | | +----------+ +----------+ PDM 1 Contents: PSNTP : Packet Sequence Number This Packet: - TSTP : Timestamp This Packet: - PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received: 10:00:10 3.5 Step 5 (PDM 1) Packet 3 is sent from Host A to Host B. Packet 3 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM 1 Contents: PSNTP : Packet Sequence Number This Packet: 26 TSTP : Timestamp This Packet: 10:00:50 PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received: 10:00:10 4 Sample Implementation Flow (PDM 2) Following is a sample simple flow for PDM 2 with one packet sent from Elkins Expires April 18, 2014 [Page 13] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 Host A and one packet received by Host B. PDM 2 does not require time synchronization between Host A and Host B. The calculations to derive meaningful metrics for network diagnostics is shown below each packet sent or received. Each packet, in addition to the PDM contains information on the sender and receiver. As discussed before, a 5-tuple consists of: SADDR : IP address of the sender SPORT : Port for sender DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc) It should be understood that the packet identification information is in each packet. We will not repeat that in each of the following steps. 4.1 Step 1 (PDM 2) Packet 1 is sent from Host A to Host B. The time for Host A is set initially to 10:00AM. The timestamp and packet sequence number are noted by the sender internally. The packet sequence number and timestamp are sent in the packet. Packet 1 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM 2 Contents: PSNTP : Packet Sequence Number This Packet: 25 PSNLR : Packet Sequence Number Last Received: - DELTALR : Delta Last Received: - PSNLS : Packet Sequence Number Last Sent: - DELTALS : Delta Last Sent: - Internally, within the sender, Host A, it must keep: PSNTP : Packet Sequence Number This Packet: 25 TSTP : Timestamp This Packet: 10:00:00 Elkins Expires April 18, 2014 [Page 14] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 Note, the initial PSNTP from Host A starts at a random number. In this case, 25. The sub-second portion of the timestamp has been omitted for the sake of simplicity. 4.2 Step 2 (PDM 2) Packet 1 is received at Host B. His time is set to one hour later than Host A. In this case, 11:00AM Internally, within the receiver, Host B, it must keep: PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received : 11:00:03 Note, this timestamp is in Host B time. It has nothing whatsoever to do with Host A time. 4.3 Step 3 (PDM 2) Packet 2 is sent by Host B to Host A. Note, the initial 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: Sending time (packet 2) - receive time (packet 1) The result of this calculation: Delta Last Received. That is: DELTALR = Sending time (packet 2) - receive time (packet 1) Note, both sending time and receive time are saved internally in Host B. They do not travel in the packet. Only the Delta is in the packet. Assume that within Host B is the following: PSNLR : Packet Sequence Number Last Received: 25 TSLR : Timestamp Last Received : 11:00:03 PSNTP : Packet Sequence Number This Packet : 12 TSTP : Timestamp This Packet : 11:00:07 Hence, DELTALR becomes: Elkins Expires April 18, 2014 [Page 15] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 4 seconds = 11:00:07 - 11:00:03 4.4 Step 4 (PDM 2) Packet 2 is received at Host A. Remember, its time is set to one hour earlier than Host B. It will keep internally: PSNLR : Packet Sequence Number Last Received: 12 TSLR : Timestamp Last Received : 10:00:12 Note, this timestamp is in Host A time. It has nothing whatsoever to do with Host B time. The formula for end-to-time is: 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 response time = 10:00:12 - 10:00:00 or 12 seconds This derived metric we will call DELTALS or Delta Last Sent. At this point all metrics are in the Host and not exposed in a packet. To do that, we need a third packet. 4.5 Step 5 (PDM 2) Packet 3 is sent from Host A to Host B. Packet 3 +----------+ +----------+ | | | | | Host | ----------> | Host | | A | | B | | | | | +----------+ +----------+ PDM 2 Contents: PSNTP : Packet Sequence Number This Packet: 26 PSNLR : Packet Sequence Number Last Received: 12 DELTALR : Delta Last Received: * PSNLS : Packet Sequence Number Last Sent: 25 DELTALS : Delta Last Sent: 12 Elkins Expires April 18, 2014 [Page 16] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 5 Backward Compatibility The scheme proposed in this document is backward compatible with all the currently defined IPv6 extension headers. According to RFC2460 [RFC2460], if the destination node does not recognize this option, it should skip over this option and continue processing the header. 6 Security Considerations The PDM MUST NOT be changed dynamically via packet flow as this creates a possibility for potential security violations or DoS attacks by numerous packets turning the header on and off. 7 IANA Considerations An option type must be assigned by IANA for the Performance and Diagnostic Metrics destination option. 8 References 8.1 Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. 8.2 Informative References [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", Internet Draft, September 2013. Elkins Expires April 18, 2014 [Page 17] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-03 October 2013 [ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence- needed-01", Internet Draft, September 2013. [ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed- 01", Internet Draft, September 2013. [ELKUSE] Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage- 01", Internet Draft, September 2013 [ELKIPPM] Elkins, N., "draft-elkins-ippm-pdm-metrics-01", Internet Draft, October 2013. 9 Acknowledgments The authors would like to thank Mike Ackermann, Keven Haining, Sigfrido Perdomo, David Boyes, Rick Troth and Fred Baker for their comments. Authors' Addresses Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 831 659 8360 Email: nalini.elkins@insidethestack.com http://www.insidethestack.com William Jouris Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 925 855 9512 Email: bill.jouris@insidethestack.com http://www.insidethestack.com Elkins Expires April 18, 2014 [Page 18]