idnits 2.17.1 draft-morton-ippm-2330-stdform-typep-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2330, but the abstract doesn't seem to directly say this. It does mention RFC2330 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2330, updated by this document, for RFC5378 checks: 1998-05-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2015) is 3123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Updates: 2330 (if approved) J. Fabini 5 Intended status: Informational TU Wien 6 Expires: April 3, 2016 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 October 1, 2015 14 Updates for IPPM's Active Metric Framework: Packets of Type-P and 15 Standard-Formed Packets 16 draft-morton-ippm-2330-stdform-typep-01 18 Abstract 20 This memo updates the IP Performance Metrics (IPPM) Framework RFC 21 2330 with new considerations for measurement methodology and testing. 22 The memo updates the definition of standard-formed packets in RFC 23 2330 to include IPv6 packets. It also augments distinguishing 24 aspects of packets, referred to as Type-P for test packets in RFC 25 2330. 27 Two points (at least) are worthwhile discussing further: extent of 28 coverage for 6LO and IPv6 Header Compression, and the continued need 29 to define a "minimal standard-formed packet". 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 3, 2016. 54 Copyright Notice 56 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 74 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 75 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The IETF IP Performance Metrics (IPPM) working group first created a 87 framework for metric development in [RFC2330]. This framework has 88 stood the test of time and enabled development of many fundamental 89 metrics. It has been updated in the area of metric composition 90 [RFC5835], and in several areas related to active stream measurement 91 of modern networks with reactive properties [RFC7312]. 93 The IPPM framework [RFC2330] recognized (in section 13) that many 94 aspects of IP packets can influence its processing during transfer 95 across the network. 97 In Section 15 of [RFC2330], the notion of a "standard-formed" packet 98 is defined. However, the definition was never updated to include 99 IPv6, as the original authors planned. 101 In particular, IPv6 Extension Headers and protocols which use IPv6 102 header compression are growing in use. This memo seeks to provide 103 the needed updates. 105 2. Scope 107 The purpose of this memo is to expand the coverage of IPPM metrics to 108 include IPv6, and to highlight additional aspects of test packets and 109 make them part of the IPPM performance metric framework. 111 The scope is to update key sections of [RFC2330], adding 112 considerations that will aid the development of new measurement 113 methodologies intended for today's IP networks. Specifically, this 114 memo expands the Type-P examples in section 13 of [RFC2330] and 115 expands the definition (in section 15 of [RFC2330]) of a standard- 116 formed packet to include IPv6 header aspects and other features. 118 Other topics in [RFC2330] which might be updated or augmented are 119 deferred to future work. This includes the topics of passive and 120 various forms of hybrid active/passive measurements. 122 3. Packets of Type-P 124 A fundamental property of many Internet metrics is that the measured 125 value of the metric depends on characteristics of the IP packet(s) 126 used to make the measurement. Potential influencing factors include 127 IP header fields and their values, but also higher-layer protocol 128 headers and their values. Consider an IP-connectivity metric: one 129 obtains different results depending on whether one is interested in 130 connectivity for packets destined for well-known TCP ports or 131 unreserved UDP ports, or those with invalid IPv4 checksums, or those 132 with TTL or Hop Limit of 16, for example. In some circumstances 133 these distinctions will result in special treatment of packets in 134 intermediate nodes and end systems (for example, if Diffserv 135 [RFC2780], ECN [RFC3168], Router Alert, Hop-by-hop extensions 136 [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of 137 firewalls or RSVP reservations). 139 Because of this distinction, we introduce the generic notion of a 140 "packet of Type-P", where in some contexts P will be explicitly 141 defined (i.e., exactly what type of packet we mean), partially 142 defined (e.g., "with a payload of B octets"), or left generic. Thus 143 we may talk about generic IP-Type-P-connectivity or more specific IP- 144 port-HTTP-connectivity. Some metrics and methodologies may be 145 fruitfully defined using generic Type-P definitions which are then 146 made specific when performing actual measurements. 148 Whenever a metric's value depends on the type of the packets involved 149 in the metric, the metric's name will include either a specific type 150 or a phrase such as "Type-P". Thus we will not define an "IP- 151 connectivity" metric but instead an "IP-Type-P-connectivity" metric 152 and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming 153 convention serves as an important reminder that one must be conscious 154 of the exact type of traffic being measured. 156 If the information constituting Type-P at the Source is found to have 157 changed at the Destination (or at a measurement point between the 158 Source and Destination, as in [RFC5644]), then the modified values 159 SHOULD be noted and reported with the results. Some modifications 160 occur according to the conditions encountered in transit (such as 161 congestion notification) or due to the requirements of segments of 162 the Source to Destination path. For example, the packet length will 163 change if IP headers are converted to the alternate version/address 164 family, or if optional Extension Headers are added or removed. Local 165 policies in intermediate nodes based on examination of IPv6 Extension 166 Headers may affect measurement repeatability. If intermediate nodes 167 follow the recommendations of [RFC7045], repeatability may be 168 improved to some degree. 170 A Network Address Translator (NAT) on the path can have unpredictable 171 impact on latency measurement (in terms of the amount of additional 172 time added), and possibly other types of measurements. It is not 173 usually possible to control this impact (as testers may not have any 174 control of the underlying network or middleboxes). There is a 175 possibility that stateful NAT will lead to unstable performance for a 176 flow with specific Type-P, since state needs to be created for the 177 first packet of a flow, and state may be lost later if the NAT runs 178 out of resources. However, this scenario does not invalidate the 179 Type-P for testing. The presence of NAT may mean that the measured 180 performance of Type-P will change between the source and the 181 destination. This can cause an issue when attempting to correlate 182 measurements conducted on segments of the path that include or 183 exclude the NAT. Thus, it is a factor to be aware of when conducting 184 measurements. 186 A closely related note: it would be very useful to know if a given 187 Internet component (like host, link, or path) treats equally a class 188 C of different types of packets. If so, then any one of those types 189 of packets can be used for subsequent measurement of the component. 190 This suggests we devise a metric or suite of metrics that attempt to 191 determine C. 193 4. Standard-Formed Packets 195 Unless otherwise stated, all metric definitions that concern IP 196 packets include an implicit assumption that the packet is *standard- 197 formed*. A packet is standard-formed if it meets all of the following 198 criteria: 200 + It includes a valid IP header: see below for version-specific 201 criteria. 203 + It is not an IP fragment. 205 + The Source and Destination addresses correspond to the intended 206 Source and Destination, including Multicast Destination addresses. 208 + If a transport header is present, it contains a valid checksum and 209 other valid fields. 211 For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, 212 the following additional criteria are required: 214 o The version field is 4 216 o The Internet Header Length (IHL) value is >= 5; the checksum is 217 correct. 219 o Its total length as given in the IPv4 header corresponds to the 220 size of the IPv4 header plus the size of the payload. 222 o Either the packet possesses sufficient TTL to travel from the 223 Source to the Destination if the TTL is decremented by one at each 224 hop, or it possesses the maximum TTL of 255. 226 o It does not contain IP options unless explicitly noted. 228 For an IPv6 ([RFC2460] and updates) packet to be standard-formed, the 229 following criteria are required: 231 o The version field is 6. 233 o Its total length corresponds to the size of the IPv6 header (40 234 octets) plus the length of the payload (including Extension 235 Headers) as given in the IPv6 header. 237 o Either the packet possesses sufficient Hop Count to travel from 238 the Source to the Destination if the Hop Count is decremented by 239 one at each hop, or it possesses the maximum Hop Count of 255. 241 o Either the packet does not contain IP Extension Headers, or it 242 contains the correct number and type of headers as specified in 243 the packet, and the headers appear in the standard-conforming 244 order (Next Header). 246 o All parameters used in the header and Extension Headers are found 247 in the IANA Registry of Internet Protocol Version 6 (IPv6) 248 Parameters, partly specified in [RFC7045]. 250 Compressed IPv6 headers must be compliant with [RFC4494], as updated 251 by [RFC6282], in order to be declared "standard-formed". 253 The topic of IPv6 Extension Headers brings current controversies into 254 focus as noted by [RFC6564] and [RFC7045]. The following additional 255 considerations apply when IPv6 Extension Headers are present: 257 o Extension Header inspection: Some intermediate nodes may inspect 258 Extension Headers or the entire IPv6 packet while in transit. In 259 exceptional cases, they may drop the packet or route via a sub- 260 optimal path, and measurements may be unreliable or unrepeatable. 261 The packet (if it arrives) may be standard-formed, with a 262 corresponding Type-P. 264 o Extension Header modification: In Hop-by-Hop headers, some TLV 265 encoded options may be permitted to change at intermediate nodes 266 while in transit. The resulting packet may be standard-formed, 267 with a corresponding Type-P. 269 o Extension Header insertion or deletion: It is possible that 270 Extension Headers could be added to, or removed from the header 271 chain. The resulting packet may be standard-formed, with a 272 corresponding Type-P. 274 o A change in packet length (from the corresponding packet observed 275 at the Source) or header modification is a significant factor in 276 Internet measurement, and requires a new Type-P to be reported. 278 We further require that if a packet is described as having a "length 279 of B octets", then 0 <= B <= 65535; and if B is the payload length in 280 octets, then B <= (65535-IP header size in octets, including any 281 Extension Headers). The jumbograms defined in [RFC2675] are not 282 covered by this length analysis. In practice, the path MTU will 283 restrict the length of standard-formed packets that can successfully 284 traverse the path. 286 So, for example, one might imagine defining an IP connectivity metric 287 as "IP-type-P-connectivity for standard-formed packets with the IP 288 Diffserv field set to 0", or, more succinctly, "IP-type- 289 P-connectivity with the IP Diffserv Field set to 0", since standard- 290 formed is already implied by convention. Changing the contents of a 291 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 292 have a profound affect on packet handling during transit, but does 293 not affect a packet's status as standard-formed. 295 A particular type of standard-formed packet often useful to consider 296 is the "minimal IP packet from A to B" - this is an IP packet with 297 the following properties: 299 + It is standard-formed. 301 + Its data payload is 0 octets. 303 + It contains no options or Extension Headers. 305 (Note that we do not define its protocol field, as different values 306 may lead to different treatment by the network.) 308 When defining IP metrics we keep in mind that no packet smaller or 309 simpler than this can be transmitted over a correctly operating IP 310 network. 312 5. Conclusions 314 This memo adds the key considerations for utilizing IPv6 in two 315 critical conventions of the IPPM Framework. It is RECOMMENDED to 316 adopt these new considerations in measurements involving IPv6. 318 6. Security Considerations 320 The security considerations that apply to any active measurement of 321 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 323 When considering privacy of those involved in measurement or those 324 whose traffic is measured, the sensitive information available to 325 potential observers is greatly reduced when using active techniques 326 which are within this scope of work. Passive observations of user 327 traffic for measurement purposes raise many privacy issues. We refer 328 the reader to the privacy considerations described in the Large Scale 329 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 330 which covers active and passive techniques. 332 7. IANA Considerations 334 This memo makes no requests of IANA. 336 8. Acknowledgements 338 The authors thank Brian Carpenter for identifying the lack of IPv6 339 coverage in IPPM's Framework, and for listing additional 340 distinguishing factors for packets of Type-P. Both Brian and Fred 341 Baker discussed many of the interesting aspects of IPv6 with the co- 342 authors, leading to a more solid first draft: thank you both. Thanks 343 to Bill Jouris for an editorial pass through the pre-00 text. 345 9. References 347 9.1. Normative References 349 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 350 DOI 10.17487/RFC0791, September 1981, 351 . 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 359 "Framework for IP Performance Metrics", RFC 2330, 360 DOI 10.17487/RFC2330, May 1998, 361 . 363 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 364 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 365 December 1998, . 367 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 368 RFC 2675, DOI 10.17487/RFC2675, August 1999, 369 . 371 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 372 Values In the Internet Protocol and Related Headers", 373 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 374 . 376 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 377 of Explicit Congestion Notification (ECN) to IP", 378 RFC 3168, DOI 10.17487/RFC3168, September 2001, 379 . 381 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 382 Algorithm and Its Use with IPsec", RFC 4494, 383 DOI 10.17487/RFC4494, June 2006, 384 . 386 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 387 Zekauskas, "A One-way Active Measurement Protocol 388 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 389 . 391 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 392 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 393 RFC 5357, DOI 10.17487/RFC5357, October 2008, 394 . 396 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 397 Metrics (IPPM): Spatial and Multicast", RFC 5644, 398 DOI 10.17487/RFC5644, October 2009, 399 . 401 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 402 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 403 2010, . 405 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 406 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 407 DOI 10.17487/RFC6282, September 2011, 408 . 410 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 411 "IPv6 Flow Label Specification", RFC 6437, 412 DOI 10.17487/RFC6437, November 2011, 413 . 415 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 416 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 417 RFC 6564, DOI 10.17487/RFC6564, April 2012, 418 . 420 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 421 of IPv6 Extension Headers", RFC 7045, 422 DOI 10.17487/RFC7045, December 2013, 423 . 425 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 426 Framework for IP Performance Metrics (IPPM)", RFC 7312, 427 DOI 10.17487/RFC7312, August 2014, 428 . 430 9.2. Informative References 432 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 433 Aitken, P., and A. Akhter, "A Framework for Large-Scale 434 Measurement of Broadband Performance (LMAP)", RFC 7594, 435 DOI 10.17487/RFC7594, September 2015, 436 . 438 Authors' Addresses 440 Al Morton 441 AT&T Labs 442 200 Laurel Avenue South 443 Middletown, NJ 07748 444 USA 446 Phone: +1 732 420 1571 447 Fax: +1 732 368 1192 448 Email: acmorton@att.com 449 URI: http://home.comcast.net/~acmacm/ 451 Joachim Fabini 452 TU Wien 453 Gusshausstrasse 25/E389 454 Vienna 1040 455 Austria 457 Phone: +43 1 58801 38813 458 Fax: +43 1 58801 38898 459 Email: Joachim.Fabini@tuwien.ac.at 460 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 462 Nalini Elkins 463 Inside Products, Inc. 464 Carmel Valley, CA 93924 465 USA 467 Email: nalini.elkins@insidethestack.com 469 Michael S. Ackermann 470 Blue Cross Blue Shield of Michigan 472 Email: mackermann@bcbsmi.com 473 Vinayak Hegde 474 Consultant 475 Brahma Sun City, Wadgaon-Sheri 476 Pune, Maharashtra 411014 477 INDIA 479 Phone: +91 9449834401 480 Email: vinayakh@gmail.com 481 URI: http://www.vinayakhegde.com