idnits 2.17.1 draft-ietf-ippm-2330-ipv6-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 (July 04, 2016) is 2846 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: January 5, 2017 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 July 04, 2016 14 IPv6 Updates for IPPM's Active Metric Framework 15 draft-ietf-ippm-2330-ipv6-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 January 5, 2017. 53 Copyright Notice 55 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 5 74 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 Network Address Translator (NAT) on the path can have unpredictable 170 impact on latency measurement (in terms of the amount of additional 171 time added), and possibly other types of measurements. It is not 172 usually possible to control this impact (as testers may not have any 173 control of the underlying network or middleboxes). There is a 174 possibility that stateful NAT will lead to unstable performance for a 175 flow with specific Type-P, since state needs to be created for the 176 first packet of a flow, and state may be lost later if the NAT runs 177 out of resources. However, this scenario does not invalidate the 178 Type-P for testing. The presence of NAT may mean that the measured 179 performance of Type-P will change between the source and the 180 destination. This can cause an issue when attempting to correlate 181 measurements conducted on segments of the path that include or 182 exclude the NAT. Thus, it is a factor to be aware of when conducting 183 measurements. 185 A closely related note: it would be very useful to know if a given 186 Internet component (like host, link, or path) treats equally a class 187 C of different types of packets. If so, then any one of those types 188 of packets can be used for subsequent measurement of the component. 189 This suggests we devise a metric or suite of metrics that attempt to 190 determine C. 192 4. Standard-Formed Packets 194 Unless otherwise stated, all metric definitions that concern IP 195 packets include an implicit assumption that the packet is *standard- 196 formed*. A packet is standard-formed if it meets all of the following 197 criteria: 199 + It includes a valid IP header: see below for version-specific 200 criteria. 202 + It is not an IP fragment. 204 + The Source and Destination addresses correspond to the intended 205 Source and Destination, including Multicast Destination addresses. 207 + If a transport header is present, it contains a valid checksum and 208 other valid fields. 210 For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, 211 the following additional criteria are required: 213 o The version field is 4 215 o The Internet Header Length (IHL) value is >= 5; the checksum is 216 correct. 218 o Its total length as given in the IPv4 header corresponds to the 219 size of the IPv4 header plus the size of the payload. 221 o Either the packet possesses sufficient TTL to travel from the 222 Source to the Destination if the TTL is decremented by one at each 223 hop, or it possesses the maximum TTL of 255. 225 o It does not contain IP options unless explicitly noted. 227 For an IPv6 ([RFC2460] and updates) packet to be standard-formed, the 228 following criteria are required: 230 o The version field is 6. 232 o Its total length corresponds to the size of the IPv6 header (40 233 octets) plus the length of the payload (including Extension 234 Headers) as given in the IPv6 header. 236 o Either the packet possesses sufficient Hop Count to travel from 237 the Source to the Destination if the Hop Count is decremented by 238 one at each hop, or it possesses the maximum Hop Count of 255. 240 o Either the packet does not contain IP Extension Headers, or it 241 contains the correct number and type of headers as specified in 242 the packet, and the headers appear in the standard-conforming 243 order (Next Header). 245 o All parameters used in the header and Extension Headers are found 246 in the IANA Registry of Internet Protocol Version 6 (IPv6) 247 Parameters, partly specified in [RFC7045]. 249 Compressed IPv6 headers must be compliant with [RFC4494], as updated 250 by [RFC6282], in order to be declared "standard-formed". 252 The topic of IPv6 Extension Headers brings current controversies into 253 focus as noted by [RFC6564] and [RFC7045]. The following additional 254 considerations apply when IPv6 Extension Headers are present: 256 o Extension Header inspection: Some intermediate nodes may inspect 257 Extension Headers or the entire IPv6 packet while in transit. In 258 exceptional cases, they may drop the packet or route via a sub- 259 optimal path, and measurements may be unreliable or unrepeatable. 260 The packet (if it arrives) may be standard-formed, with a 261 corresponding Type-P. 263 o Extension Header modification: In Hop-by-Hop headers, some TLV 264 encoded options may be permitted to change at intermediate nodes 265 while in transit. The resulting packet may be standard-formed, 266 with a corresponding Type-P. 268 o Extension Header insertion or deletion: It is possible that 269 Extension Headers could be added to, or removed from the header 270 chain. The resulting packet may be standard-formed, with a 271 corresponding Type-P. 273 o A change in packet length (from the corresponding packet observed 274 at the Source) or header modification is a significant factor in 275 Internet measurement, and requires a new Type-P to be reported. 277 We further require that if a packet is described as having a "length 278 of B octets", then 0 <= B <= 65535; and if B is the payload length in 279 octets, then B <= (65535-IP header size in octets, including any 280 Extension Headers). The jumbograms defined in [RFC2675] are not 281 covered by this length analysis. In practice, the path MTU will 282 restrict the length of standard-formed packets that can successfully 283 traverse the path. 285 So, for example, one might imagine defining an IP connectivity metric 286 as "IP-type-P-connectivity for standard-formed packets with the IP 287 Diffserv field set to 0", or, more succinctly, "IP-type- 288 P-connectivity with the IP Diffserv Field set to 0", since standard- 289 formed is already implied by convention. Changing the contents of a 290 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 291 have a profound affect on packet handling during transit, but does 292 not affect a packet's status as standard-formed. 294 A particular type of standard-formed packet often useful to consider 295 is the "minimal IP packet from A to B" - this is an IP packet with 296 the following properties: 298 + It is standard-formed. 300 + Its data payload is 0 octets. 302 + It contains no options or Extension Headers. 304 (Note that we do not define its protocol field, as different values 305 may lead to different treatment by the network.) 307 When defining IP metrics we keep in mind that no packet smaller or 308 simpler than this can be transmitted over a correctly operating IP 309 network. 311 5. Conclusions 313 This memo adds the key considerations for utilizing IPv6 in two 314 critical conventions of the IPPM Framework. It is RECOMMENDED to 315 adopt these new considerations in measurements involving IPv6. 317 6. Security Considerations 319 The security considerations that apply to any active measurement of 320 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 322 When considering privacy of those involved in measurement or those 323 whose traffic is measured, the sensitive information available to 324 potential observers is greatly reduced when using active techniques 325 which are within this scope of work. Passive observations of user 326 traffic for measurement purposes raise many privacy issues. We refer 327 the reader to the privacy considerations described in the Large Scale 328 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 329 which covers active and passive techniques. 331 7. IANA Considerations 333 This memo makes no requests of IANA. 335 8. Acknowledgements 337 The authors thank Brian Carpenter for identifying the lack of IPv6 338 coverage in IPPM's Framework, and for listing additional 339 distinguishing factors for packets of Type-P. Both Brian and Fred 340 Baker discussed many of the interesting aspects of IPv6 with the co- 341 authors, leading to a more solid first draft: thank you both. Thanks 342 to Bill Jouris for an editorial pass through the pre-00 text. 344 9. References 346 9.1. Normative References 348 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 349 DOI 10.17487/RFC0791, September 1981, 350 . 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 358 "Framework for IP Performance Metrics", RFC 2330, 359 DOI 10.17487/RFC2330, May 1998, 360 . 362 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 363 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 364 December 1998, . 366 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 367 RFC 2675, DOI 10.17487/RFC2675, August 1999, 368 . 370 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 371 Values In the Internet Protocol and Related Headers", 372 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 373 . 375 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 376 of Explicit Congestion Notification (ECN) to IP", 377 RFC 3168, DOI 10.17487/RFC3168, September 2001, 378 . 380 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 381 Algorithm and Its Use with IPsec", RFC 4494, 382 DOI 10.17487/RFC4494, June 2006, 383 . 385 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 386 Zekauskas, "A One-way Active Measurement Protocol 387 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 388 . 390 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 391 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 392 RFC 5357, DOI 10.17487/RFC5357, October 2008, 393 . 395 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 396 Metrics (IPPM): Spatial and Multicast", RFC 5644, 397 DOI 10.17487/RFC5644, October 2009, 398 . 400 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 401 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 402 2010, . 404 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 405 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 406 DOI 10.17487/RFC6282, September 2011, 407 . 409 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 410 "IPv6 Flow Label Specification", RFC 6437, 411 DOI 10.17487/RFC6437, November 2011, 412 . 414 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 415 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 416 RFC 6564, DOI 10.17487/RFC6564, April 2012, 417 . 419 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 420 of IPv6 Extension Headers", RFC 7045, 421 DOI 10.17487/RFC7045, December 2013, 422 . 424 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 425 Framework for IP Performance Metrics (IPPM)", RFC 7312, 426 DOI 10.17487/RFC7312, August 2014, 427 . 429 9.2. Informative References 431 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 432 Aitken, P., and A. Akhter, "A Framework for Large-Scale 433 Measurement of Broadband Performance (LMAP)", RFC 7594, 434 DOI 10.17487/RFC7594, September 2015, 435 . 437 Authors' Addresses 439 Al Morton 440 AT&T Labs 441 200 Laurel Avenue South 442 Middletown, NJ 07748 443 USA 445 Phone: +1 732 420 1571 446 Fax: +1 732 368 1192 447 Email: acmorton@att.com 448 URI: http://home.comcast.net/~acmacm/ 450 Joachim Fabini 451 TU Wien 452 Gusshausstrasse 25/E389 453 Vienna 1040 454 Austria 456 Phone: +43 1 58801 38813 457 Fax: +43 1 58801 38898 458 Email: Joachim.Fabini@tuwien.ac.at 459 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 461 Nalini Elkins 462 Inside Products, Inc. 463 Carmel Valley, CA 93924 464 USA 466 Email: nalini.elkins@insidethestack.com 468 Michael S. Ackermann 469 Blue Cross Blue Shield of Michigan 471 Email: mackermann@bcbsm.com 472 Vinayak Hegde 473 Consultant 474 Brahma Sun City, Wadgaon-Sheri 475 Pune, Maharashtra 411014 476 INDIA 478 Phone: +91 9449834401 479 Email: vinayakh@gmail.com 480 URI: http://www.vinayakhegde.com