idnits 2.17.1 draft-elkins-6man-ipv6-pdm-dest-option-08.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 10, 2014) is 3480 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 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 Inside Products 4 R. Hamilton 5 Chemical Abstracts Service 6 M. Ackermann 7 Intended Status: Proposed Standard BCBS Michigan 8 Expires: April 2015 October 10, 2014 10 IPv6 Performance and Diagnostic Metrics Destination Option 11 draft-elkins-6man-ipv6-pdm-dest-option-08 13 Abstract 15 To measure performance and to diagnose performance and connectivity 16 problems, metrics embedded in each packet are critical for timely and 17 accurate problem resolution. Such diagnostics may be interpreted in 18 real-time or after the fact. The base metrics are: packet sequence 19 number and packet timing. Metrics derived from these will be 20 described separately. This document describes a new implementation of 21 the existing IPv6 Destination Options extension header, the 22 Performance and Diagnostic Metrics (PDM) Destination Options 23 extension header. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2 Performance and Diagnostic Metrics Destination Option . . . . . 3 66 2.1 Destination Options Header . . . . . . . . . . . . . . . . 3 67 2.2 Performance and Diagnostic Metrics Destination Option . . . 4 68 2.3 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.4 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 7 70 2.5 Header Placement . . . . . . . . . . . . . . . . . . . . . 8 71 2.6 Implementation Considerations . . . . . . . . . . . . . . . 9 72 2.6.1 Dynamic Configuration Options . . . . . . . . . . . . . 9 73 2.6.2 Data Length Filtering . . . . . . . . . . . . . . . . . 9 74 2.6.3 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . 9 75 3 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 76 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 77 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 78 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 80 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1 Introduction 85 To measure performance and to diagnose performance and connectivity 86 problems, metrics embedded in each packet are critical for timely and 87 accurate problem resolution. Such diagnostics may be interpreted in 88 real-time or after the fact. The base metrics are: packet sequence 89 number and packet timing. Metrics derived from these will be 90 described separately. This document describes a new implementation of 91 an existing IPv6 Destination Options extension header, the 92 Performance and Diagnostic Metrics (PDM) Destination Options 93 extension header. 95 For the rationale and usage of the PDM extension header, see "IPPM 96 Considerations for the IPv6 PDM Destination Option" [ELK-IPPM]. 97 [ELK-IPPM] discusses measurement of end-user Quality of Experience 98 (QoE) as well as the details of the scaling factors used. The 99 current document describes the fields in the PDM header itself. 101 As defined in RFC2460 [RFC2460], destination options are carried by 102 the IPv6 Destination Options extension header. Destination options 103 include optional information that need be examined only by the IPv6 104 node given as the destination address in the IPv6 header, not by 105 routers or other "middle boxes". This document specifies a new 106 destination option, the Performance and Diagnostic Metrics (PDM) 107 destination option. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2 Performance and Diagnostic Metrics Destination Option 117 2.1 Destination Options Header 119 The IPv6 Destination Options Header is used to carry optional 120 information that need be examined only by a packet's destination 121 node(s). The Destination Options Header is identified by a Next 122 Header value of 60 in the immediately preceding header and is defined 123 in RFC2460 [RFC2460]. 125 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 126 is an implementation of the IPv6 Destination Options extension header 127 (Next Header value = 60). The PDM does not require time 128 synchronization. 130 2.2 Performance and Diagnostic Metrics Destination Option 132 The Performance and Diagnostic Metrics Destination Option (PDM) 133 contains the following fields: 135 TIMEBASE : Base timer unit 136 SCALEDL : Scale for Delta Last Received 137 SCALEDS : Scale for Delta Last Sent 138 PSNTP : Packet Sequence Number This Packet 139 PSNLR : Packet Sequence Number Last Received 140 DELTALR : Delta Last Received 141 DELTALS : Delta Last Sent 143 For a full explanation of the SCALEDL, SCALEDS, DELTALR, DELTALS 144 fields, see [ELK-IPPM]. 146 The PDM destination option is encoded in type-length-value (TLV) 147 format as follows: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Option Type | Option Length |TB |ScaleDL | ScaleDS | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | PSN This Packet | PSN Last Received | 155 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Delta Last Received | Delta Last Sent | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Option Type 161 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 163 Option Length 165 8-bit unsigned integer. Length of the option, in octets, excluding 166 the Option Type and Option Length fields. This field MUST be set to 167 16. 169 Time Base 171 2-bit unsigned integer. It will indicate the unit measurement for 172 this device. That is, for a value of 11 in the Time Base field, a 173 value of 1 in the DELTA fields indicates this device has incremented 174 the time by 1 picosecond. Similarly, for a value of 01 in the Time 175 Base field, a DELTA value of 1 indicates an increment of 1 176 microsecond. 178 The possible values of Time Base are as follows: 180 00 - milliseconds 181 01 - microseconds 182 10 - nanoseconds 183 11 - picoseconds 185 Packet Sequence Number This Packet (PSNTP) 187 16-bit unsigned integer. This field will wrap. It is intended for 188 human use. 190 Initialized at a random number and monotonically incremented for 191 packet on the 5-tuple. The 5-tuple consists of the source and 192 destination IP addresses, the source and destination ports, and the 193 upper layer protocol (ex. TCP, ICMP, etc). 195 Operating systems MUST implement a separate packet sequence number 196 counter per 5-tuple. Operating systems MUST NOT implement a single 197 counter for all connections. 199 Note: This is consistent with the current implementation of the IPID 200 field in IPv4 for many, but not all, stacks. 202 Packet Sequence Number Last Received (PSNLR) 204 16-bit unsigned integer. This is the PSN of the packet last received 205 on the 5-tuple. 207 Scale Delta Last Received (SCALEDLR) 209 7-bit signed integer. This is the scaling value for the Delta Last 210 Received (DELTALR) field. The possible values are from -64 to +63. 212 Scale Delta Last Sent (SCALEDLS) 214 7-bit signed integer. This is the scaling value for the Delta Last 215 Sent (DELTALS) field. The possible values are from -64 to +63. 217 Delta Last Received (DELTALR) 218 A 16-bit unsigned integer field. 220 DELTALR = Send time packet 2 - Receive time packet 1 222 The value is according to the scale in SCALEDLR. 224 Delta Last Sent (DELTALS) 226 A 16-bit unsigned integer field. 228 Delta Last Sent = Receive time packet 2 - Send time packet 1 230 The value is in according to the scale in SCALEDLS. 232 Option Type 234 The two highest-order bits of the Option Type field are encoded to 235 indicate specific processing of the option; for the PDM destination 236 option, these two bits MUST be set to 00. This indicates the 237 following processing requirements: 239 00 - skip over this option and continue processing the header. 241 RFC2460 [RFC2460] defines other values for the Option Type field. 242 These MUST NOT be used in the PDM. The other values are as follows: 244 01 - discard the packet. 246 10 - discard the packet and, regardless of whether or not the 247 packet's Destination Address was a multicast address, send an ICMP 248 Parameter Problem, Code 2, message to the packet's Source Address, 249 pointing to the unrecognized Option Type. 251 11 - discard the packet and, only if the packet's Destination 252 Address was not a multicast address, send an ICMP Parameter Problem, 253 Code 2, message to the packet's Source Address, pointing to the 254 unrecognized Option Type. 256 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 257 Option Type specifies whether or not the Option Data of that option 258 can change en-route to the packet's final destination. 260 In the PDM, the value of the third-highest-order bit MUST be 0. The 261 possible values are as follows: 263 0 - Option Data does not change en-route 265 1 - Option Data may change en-route 267 The three high-order bits described above are to be treated as part 268 of the Option Type, not independent of the Option Type. That is, a 269 particular option is identified by a full 8-bit Option Type, not just 270 the low-order 5 bits of an Option Type. 272 2.3 Time Base 274 This specification allows for the fact that different CPU TOD clocks 275 use different binary points. For some clocks, a value of 1 could 276 indicate 1 microsecond, whereas other clocks could use the value 1 to 277 indicate 1 millisecond. In the former case, the binary digits to the 278 right of that binary point measure 2**(-n) microseconds, and in the 279 latter case, 2**(-n) milliseconds. 281 The Time Base allows us to ensure we have a common reference, at the 282 very least, common knowledge of what the binary point is for the 283 transmitted values. 285 2.4 Timer-value scaling 287 As discussed in [TRAM-TCPM] we propose storing not an entire time- 288 interval value, but just the most significant bits of that value, 289 along with a scaling factor to indicate the magnitude of the time- 290 interval value. In our case, we will use the high-order 16 bits. The 291 scaling value will be the number of bits in the timer register to the 292 right of the 16th significant bit. That is, if the timer register 293 contains this binary value: 295 1110100011010100101001010001000000000000 296 <-16 bits -><-24 bits -> 298 then, the values stored would be 1110 1000 1101 0100 in binary (E8D4 299 hexadecimal) for the time value and 24 for the scaling value. Note 300 that the displayed value is the binary equivalent of 1 second 301 expressed in picoseconds. 303 The following table represents a device which has a TimeBase of 304 picosecond (or 11). For this Time Base value the smallest and 305 simplest time value to represent is 1 picosecond; the encoded value 306 is 1, and the scaling value is 0. Using time values in the first 307 column in the table below, we create the following encoded values and 308 scaling values: 310 Time value in Encoded Scaling 311 Delta time picoseconds value decimal 312 ----------------------------------------------------- 313 1 picosecond 1 0001 0 314 1 nanosecond 3e8 03e8 0 315 1 microsecond f4240 f424 4 316 1 millisecond 3b9aca00 3b9a 16 317 1 second e8d4a51000 e8d4 24 318 1 minute 3691d6afc000 3691 32 319 1 hour cca2e51310000 cca2 36 320 1 day 132f4579c980000 132f 44 321 365 days 1b5a660ea44b80000 1b5a 52 323 Sample binary values (high order 16 bits taken) 325 1 psec 1 0001 326 1 nsec 3e8 0011 1110 1000 327 1 usec f4240 1111 0100 0010 0100 0000 328 1 msec 3b9aca00 0011 1011 1001 1010 1100 1010 0000 0000 329 1 sec e8d4a51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000 331 The need for a signed scaling value is more apparent when the Time 332 Base is lower. If you specify your Time Base is microseconds (or 01) 333 then these tables looks very similar: 335 Time value in Encoded Scaling 336 Delta time microseconds value decimal 337 -------------------------------------------------------- 338 1 microsecond 1 0001 0 339 1 millisecond 3e8 03e8 0 340 1 second f4240 f424 4 341 1 minute 3938700 e4e1 10 342 1 hour d693a400 d693 16 343 1 day 141dd76000 a0ee 21 345 An issue arises when the binary point is at the microsecond level, as 346 it is here, but the time differential to be expressed is some number 347 of nanoseconds or picoseconds. For example 1 nanosecond is .001 348 microseconds, or about .000000000100000110001001001 in binary. To 349 encode this value we would follow the same procedure: 351 <- 25 bits -> Scaling value: -25 352 000000000100000110001001001 353 <-16 bits -> Encoded value: 8312 355 So, the encoded value would be 8312, with a scaling value of -25 356 which, in the signed 7-bit SCALEDS or SCALEDR field would be 357 represented as 1100111 in binary. 359 Similarly, if the Time Base is 10, indicating the clock is counting 360 nanoseconds, the encoded value and scaling values for 1 picosecond, 361 or .001 nanoseconds are the same, 8312 and -25, because we've changed 362 the Time Base. 364 For further discussion on timing and scaling, please see "IPPM 365 Considerations for the IPv6 PDM Destination Option" [ELK-IPPM]. 367 2.5 Header Placement 369 The PDM destination option MUST be placed as follows: 371 - Before the upper-layer header. That is, this is the last 372 extension header. 374 This follows the order defined in RFC2460 [RFC2460] 376 IPv6 header 378 Hop-by-Hop Options header 380 Destination Options header 382 Routing header 384 Fragment header 386 Authentication header 388 Encapsulating Security Payload header 390 Destination Options header 392 upper-layer header 394 For each IPv6 packet header, the PDM MUST NOT appear more than once. 395 However, an encapsulated packet MAY contain a separate PDM associated 396 with each encapsulated IPv6 header. 398 The inclusion of a PDM in a packet affects the receiving node's 399 processing of only this single packet. No state is created or 400 modified in the receiving node as a result of receiving a PDM in a 401 packet. 403 2.6 Implementation Considerations 405 The PDM destination options extension header SHOULD be turned on by 406 each stack on a host node. 408 2.6.1 Dynamic Configuration Options 410 If implemented, each operating system MUST have a default 411 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 412 The operating system MAY also have a dynamic configuration option to 413 change the configuration setting as needed. 415 If the PDM destination options extension header is used, then it MAY 416 be turned on for all packets flowing through the host, applied to an 417 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 418 address only. These are at the discretion of the implementation. 420 The PDM MUST NOT be changed dynamically via packet flow as this may 421 create potential security violation or DoS attack by numerous packets 422 turning the header on and off. 424 As with all other destination options extension headers, the PDM is 425 for destination nodes only. As specified above, intermediate devices 426 MUST neither set nor modify this field. 428 2.6.2 Data Length Filtering 430 Different results for derived metrics, such as, server delay, will be 431 obtained if calculations are done including or excluding packets 432 which have a data length of 0 or 1. Some protocols, for example, 433 TCP, provide acknowledgements which have a length of 0. Keep-alive 434 packets have a data length of 0 or 1. 436 Operating systems may provide the user a choice of whether to include 437 or exclude packets with a 0 or 1 byte data length. 439 2.6.3 5-tuple Aging 441 Within the operating system, metrics must be kept on a 5-tuple basis. 442 The 5-tuple is: 444 SADDR : IP address of the sender 445 SPORT : Port for sender 446 DADDR : IP address of the destination 447 DPORT : Port for destination 448 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP) 450 The question comes of when to stop keeping data or restarting the 451 numbering for a 5-tuple. For example, in the case of TCP, at some 452 point, the connection will terminate. Keeping data in control blocks 453 forever, will have unfortunate consequences for the operating system. 455 So, the recommendation is to use a known aging parameter such as Max 456 Segment Lifetime (MSL) as defined in Transmission Control Protocol 457 [RFC0793]. The choice of aging parameter is left up to the 458 implementation. 460 3 Backward Compatibility 462 The scheme proposed in this document is backward compatible with all 463 the currently defined IPv6 extension headers. According to RFC2460 464 [RFC2460], if the destination node does not recognize this option, it 465 should skip over this option and continue processing the header. 467 4 Security Considerations 469 The PDM MUST NOT be changed dynamically via packet flow as this 470 creates a possibility for potential security violations or DoS 471 attacks by numerous packets turning the header on and off. 473 5 IANA Considerations 475 An option type must be assigned by IANA for the Performance and 476 Diagnostic Metrics (PDM) destination option. 478 6 References 480 6.1 Normative References 482 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 483 RFC 793, September 1981. 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", RFC 2460, December 1998. 491 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 492 Values In the Internet Protocol and Related Headers", BCP 493 37, RFC 2780, March 2000. 495 6.2 Informative References 497 [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP 498 Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] 500 [ELK-IPPM] Elkins, N., "IPPM Considerations for the IPv6 PDM 501 Destination Option-01", Internet Draft, October 2014. 503 7 Acknowledgments 505 The authors would like to thank Keven Haining, Bill Jouris, Sigfrido 506 Perdomo and Fred Baker for their comments. 508 Authors' Addresses 510 Nalini Elkins 511 Inside Products, Inc. 512 36A Upper Circle 513 Carmel Valley, CA 93924 514 United States 515 Phone: +1 831 659 8360 516 Email: nalini.elkins@insidethestack.com 517 http://www.insidethestack.com 519 Robert M. Hamilton 520 Chemical Abstracts Service 521 A Division of the American Chemical Society 522 2540 Olentangy River Road 523 Columbus, Ohio 43202 524 United States 525 Phone: +1 614 447 3600 x2517 526 Email: rhamilton@cas.org 527 http://www.cas.org 529 Michael S. Ackermann 530 Blue Cross Blue Shield of Michigan 531 P.O. Box 2888 532 Detroit, Michigan 48231 533 United States 534 Phone: +1 310 460 4080 535 Email: mackermann@bcbsmi.com 536 http://www.bcbsmi.com