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