idnits 2.17.1 draft-elkins-6man-ipv6-pdm-dest-option-06.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 (July 29, 2014) is 3557 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 B. Jouris 4 Inside Products 5 M. Ackermann 6 Intended Status: Proposed Standard BCBS Michigan 7 Expires: January 2015 July 29, 2014 9 IPv6 Performance and Diagnostic Metrics Destination Option 10 draft-elkins-6man-ipv6-pdm-dest-option-06 12 Abstract 14 To diagnose performance and connectivity problems, metrics on passive 15 traffic are critical for timely end-to-end problem resolution. Such 16 diagnostics may be real-time or after the fact, but must not impact 17 an operational production network. The base metrics are: packet 18 sequence number and packet timestamp. Metrics derived from these 19 will be described separately. This document solves these problems 20 with a new destination option, the Performance and Diagnostic Metrics 21 destination option (PDM). 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Performance and Diagnostic Metrics Destination Option . . . . . 3 63 2.1 Destination Options Header . . . . . . . . . . . . . . . . 3 64 2.2 PDM Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3 Performance and Diagnostic Metrics Destination Option . . . 3 66 2.4 Header Placement . . . . . . . . . . . . . . . . . . . . . . 7 67 2.5 Implementation Considerations . . . . . . . . . . . . . . . 8 68 2.5.1 Dynamic Configuration Options . . . . . . . . . . . . . 8 69 2.5.2 Data Length Filtering . . . . . . . . . . . . . . . . . 8 70 2.5.3 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . 8 71 3 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 72 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 73 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2 Informative References . . . . . . . . . . . . . . . . . . . 10 76 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1 Introduction 81 To diagnose performance and connectivity problems, metrics on passive 82 traffic are critical for timely end-to-end problem resolution. Such 83 diagnostics may be real-time or after the fact, but must not impact 84 an operational production network. The base metrics are: packet 85 sequence number and packet timestamp. 87 For background, please see draft-zheng-framework-passive-01 88 [Passive]. This draft provides a foundation to this document. 90 As discussed in the above Internet Draft, passive measurement is 91 preferred for measuring end-user Quality of Experience (QoE) as well 92 as peak capacity demands. This document provides a solution for 93 obtaining such metrics. 95 As defined in RFC2460 [RFC2460], destination options are carried by 96 the IPv6 Destination Options extension header. Destination options 97 include optional information that need be examined only by the IPv6 98 node given as the destination address in the IPv6 header, not by 99 routers or other "middle boxes". This document specifies a new 100 destination option, the Performance and Diagnostic Metrics 101 destination option (PDM). 103 1.1 Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2 Performance and Diagnostic Metrics Destination Option 111 2.1 Destination Options Header 113 The IPv6 Destination Options Header is used to carry optional 114 information that need be examined only by a packet's destination 115 node(s). The Destination Options Header is identified by a Next 116 Header value of 60 in the immediately preceding header and is defined 117 in RFC2460 [RFC2460]. 119 2.2 PDM Types 121 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 122 is an implementation of the Destination Options Header (Next Header 123 value = 60). The PDM does not require time synchronization. 125 2.3 Performance and Diagnostic Metrics Destination Option 126 The Performance and Diagnostic Metrics Destination Option (PDM) 127 contains the following fields: 129 PSNTP : Packet Sequence Number This Packet 130 PSNLR : Packet Sequence Number Last Received 131 DELTALR : Delta Last Received 132 PSNLS : Packet Sequence Number Last Sent 133 DELTALS : Delta Last Sent 135 The PDM destination option is encoded in type-length-value (TLV) 136 format as follows: 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Option Type | Option Length | PSN This Packet | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | PSN Last Received | PSN Last Sent | 144 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Delta Last Received | Delta Last Sent | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | TType | 148 +-+-+-+-+ 150 Option Type 152 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 154 Option Length 156 8-bit unsigned integer. Length of the option, in octets, excluding 157 the Option Type and Option Length fields. This field MUST be set to 158 22. 160 Packet Sequence Number This Packet (PSNTP) 162 16-bit unsigned integer. This field will wrap. It is intended for 163 human use. 165 Initialized at a random number and monotonically incremented for 166 packet on the 5-tuple. The 5-tuple consists of the source and 167 destination IP addresses, the source and destination ports, and the 168 upper layer protocol (ex. TCP, ICMP, etc). 170 Operating systems MUST implement a separate packet sequence number 171 counter per 5-tuple. Operating systems MUST NOT implement a single 172 counter for all connections. 174 Note: This is consistent with the current implementation of the IPID 175 field in IPv4 for many, but not all, stacks. 177 Packet Sequence Number Last Received (PSNLR) 179 16-bit unsigned integer. This is the PSN of the packet last received 180 on the 5-tuple. 182 Packet Sequence Number Last Sent (PSNLS) 184 16-bit unsigned integer. This is the PSN of the packet last sent on 185 the 5-tuple. 187 Delta TimeStamp Type (TIMETYPE) 189 4-bit unsigned integer. This is the type of time contained in the 190 delta fields below. 192 0 - unknown 1 - time is in units of nanoseconds 2 - time is in units 193 of microseconds 3 - time is in units of milliseconds 4 - time is in 194 units of seconds 5 - time is in units of minutes 6 - time is in units 195 of hours 7 - time is in units of days 197 The values 5 - 7 are relevant for Delay Tolerant Networks (DTN) which 198 may operate with long delays between packets. 200 Delta Last Received (DELTALR) 202 A 16-bit unsigned integer field. This is server delay. 204 DELTALR = Send time packet 2 - Receive time packet 1 206 The value is according to the scale in TIMETYPE. 208 Delta Last Sent (DELTALS) 210 A 16-bit unsigned integer field. This is round trip or end-to-end 211 time. 213 Delta Last Sent = Receive time packet 2 - Send time packet 1 215 The value is in according to the scale in TIMETYPE. 217 Option Type 219 The two highest-order bits of the Option Type field are encoded to 220 indicate specific processing of the option; for the PDM destination 221 option, these two bits MUST be set to 00. This indicates the 222 following processing requirements: 224 00 - skip over this option and continue processing the header. 226 RFC2460 [RFC2460] defines other values for the Option Type field. 227 These MUST NOT be used in the PDM. The other values are as follows: 229 01 - discard the packet. 231 10 - discard the packet and, regardless of whether or not the 232 packet's Destination Address was a multicast address, send an ICMP 233 Parameter Problem, Code 2, message to the packet's Source Address, 234 pointing to the unrecognized Option Type. 236 11 - discard the packet and, only if the packet's Destination 237 Address was not a multicast address, send an ICMP Parameter Problem, 238 Code 2, message to the packet's Source Address, pointing to the 239 unrecognized Option Type. 241 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 242 Option Type specifies whether or not the Option Data of that option 243 can change en-route to the packet's final destination. 245 In the PDM, the value of the third-highest-order bit MUST be 0. The 246 possible values are as follows: 248 0 - Option Data does not change en-route 250 1 - Option Data may change en-route 252 The three high-order bits described above are to be treated as part 253 of the Option Type, not independent of the Option Type. That is, a 254 particular option is identified by a full 8-bit Option Type, not just 255 the low-order 5 bits of an Option Type. 257 2.4 Header Placement 259 The PDM destination option MUST be placed as follows: 261 - Before the upper-layer header. That is, this is the last 262 extension header. 264 This follows the order defined in RFC2460 [RFC2460] 266 IPv6 header 268 Hop-by-Hop Options header 270 Destination Options header 272 Routing header 274 Fragment header 276 Authentication header 278 Encapsulating Security Payload header 280 Destination Options header 282 upper-layer header 284 For each IPv6 packet header, the PDM MUST NOT appear more than once. 285 However, an encapsulated packet MAY contain a separate PDM associated 286 with each encapsulated IPv6 header. 288 The inclusion of a PDM in a packet affects the receiving node's 289 processing of only this single packet. No state is created or 290 modified in the receiving node as a result of receiving a PDM in a 291 packet. 293 2.5 Implementation Considerations 295 The PDM destination options extension header SHOULD be turned on by 296 each stack on a host node. 298 2.5.1 Dynamic Configuration Options 300 If implemented, each operating system MUST have a default 301 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 302 The operating system MAY also have a dynamic configuration option to 303 change the configuration setting as needed. 305 If the PDM destination options extension header is used, then it MAY 306 be turned on for all packets flowing through the host, applied to an 307 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 308 address only. These are at the discretion of the implementation. 310 The PDM MUST NOT be changed dynamically via packet flow as this may 311 create potential security violation or DoS attack by numerous packets 312 turning the header on and off. 314 As with all other destination options extension headers, the PDM is 315 for destination nodes only. As specified above, intermediate devices 316 MUST neither set nor modify this field. 318 2.5.2 Data Length Filtering 320 Different results for derived metrics, such as, server delay, will be 321 obtained if calculations are done including or excluding packets 322 which have a data length of 0 or 1. Some protocols, for example, 323 TCP, provide acknowledgements which have a length of 0. Keep-alive 324 packets have a data length of 0 or 1. 326 Operating systems may provide the user a choice of whether to include 327 or exclude packets with a 0 or 1 byte data length. 329 2.5.3 5-tuple Aging 331 Within the operating system, metrics must be kept on a 5-tuple basis. 332 As discussed before, these are: 334 PSNTP : Packet Sequence Number This Packet 335 TSTP : Timestamp This Packet 336 PSNLR : Packet Sequence Number Last Received 337 TSLR : Timestamp Last Received 338 PROTC : Protocol for Upper Layer (ex. TCP, UDP, ICMP, etc) 340 The question comes of when to stop keeping data or restarting the 341 numbering for a 5-tuple. For example, in the case of TCP, at some 342 point, the connection will terminate. Keeping data in control blocks 343 forever, will have unfortunate consequences for the operating system. 345 So, the recommendation is to use a known aging parameter such as Max 346 Segment Lifetime (MSL) as defined in Transmission Control Protocol 347 [RFC0793]. The choice of aging parameter is left up to the 348 implementation. 350 3 Backward Compatibility 352 The scheme proposed in this document is backward compatible with all 353 the currently defined IPv6 extension headers. According to RFC2460 354 [RFC2460], if the destination node does not recognize this option, it 355 should skip over this option and continue processing the header. 357 4 Security Considerations 359 The PDM MUST NOT be changed dynamically via packet flow as this 360 creates a possibility for potential security violations or DoS 361 attacks by numerous packets turning the header on and off. 363 5 IANA Considerations 365 An option type must be assigned by IANA for the Performance and 366 Diagnostic Metrics destination option. 368 6 References 370 6.1 Normative References 372 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 373 RFC 793, September 1981. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 379 (IPv6) Specification", RFC 2460, December 1998. 381 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 382 Values In the Internet Protocol and Related Headers", 383 BCP 37, RFC 2780, March 2000. 385 6.2 Informative References 387 [Passive] Zheng, V., "draft-zheng-ippm-framework-passive-01", 388 Internet Draft, July 2014. [Work in Progress] 390 7 Acknowledgments 392 The authors would like to thank Keven Haining, Sigfrido Perdomo and 393 Fred Baker for their comments. 395 Authors' Addresses 397 Nalini Elkins 398 Inside Products, Inc. 399 36A Upper Circle 400 Carmel Valley, CA 93924 401 United States 402 Phone: +1 831 659 8360 403 Email: nalini.elkins@insidethestack.com 404 http://www.insidethestack.com 406 William Jouris 407 Inside Products, Inc. 408 36A Upper Circle 409 Carmel Valley, CA 93924 410 United States 411 Phone: +1 925 855 9512 412 Email: bill.jouris@insidethestack.com 413 http://www.insidethestack.com 415 Michael S. Ackermann 416 Blue Cross Blue Shield of Michigan 417 P.O. Box 2888 418 Detroit, Michigan 48231 419 United States 420 Phone: +1 310 460 4080 421 Email: mackermann@bcbsmi.com 422 http://www.bcbsmi.com