idnits 2.17.1 draft-elkins-6man-ipv6-pdm-dest-option-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3911 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. 'PSNELK' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSPELK' -- Possible downref: Non-RFC (?) normative reference: ref. 'USEELK' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Inside Products 4 M. Ackermann 5 BCBS Michigan 6 K. Haining 7 U.S. Bank 8 S. Perdomo 9 DTCC 10 W. Jouris 11 Inside Products 12 D. Boyes 13 Sine Nomine 14 Expires: January 2014 July 14, 2013 16 IPv6 Performance and Diagnostic Metrics Destination Option 17 draft-elkins-6man-ipv6-pdm-dest-option-01 19 Abstract 21 To diagnose problems for a number of Enterprise Data Center Operators 22 (EDCO), two metrics are critical for timely end-to-end problem 23 resolution, both real-time and after the fact, without impacting an 24 operational production network. They are: packet sequence number and 25 packet timestamp. Packet sequence number is required for diagnostics. 26 Packet timestamp is required to calculate end-to-end response time. 27 Current methods are inadequate for these purposes because they assume 28 unreasonable access to intermediate devices, are cost prohibitive, 29 require infeasible changes to a running production network, and / or 30 do not provide timely data. This document solves these problems with 31 a new destination option, the Performance and Diagnostic Metrics 32 destination option (PDM). 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as 42 Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2 Performance and Diagnostic Metrics Destination Option . . . . . 3 74 2.1 Destination Options Header . . . . . . . . . . . . . . . . 3 75 2.2 Performance and Diagnostic Metrics Destination Option . . . 4 76 2.3 Implementation Considerations . . . . . . . . . . . . . . . 7 77 3 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 78 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 79 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 80 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 82 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 83 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1 Introduction 88 To diagnose problems for a number of Enterprise Data Center Operators 89 (EDCO), two metrics are critical for timely end-to-end problem 90 resolution, both real-time and after the fact, without impacting an 91 operational production network. They are: packet sequence number and 92 packet timestamp. Packet sequence number is required for diagnostics. 93 Packet timestamp is required to calculate end-to-end response time. 95 For background, please see Draft-Elkins-Packet-Sequence-Number- 96 Needed-00 [PSNELK], Draft-Elkins-End-To-End-Response-Time-00 97 [RSPELK], and Draft-Elkins-PDM-Recommended-Usage-00 [USEELK]. These 98 drafts are companion documents to this document. All three documents 99 should be read together. 101 As discussed in the above Internet Drafts, current methods are 102 inadequate for these purposes because they assume unreasonable access 103 to intermediate devices, are cost prohibitive, require infeasible 104 changes to a running production network, and / or do not provide 105 timely data. This document provides a solution for these problems. 107 As defined in RFC2460 [RFC2460], destination options are carried by 108 the IPv6 Destination Options extension header. Destination options 109 include optional information that need be examined only by the IPv6 110 node given as the destination address in the IPv6 header, not by 111 routers in between. This document detail the specifications for a 112 new destination option, the Performance and Diagnostic Metrics 113 destination option (PDM). 115 1.1 Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2 Performance and Diagnostic Metrics Destination Option 123 2.1 Destination Options Header 125 The IPv6 Destination Options Header is used to carry optional 126 information that need be examined only by a packet's destination 127 node(s). The Destination Options Header is identified by a Next 128 Header value of 60 in the immediately preceding header and is defined 129 in RFC2460 [RFC2460]. 131 2.2 Performance and Diagnostic Metrics Destination Option 133 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 134 is an implementation of the Destination Options Header (Next Header 135 value = 60). 137 It is used to facilitate diagnostics by including a packet sequence 138 number and timestamp. 140 The PDM destination option is encoded in type-length-value (TLV) 141 format as follows: 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Option Type | Option Length | Packet Sequence Number | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 + + 150 | | 151 + TimeStamp This Packet (64-bit) + 152 | | 153 + + 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 + + 158 | | 159 + TimeStamp Last Packet (64-bit) + 160 | | 161 + + 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 + + 166 | | 167 + Application Specific + 168 | | 169 + + 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Option Type 175 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 176 Option Length 178 8-bit unsigned integer. Length of the option, in octets, excluding 179 the Option Type and Option Length fields. This field MUST be set to 180 88. 182 Packet Sequence Number 184 16-bit unsigned integer. This field will wrap. It is intended for 185 human use. 187 Initialized at 0 and monotonically incremented for protocol packet on 188 the CONNECTION. 190 Operating systems MUST implement a separate packet sequence number 191 counter per connection. Operating systems MUST NOT implement a single 192 counter for all connections. 194 Note: This is consistent with the current implementation of the IPID 195 field in IPv4 for many, but not all, stacks. 197 TimeStamp This Packet 199 A 64-bit unsigned integer field containing a timestamp that this 200 packet was sent by the source node. The value indicates the number 201 of seconds since January 1, 1970, 00:00 UTC, by using a fixed point 202 format. In this format, the integer number of seconds is contained 203 in the first 32 bits of the field, and the remaining 32 bits resolve 204 to picoseconds. 206 This follows timestamp formats used in Network Time Protocol (NTP) 207 [RFC5905] and SEND [RFC3971]. A discussion of why NTP is used in 208 preference to Precision Time Protocol (PTP) is in Draft-Elkins-End- 209 To-End-Response-Time-00.txt. 211 Implementation note: This format is compatible with the usual 212 representation of time under UNIX, although the number of bits 213 available for the integer and fraction parts in different Unix 214 implementations vary. 216 TimeStamp Last Packet 218 A 64-bit unsigned integer field containing a timestamp that the last 219 packet on this connection was received. The value indicates the 220 number of seconds since January 1, 1970, 00:00 UTC, by using a fixed 221 point format. In this format, the integer number of seconds is 222 contained in the first 32 bits of the field, and the remaining 32 223 bits resolve to picoseconds. 225 This follows timestamp formats used in Network Time Protocol (NTP) 226 [RFC5905] and SEND [RFC3971]. 228 Application Reserved 230 A 64-bit field reserved for performance and diagnostic metrics to be 231 used by end nodes. The meaning is agreed upon by the source and 232 destination nodes. 234 Option Type 236 The two highest-order bits of the Option Type field are encoded to 237 indicate specific processing of the option; for the PDM destination 238 option, these two bits MUST be set to 00. This indicates the 239 following processing requirements: 241 00 - skip over this option and continue processing the header. 243 RFC2460 [RFC2460] defines other values for the Option Type field. 244 These MUST NOT be used in the PDM. The other values are as follows: 246 01 - discard the packet. 248 10 - discard the packet and, regardless of whether or not the 249 packet's Destination Address was a multicast address, send an ICMP 250 Parameter Problem, Code 2, message to the packet's Source Address, 251 pointing to the unrecognized Option Type. 253 11 - discard the packet and, only if the packet's Destination 254 Address was not a multicast address, send an ICMP Parameter Problem, 255 Code 2, message to the packet's Source Address, pointing to the 256 unrecognized Option Type. 258 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 259 Option Type specifies whether or not the Option Data of that option 260 can change en-route to the packet's final destination. 262 In the PDM, the value of the third-highest-order bit MUST be 0. The 263 possible values are as follows: 265 0 - Option Data does not change en-route 267 1 - Option Data may change en-route 269 The three high-order bits described above are to be treated as part 270 of the Option Type, not independent of the Option Type. That is, a 271 particular option is identified by a full 8-bit Option Type, not just 272 the low-order 5 bits of an Option Type. 274 Header Placement 276 The PDM destination option MUST be placed as follows: 278 - Before the upper-layer header. That is, this is the last 279 extension header. 281 This follows the order defined in RFC2460 [RFC2460] 283 IPv6 header 285 Hop-by-Hop Options header 287 Destination Options header 289 Routing header 291 Fragment header 293 Authentication header 295 Encapsulating Security Payload header 297 Destination Options header 299 upper-layer header 301 For each IPv6 packet header, the PDM MUST NOT appear more than once. 302 However, an encapsulated packet MAY contain a separate PDM associated 303 with each encapsulated IPv6 header. 305 The inclusion of a PDM in a packet affects the receiving node's 306 processing of only this single packet. No state is created or 307 modified in the receiving node as a result of receiving a PDM in a 308 packet. 310 2.3 Implementation Considerations 311 The PDM destination options extension header SHOULD be turned on by 312 each stack on a host node. 314 If implemented, each operating system MUST have a default 315 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 316 The operating system MAY also have a dynamic configuration option to 317 change the configuration setting as needed. 319 If the PDM destination options extension header is used, then it MAY 320 be turned on for all packets flowing through the host, applied to an 321 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 322 address only. These are at the discretion of the implementation. 324 The PDM MUST NOT be changed dynamically via packet flow as this may 325 create potential security violation or DoS attack by numerous packets 326 turning the header on and off. 328 As with all other destination options extension headers, the PDM is 329 for destination nodes only. As specified above, intermediate devices 330 MUST neither set nor modify this field. 332 3 Backward Compatibility 334 The scheme proposed in this document is backward compatible with all 335 the currently defined IPv6 extension headers. According to RFC2460 336 [RFC2460], if the destination node does not recognize this option, it 337 should skip over this option and continue processing the header. 339 4 Security Considerations 341 The PDM MUST NOT be changed dynamically via packet flow as this 342 creates a possibility for potential security violations or DoS 343 attacks by numerous packets turning the header on and off. 345 5 IANA Considerations 347 An option type must be assigned by IANA for the Performance and 348 Diagnostic Metrics destination option. 350 6 References 352 6.1 Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 358 (IPv6) Specification", RFC 2460, December 1998. 360 [PSNELK] Elkins, N., "Draft-Elkins-Packet-Sequence-Number-Needed- 361 00", Internet Draft, May 2013. 363 [RSPELK] Elkins, N., "Draft-Elkins-End-To-End-Response-Time-00", 365 [USEELK] Elkins, N., "Draft-Elkins-PDM-Recommended-Usage-00", 367 6.2 Informative References 369 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 370 Values In the Internet Protocol and Related Headers", 371 BCP 37, RFC 2780, March 2000. 373 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 374 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 376 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 377 "Network Time Protocol Version 4: Protocol and Algorithms 378 Specification", RFC 5905, June 2010. 380 7 Acknowledgments 382 The authors would like to thank Rick Troth, Neil Wasserman and Fred Baker 383 for their comments. 385 Authors' Addresses 387 Nalini Elkins 388 Inside Products, Inc. 389 36A Upper Circle 390 Carmel Valley, CA 93924 391 United States 392 Phone: +1 831 659 8360 393 Email: nalini.elkins@insidethestack.com 394 http://www.insidethestack.com 396 Michael S. Ackermann 397 Blue Cross Blue Shield of Michigan 398 P.O. Box 2888 399 Detroit, Michigan 48231 400 United States 401 Phone: +1 310 460 4080 402 Email: mackermann@bcbsmi.com 403 http://www.bcbsmi.com 405 Keven Haining 406 US Bank 407 16900 W Capitol Drive 408 Brookfield, WI 53005 409 United States 410 Phone: +1 262 790 3551 411 Email: keven.haining@usbank.com 412 http://www.usbank.com 414 Sigfrido Perdomo 415 Depository Trust and Clearing Corporation 416 55 Water Street 417 New York, NY 10055 418 United States 419 Phone: +1 917 842 7375 420 Email: s.perdomo@dtcc.com 421 http://www.dtcc.com 423 William Jouris 424 Inside Products, Inc. 425 36A Upper Circle 426 Carmel Valley, CA 93924 427 United States 428 Phone: +1 925 855 9512 429 Email: bill.jouris@insidethestack.com 430 http://www.insidethestack.com 432 David Boyes 433 Sine Nomine Associates 434 43596 Blacksmith Square 435 Ashburn, VA 20147 436 United States 437 Phone: +1 703 723 6673 438 dboyes@sinenomine.net 439 http://www.sinenomine.net