idnits 2.17.00 (12 Aug 2021) /tmp/idnits42264/draft-morton-ippm-2330-stdform-typep-00.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 (August 6, 2015) is 2479 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: draft-ietf-lmap-framework has been published as RFC 7594 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: February 7, 2016 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 August 6, 2015 13 Updates for IPPM's Active Metric Framework: Packets of Type-P and 14 Standard-Formed Packets 15 draft-morton-ippm-2330-stdform-typep-00 17 Abstract 19 This memo updates the IP Performance Metrics (IPPM) Framework RFC 20 2330 with new considerations for measurement methodology and testing. 21 The memo updates the definition of standard-formed packets in RFC 22 2330 to include IPv6 packets. It also augments distinguishing 23 aspects of packets, referred to as Type-P for test packets in RFC 24 2330. 26 Two points (at least) are worthwhile discussing further: extent of 27 coverage for 6LO and IPv6 Header Compression, and the continued need 28 to define a "minimal standard-formed packet". 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 7, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 73 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 4 74 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 9.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The IETF IP Performance Metrics (IPPM) working group first created a 86 framework for metric development in [RFC2330]. This framework has 87 stood the test of time and enabled development of many fundamental 88 metrics. It has been updated in the area of metric composition 89 [RFC5835], and in several areas related to active stream measurement 90 of modern networks with reactive properties [RFC7312]. 92 The IPPM framework [RFC2330] recognized (in section 13) that many 93 aspects of IP packets can influence its processing during transfer 94 across the network. 96 In Section 15 of [RFC2330], the notion of a "standard-formed" packet 97 is defined. However, the definition was never updated to include 98 IPv6, as the original authors planned. 100 In particular, IPv6 Extension Headers and protocols which use IPv6 101 header compression are growing in use. This memo seeks to provide 102 the needed updates. 104 2. Scope 106 The purpose of this memo is to expand the coverage of IPPM metrics to 107 include IPv6, and to highlight additional aspects of test packets and 108 make them part of the IPPM performance metric framework. 110 The scope is to update key sections of [RFC2330], adding 111 considerations that will aid the development of new measurement 112 methodologies intended for today's IP networks. Specifically, this 113 memo expands the Type-P examples in section 13 of [RFC2330] and 114 expands the definition (in section 15 of [RFC2330]) of a standard- 115 formed packet to include IPv6 header aspects and other features. 117 Other topics in [RFC2330] which might be updated or augmented are 118 deferred to future work. This includes the topics of passive and 119 various forms of hybrid active/passive measurements. 121 3. Packets of Type-P 123 A fundamental property of many Internet metrics is that the measured 124 value of the metric depends on characteristics of the IP packet(s) 125 used to make the measurement. Potential influencing factors include 126 IP header fields and their values, but also higher-layer protocol 127 headers and their values. Consider an IP-connectivity metric: one 128 obtains different results depending on whether one is interested in 129 connectivity for packets destined for well-known TCP ports or 130 unreserved UDP ports, or those with invalid IPv4 checksums, or those 131 with TTL or Hop Limit of 16, for example. In some circumstances 132 these distinctions will result in special treatment of packets in 133 intermediate nodes and end systems (for example, if Diffserv 134 [RFC2780], ECN [RFC3168], Router Alert, Hop-by-hop extensions 135 [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of 136 firewalls or RSVP reservations). 138 Because of this distinction, we introduce the generic notion of a 139 "packet of Type-P", where in some contexts P will be explicitly 140 defined (i.e., exactly what type of packet we mean), partially 141 defined (e.g., "with a payload of B octets"), or left generic. Thus 142 we may talk about generic IP-Type-P-connectivity or more specific IP- 143 port-HTTP-connectivity. Some metrics and methodologies may be 144 fruitfully defined using generic Type-P definitions which are then 145 made specific when performing actual measurements. 147 Whenever a metric's value depends on the type of the packets involved 148 in the metric, the metric's name will include either a specific type 149 or a phrase such as "Type-P". Thus we will not define an "IP- 150 connectivity" metric but instead an "IP-Type-P-connectivity" metric 151 and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming 152 convention serves as an important reminder that one must be conscious 153 of the exact type of traffic being measured. 155 If the information constituting Type-P at the Source is found to have 156 changed at the Destination (or at a measurement point between the 157 Source and Destination, as in [RFC5644]), then the modified values 158 SHOULD be noted and reported with the results. Some modifications 159 occur according to the conditions encountered in transit (such as 160 congestion notification) or due to the requirements of segments of 161 the Source to Destination path. For example, the packet length will 162 change if IP headers are converted to the alternate version/address 163 family, or if optional Extension Headers are added or removed. Local 164 policies in intermediate nodes based on examination of IPv6 Extension 165 Headers may affect measurement repeatability. If intermediate nodes 166 follow the recommendations of [RFC7045], repeatability may be 167 improved to some degree. 169 A closely related note: it would be very useful to know if a given 170 Internet component treats equally a class C of different types of 171 packets. If so, then any one of those types of packets can be used 172 for subsequent measurement of the component. This suggests we devise 173 a metric or suite of metrics that attempt to determine C. 175 4. Standard-Formed Packets 177 Unless otherwise stated, all metric definitions that concern IP 178 packets include an implicit assumption that the packet is *standard- 179 formed*. A packet is standard-formed if it meets all of the following 180 criteria: 182 + It includes a valid IP header: see below for version-specific 183 criteria. 185 + It is not an IP fragment. 187 + The Source and Destination addresses correspond to the intended 188 Source and Destination, including Multicast Destination addresses. 190 + If a transport header is present, it contains a valid checksum and 191 other valid fields. 193 For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, 194 the following additional criteria are required: 196 o The version field is 4 198 o The Internet Header Length (IHL) value is >= 5; the checksum is 199 correct. 201 o Its total length as given in the IPv4 header corresponds to the 202 size of the IPv4 header plus the size of the payload. 204 o Either the packet possesses sufficient TTL to travel from the 205 Source to the Destination if the TTL is decremented by one at each 206 hop, or it possesses the maximum TTL of 255. 208 o It does not contain IP options unless explicitly noted. 210 For an IPv6 ([RFC2460] and updates) packet to be standard-formed, the 211 following criteria are required: 213 o The version field is 6. 215 o Its total length corresponds to the size of the IPv6 header (40 216 octets) plus the length of the payload (including Extension 217 Headers) as given in the IPv6 header. 219 o Either the packet possesses sufficient Hop Count to travel from 220 the Source to the Destination if the Hop Count is decremented by 221 one at each hop, or it possesses the maximum Hop Count of 255. 223 o Either the packet does not contain IP Extension Headers, or it 224 contains the correct number and type of headers as specified in 225 the packet, and the headers appear in the standard-conforming 226 order (Next Header). 228 o All parameters used in the header and Extension Headers are found 229 in the IANA Registry of Internet Protocol Version 6 (IPv6) 230 Parameters, partly specified in [RFC7045]. 232 Compressed IPv6 headers must be compliant with [RFC4494], as updated 233 by [RFC6282], in order to be declared "standard-formed". 235 The topic of IPv6 Extension Headers brings current controversies into 236 focus as noted by [RFC6564] and [RFC7045]. The following additional 237 considerations apply when IPv6 Extension Headers are present: 239 o Extension Header inspection: Some intermediate nodes may inspect 240 Extension Headers or the entire IPv6 packet while in transit. In 241 exceptional cases, they may drop the packet or route via a sub- 242 optimal path, and measurements may be unreliable or unrepeatable. 243 The packet (if it arrives) may be standard-formed, with a 244 corresponding Type-P. 246 o Extension Header modification: In Hop-by-Hop headers, some TLV 247 encoded options may be permitted to change at intermediate nodes 248 while in transit. The resulting packet may be standard-formed, 249 with a corresponding Type-P. 251 o Extension Header insertion or deletion: It is possible that 252 Extension Headers could be added to, or removed from the header 253 chain. The resulting packet may be standard-formed, with a 254 corresponding Type-P. 256 o A change in packet length (from the corresponding packet observed 257 at the Source) or header modification is a significant factor in 258 Internet measurement, and requires a new Type-P to be reported. 260 We further require that if a packet is described as having a "length 261 of B octets", then 0 <= B <= 65535; and if B is the payload length in 262 octets, then B <= (65535-IP header size in octets, including any 263 Extension Headers). The jumbograms defined in [RFC2675] are not 264 covered by this length analysis. In practice, the path MTU will 265 restrict the length of standard-formed packets that can successfully 266 traverse the path. 268 So, for example, one might imagine defining an IP connectivity metric 269 as "IP-type-P-connectivity for standard-formed packets with the IP 270 Diffserv field set to 0", or, more succinctly, "IP-type- 271 P-connectivity with the IP Diffserv Field set to 0", since standard- 272 formed is already implied by convention. Changing the contents of a 273 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 274 have a profound affect on packet handling during transit, but does 275 not affect a packet's status as standard-formed. 277 A particular type of standard-formed packet often useful to consider 278 is the "minimal IP packet from A to B" - this is an IP packet with 279 the following properties: 281 + It is standard-formed. 283 + Its data payload is 0 octets. 285 + It contains no options or Extension Headers. 287 (Note that we do not define its protocol field, as different values 288 may lead to different treatment by the network.) 289 When defining IP metrics we keep in mind that no packet smaller or 290 simpler than this can be transmitted over a correctly operating IP 291 network. 293 5. Conclusions 295 This memo adds the key considerations for utilizing IPv6 in two 296 critical conventions of the IPPM Framework. It is RECOMMENDED to 297 adopt these new considerations in measurements involving IPv6. 299 6. Security Considerations 301 The security considerations that apply to any active measurement of 302 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 304 When considering privacy of those involved in measurement or those 305 whose traffic is measured, the sensitive information available to 306 potential observers is greatly reduced when using active techniques 307 which are within this scope of work. Passive observations of user 308 traffic for measurement purposes raise many privacy issues. We refer 309 the reader to the privacy considerations described in the Large Scale 310 Measurement of Broadband Performance (LMAP) Framework 311 [I-D.ietf-lmap-framework], which covers active and passive 312 techniques. 314 7. IANA Considerations 316 This memo makes no requests of IANA. 318 8. Acknowledgements 320 The authors thank Brian Carpenter for identifying the lack of IPv6 321 coverage in IPPM's Framework, and for listing additional 322 distinguishing factors for packets of Type-P. Both Brian and Fred 323 Baker discussed many of the interesting aspects of IPv6 with the co- 324 authors, leading to a more solid first draft: thank you both. Thanks 325 to Bill Jouris for an editorial pass through the pre-00 text. 327 9. References 329 9.1. Normative References 331 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 332 DOI 10.17487/RFC0791, September 1981, 333 . 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 341 "Framework for IP Performance Metrics", RFC 2330, 342 DOI 10.17487/RFC2330, May 1998, 343 . 345 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 346 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 347 December 1998, . 349 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 350 RFC 2675, DOI 10.17487/RFC2675, August 1999, 351 . 353 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 354 Values In the Internet Protocol and Related Headers", 355 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 356 . 358 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 359 of Explicit Congestion Notification (ECN) to IP", 360 RFC 3168, DOI 10.17487/RFC3168, September 2001, 361 . 363 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 364 Algorithm and Its Use with IPsec", RFC 4494, 365 DOI 10.17487/RFC4494, June 2006, 366 . 368 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 369 Zekauskas, "A One-way Active Measurement Protocol 370 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 371 . 373 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 374 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 375 RFC 5357, DOI 10.17487/RFC5357, October 2008, 376 . 378 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 379 Metrics (IPPM): Spatial and Multicast", RFC 5644, 380 DOI 10.17487/RFC5644, October 2009, 381 . 383 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 384 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 385 2010, . 387 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 388 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 389 DOI 10.17487/RFC6282, September 2011, 390 . 392 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 393 "IPv6 Flow Label Specification", RFC 6437, 394 DOI 10.17487/RFC6437, November 2011, 395 . 397 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 398 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 399 RFC 6564, DOI 10.17487/RFC6564, April 2012, 400 . 402 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 403 of IPv6 Extension Headers", RFC 7045, 404 DOI 10.17487/RFC7045, December 2013, 405 . 407 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 408 Framework for IP Performance Metrics (IPPM)", RFC 7312, 409 DOI 10.17487/RFC7312, August 2014, 410 . 412 9.2. Informative References 414 [I-D.ietf-lmap-framework] 415 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 416 Aitken, P., and A. Akhter, "A framework for Large-Scale 417 Measurement of Broadband Performance (LMAP)", draft-ietf- 418 lmap-framework-14 (work in progress), April 2015. 420 Authors' Addresses 421 Al Morton 422 AT&T Labs 423 200 Laurel Avenue South 424 Middletown, NJ 07748 425 USA 427 Phone: +1 732 420 1571 428 Fax: +1 732 368 1192 429 Email: acmorton@att.com 430 URI: http://home.comcast.net/~acmacm/ 432 Joachim Fabini 433 TU Wien 434 Gusshausstrasse 25/E389 435 Vienna 1040 436 Austria 438 Phone: +43 1 58801 38813 439 Fax: +43 1 58801 38898 440 Email: Joachim.Fabini@tuwien.ac.at 441 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 443 Nalini Elkins 444 Inside Products, Inc. 445 Carmel Valley, CA 93924 446 USA 448 Email: nalini.elkins@insidethestack.com 450 Michael S. Ackermann 451 Blue Cross Blue Shield of Michigan 453 Email: mackermann@bcbsmi.com 455 Vinayak Hegde 457 Email: vinayakh@gmail.com