idnits 2.17.1 draft-elkins-6man-ipv6-pdm-dest-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2013) is 3851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ACKPDM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELKPSN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELKRSP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELKUSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELKIPPM' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 Intended Status: Proposed Standard W. Jouris 4 Inside Products 5 Expires: April 2014 October 3, 2013 7 IPv6 Performance and Diagnostic Metrics Destination Option 8 draft-elkins-6man-ipv6-pdm-dest-option-02 10 Abstract 12 To diagnose performance and connectivity problems, metrics on real 13 (non-synthetic) transmission are critical for timely end-to-end 14 problem resolution. Such diagnostics may be real-time or after the 15 fact, but must not impact an operational production network. The base 16 metrics are: packet sequence number and packet timestamp. Metrics 17 derived from these will be described separately. This document solves 18 these problems with a new destination option, the Performance and 19 Diagnostic Metrics destination option (PDM). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2 Performance and Diagnostic Metrics Destination Option . . . . . 4 62 2.1 Destination Options Header . . . . . . . . . . . . . . . . 4 63 2.2 Performance and Diagnostic Metrics Destination Option . . . 5 64 2.3 Implementation Considerations . . . . . . . . . . . . . . . 8 65 2.3.1 Dynamic Configuration Options . . . . . . . . . . . . . 8 66 2.3.2 Data Length Filtering . . . . . . . . . . . . . . . . . 9 67 2.3.3 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . 9 68 2.4 Sample Implementation Flow . . . . . . . . . . . . . . . . 10 69 3.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 75 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 76 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 77 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 79 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1 Introduction 84 To diagnose performance and connectivity problems, metrics on real 85 (non-synthetic) transmission are critical for timely end-to-end 86 problem resolution. Such diagnostics may be real-time or after the 87 fact, but must not impact an operational production network. The base 88 metrics are: packet sequence number and packet timestamp. 90 For background, please see draft-ackermann-tictoc-pdm-ntp-usage-00 91 [ACKPDM], draft-elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], 92 draft-elkins-v6ops-ipv6-pdm-recommended-usage-01 [ELKUSE], draft- 93 elkins-v6ops-ipv6-end-to-end-rt-needed-01 [ELKRSP] and draft-elkins- 94 ippm-pdm-metrics-00 [ELKIPPM]. These drafts are companions to this 95 document. 97 As discussed in the above Internet Drafts, current methods are 98 inadequate for these purposes because they assume unreasonable access 99 to intermediate devices, are cost prohibitive, require infeasible 100 changes to a running production network, and / or do not provide 101 timely data. This document provides a solution for these problems. 103 As defined in RFC2460 [RFC2460], destination options are carried by 104 the IPv6 Destination Options extension header. Destination options 105 include optional information that need be examined only by the IPv6 106 node given as the destination address in the IPv6 header, not by 107 routers or other "middle boxes". This document specifies a new 108 destination option, the Performance and Diagnostic Metrics 109 destination option (PDM). 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2 Performance and Diagnostic Metrics Destination Option 119 2.1 Destination Options Header 121 The IPv6 Destination Options Header is used to carry optional 122 information that need be examined only by a packet's destination 123 node(s). The Destination Options Header is identified by a Next 124 Header value of 60 in the immediately preceding header and is defined 125 in RFC2460 [RFC2460]. 127 2.2 Performance and Diagnostic Metrics Destination Option 129 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 130 is an implementation of the Destination Options Header (Next Header 131 value = 60). 133 It is used to facilitate diagnostics by including a packet sequence 134 number and timestamp. 136 The PDM destination option is encoded in type-length-value (TLV) 137 format as follows: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Option Type | Option Length | PSN This Packet | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | | 145 + + 146 | | 147 + TimeStamp This Packet (64-bit) + 148 | | 149 + + 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | PSN Last Packet | Reserved | 153 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + + 156 | | 157 + TimeStamp Last Packet (64-bit) + 158 | | 159 + + 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Option Type 165 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 167 Option Length 169 8-bit unsigned integer. Length of the option, in octets, excluding 170 the Option Type and Option Length fields. This field MUST be set to 171 22. 173 Packet Sequence Number This Packet (PSNTP) 175 16-bit unsigned integer. This field will wrap. It is intended for 176 human use. 178 Initialized at a random number and monotonically incremented for 179 packet on the 5-tuple. The 5-tuple consists of the source and 180 destination IP addresses, the source and destination ports, and the 181 upper layer protocol (ex. TCP, ICMP, etc). 183 Operating systems MUST implement a separate packet sequence number 184 counter per 5-tuple. Operating systems MUST NOT implement a single 185 counter for all connections. 187 Note: This is consistent with the current implementation of the IPID 188 field in IPv4 for many, but not all, stacks. 190 TimeStamp This Packet (TSTP) 192 A 64-bit unsigned integer field containing a timestamp that this 193 packet was sent by the source node. The value indicates the number 194 of seconds since January 1, 1970, 00:00 UTC, by using a fixed point 195 format. In this format, the integer number of seconds is contained 196 in the first 32 bits of the field, and the remaining 32 bits resolve 197 to picoseconds. 199 This follows timestamp formats used in Network Time Protocol (NTP) 200 [RFC5905] and SEND [RFC3971]. A discussion of why NTP is used in 201 preference to Precision Time Protocol (PTP) is in draft-elkins-v6ops- 202 ipv6-end-to-end-rt-needed-01 [ELKRSP]. A discussion of how to 203 implement NTP for use with the PDM header is in draft-ackermann- 204 tictoc-pdm-ntp-usage-00 [ACKPDM]. 206 Implementation note: This format is compatible with the usual 207 representation of time under UNIX, although the number of bits 208 available for the integer and fraction parts in different Unix 209 implementations vary. 211 Packet Sequence Number Last Received (PSNLR) 213 16-bit unsigned integer. This is the PSN of the packet last received 214 on the 5-tuple. 216 TimeStamp Last Received (TSLR) 218 A 64-bit unsigned integer field containing a timestamp. This is the 219 timestamp of the packet last received on the 5-tuple. 221 The value indicates the number of seconds since January 1, 1970, 222 00:00 UTC, by using a fixed point format. In this format, the 223 integer number of seconds is contained in the first 32 bits of the 224 field, and the remaining 32 bits resolve to picoseconds. 226 Option Type 228 The two highest-order bits of the Option Type field are encoded to 229 indicate specific processing of the option; for the PDM destination 230 option, these two bits MUST be set to 00. This indicates the 231 following processing requirements: 233 00 - skip over this option and continue processing the header. 235 RFC2460 [RFC2460] defines other values for the Option Type field. 236 These MUST NOT be used in the PDM. The other values are as follows: 238 01 - discard the packet. 240 10 - discard the packet and, regardless of whether or not the 241 packet's Destination Address was a multicast address, send an ICMP 242 Parameter Problem, Code 2, message to the packet's Source Address, 243 pointing to the unrecognized Option Type. 245 11 - discard the packet and, only if the packet's Destination 246 Address was not a multicast address, send an ICMP Parameter Problem, 247 Code 2, message to the packet's Source Address, pointing to the 248 unrecognized Option Type. 250 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 251 Option Type specifies whether or not the Option Data of that option 252 can change en-route to the packet's final destination. 254 In the PDM, the value of the third-highest-order bit MUST be 0. The 255 possible values are as follows: 257 0 - Option Data does not change en-route 259 1 - Option Data may change en-route 261 The three high-order bits described above are to be treated as part 262 of the Option Type, not independent of the Option Type. That is, a 263 particular option is identified by a full 8-bit Option Type, not just 264 the low-order 5 bits of an Option Type. 266 Header Placement 268 The PDM destination option MUST be placed as follows: 270 - Before the upper-layer header. That is, this is the last 271 extension header. 273 This follows the order defined in RFC2460 [RFC2460] 275 IPv6 header 277 Hop-by-Hop Options header 279 Destination Options header 281 Routing header 283 Fragment header 285 Authentication header 287 Encapsulating Security Payload header 289 Destination Options header 291 upper-layer header 293 For each IPv6 packet header, the PDM MUST NOT appear more than once. 294 However, an encapsulated packet MAY contain a separate PDM associated 295 with each encapsulated IPv6 header. 297 The inclusion of a PDM in a packet affects the receiving node's 298 processing of only this single packet. No state is created or 299 modified in the receiving node as a result of receiving a PDM in a 300 packet. 302 2.3 Implementation Considerations 304 The PDM destination options extension header SHOULD be turned on by 305 each stack on a host node. 307 2.3.1 Dynamic Configuration Options 309 If implemented, each operating system MUST have a default 310 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 312 The operating system MAY also have a dynamic configuration option to 313 change the configuration setting as needed. 315 If the PDM destination options extension header is used, then it MAY 316 be turned on for all packets flowing through the host, applied to an 317 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 318 address only. These are at the discretion of the implementation. 320 The PDM MUST NOT be changed dynamically via packet flow as this may 321 create potential security violation or DoS attack by numerous packets 322 turning the header on and off. 324 As with all other destination options extension headers, the PDM is 325 for destination nodes only. As specified above, intermediate devices 326 MUST neither set nor modify this field. 328 2.3.2 Data Length Filtering 330 Different results for derived metrics, such as, server delay, will be 331 obtained if calculations are done including or excluding packets 332 which have a data length of 0 or 1. Some protocols, for example, 333 TCP, provide acknowledgements which have a length of 0. Keep-alive 334 packets have a data length of 0 or 1. 336 Operating systems may provide the user a choice of whether to include 337 or exclude packets with a zero or 1 byte data length. 339 2.3.3 5-tuple Aging 341 Within the operating system, metrics must be kept on a 5-tuple basis. 343 As will be discussed in section 2.4, these are: 345 PSNTP : Packet Sequence Number This Packet 346 TSTP : Timestamp This Packet 347 PSNLR : Packet Sequence Number Last Received 348 TSLR : Timestamp Last Received 349 PROTC : Protocol for Upper Layer (ex. TCP, UDP, ICMP, etc) 351 The question comes of when to stop keeping data or restarting the 352 numbering for a 5-tuple. For example, in the case of TCP, at some 353 point, the connection will terminate. Keeping data in control blocks 354 forever, will have unfortunate consequences for the operating system. 356 The choice of aging parameter is left up to the implementation. 358 2.4 Sample Implementation Flow 360 Following is a sample simple flow with one packet sent from Host A 361 and one packet received by Host B. The calculations to derive 362 meaningful metrics for network diagnostics from these fields is 363 described in draft-elkins-ippm-pdm-metrics-00 [ELKIPPM]. 365 Time synchronization is required between Host A and Host B. 367 Each packet, in addition to the PDM contains information on the 368 sender and receiver. This is the 5-tuple consisting of: 370 SADDR : IP address of the sender 371 SPORT : Port for sender 372 DADDR : IP address of the destination 373 DPORT : Port for destination 374 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 376 It should be understood that the packet identification information is 377 in each packet. We will not repeat that in each of the following 378 steps. 380 3.1 Step 1 382 Packet 1 is sent from Host A to Host B. The time for Host A is set 383 initially to 10:00AM. 385 The timestamp and packet sequence number are sent in the PDM. 387 The initial PSNTP from Host A starts at a random number. In this 388 case, 25. The sub-second portion of the timestamp has been omitted 389 for the sake of simplicity. 391 Packet 1 393 +----------+ +----------+ 394 | | | | 395 | Host | ----------> | Host | 396 | A | | B | 397 | | | | 398 +----------+ +----------+ 400 PDM Contents: 402 PSNTP : Packet Sequence Number This Packet: 25 403 TSTP : Timestamp This Packet: 10:00:00 404 PSNLR : Packet Sequence Number Last Received: - 405 TSLR : Timestamp Last Received: - 407 3.2 Step 2 409 Packet 1 is received by Host B. The time for Host B was synchronized 410 with Host A. Both were set initially to 10:00AM. 412 The timestamp and PSN for the received packet are placed in the PSNLR 413 and TSLR fields. These are from the point of view of B. That is, 414 they indicate when the packet from A was received and which packet it 415 was. 417 The PDM is not sent at this point. It is only prepared. It will be 418 sent when the response to packet 1 is sent by Host B. 420 Packet 1 Received 422 +----------+ +----------+ 423 | | | | 424 | Host | ----------> | Host | 425 | A | | B | 426 | | | | 427 +----------+ +----------+ 429 PDM Contents: 431 PSNTP : Packet Sequence Number This Packet: - 432 TSTP : Timestamp This Packet: - 433 PSNLR : Packet Sequence Number Last Received: 25 434 TSLR : Timestamp Last Received: 10:00:03 436 3.3 Step 3 438 Packet 2 is sent from Host B to Host A. The initial PSNTP from Host 439 B starts at a random number. In this case, 12. 441 Packet 2 443 +----------+ +----------+ 444 | | | | 445 | Host | <---------- | Host | 446 | A | | B | 447 | | | | 448 +----------+ +----------+ 450 PDM Contents: 452 PSNTP : Packet Sequence Number This Packet: 12 453 TSTP : Timestamp This Packet: 10:00:07 454 PSNLR : Packet Sequence Number Last Received: 25 455 TSLR : Timestamp Last Received: 10:00:03 457 3.4 Step 4 459 Packet 2 is received by Host A. 461 The timestamp and PSN for the received packet are placed in the PSNLR 462 and TSLR fields. These are from the point of view of A. That is, 463 they indicate when the packet from B was received and which packet it 464 was. 466 The PDM is not sent at this point. It is only prepared. It will be 467 sent when the NEXT packet to Host B is sent by Host A. If there is no 468 next packet for the 5-tuple, as may be the case for UDP, then this 469 value will be missing. 471 Packet 2 Received 473 +----------+ +----------+ 474 | | | | 475 | Host | <---------- | Host | 476 | A | | B | 477 | | | | 478 +----------+ +----------+ 480 PDM Contents: 482 PSNTP : Packet Sequence Number This Packet: - 483 TSTP : Timestamp This Packet: - 484 PSNLR : Packet Sequence Number Last Received: 12 485 TSLR : Timestamp Last Received: 10:00:10 487 3.5 Step 5 489 Packet 3 is sent from Host A to Host B. 490 Packet 3 492 +----------+ +----------+ 493 | | | | 494 | Host | ----------> | Host | 495 | A | | B | 496 | | | | 497 +----------+ +----------+ 499 PDM Contents: 501 PSNTP : Packet Sequence Number This Packet: 26 502 TSTP : Timestamp This Packet: 10:00:50 503 PSNLR : Packet Sequence Number Last Received: 12 504 TSLR : Timestamp Last Received: 10:00:10 506 3 Backward Compatibility 508 The scheme proposed in this document is backward compatible with all 509 the currently defined IPv6 extension headers. According to RFC2460 510 [RFC2460], if the destination node does not recognize this option, it 511 should skip over this option and continue processing the header. 513 4 Security Considerations 515 The PDM MUST NOT be changed dynamically via packet flow as this 516 creates a possibility for potential security violations or DoS 517 attacks by numerous packets turning the header on and off. 519 5 IANA Considerations 521 An option type must be assigned by IANA for the Performance and 522 Diagnostic Metrics destination option. 524 6 References 526 6.1 Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 532 (IPv6) Specification", RFC 2460, December 1998. 534 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 535 Values In the Internet Protocol and Related Headers", 536 BCP 37, RFC 2780, March 2000. 538 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 539 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 541 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 542 "Network Time Protocol Version 4: Protocol and Algorithms 543 Specification", RFC 5905, June 2010. 545 [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", 546 Internet Draft, September 2013. 548 [ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence- 549 needed-01", Internet Draft, September 2013. 551 [ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed- 552 01", Internet Draft, September 2013. 554 [ELKUSE] Elkins, N., "draft-elkins-v6ops-ipv6-pdm-recommended-usage- 555 01", Internet Draft, September 2013 557 [ELKIPPM] Elkins, N., "Draft-elkins-ippm-pdm-metrics-00", Internet 558 Draft, September 2013. 560 7 Acknowledgments 562 The authors would like to thank Mike Ackermann, Keven 563 Haining, Sigfrido Perdomo, David Boyes, Rick Troth and 564 Fred Baker for their comments. 566 Authors' Addresses 568 Nalini Elkins 569 Inside Products, Inc. 570 36A Upper Circle 571 Carmel Valley, CA 93924 572 United States 573 Phone: +1 831 659 8360 574 Email: nalini.elkins@insidethestack.com 575 http://www.insidethestack.com 577 William Jouris 578 Inside Products, Inc. 579 36A Upper Circle 580 Carmel Valley, CA 93924 581 United States 582 Phone: +1 925 855 9512 583 Email: bill.jouris@insidethestack.com 584 http://www.insidethestack.com