idnits 2.17.1 draft-ietf-ippm-2330-ipv6-04.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 (April 5, 2018) is 2206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: October 7, 2018 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 April 5, 2018 14 IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework 15 draft-ietf-ippm-2330-ipv6-04 17 Abstract 19 This memo updates the IP Performance Metrics (IPPM) Framework RFC 20 2330 with new considerations for measurement methodology and testing. 21 It updates the definition of standard-formed packets in RFC 2330 to 22 include IPv6 packets, deprecates the definition of minimum standard- 23 formed packet, and augments distinguishing aspects of packets, 24 referred to as Type-P for test packets in RFC 2330. This memo 25 identifies that IPv4-IPv6 co-existence can challenge measurements 26 within the scope of the IPPM Framework. Exemplary use cases include, 27 but are not limited to IPv4-IPv6 translation, NAT, protocol 28 encapsulation, IPv6 header compression, or use of IPv6 over Low-Power 29 Wireless Area Networks (6LoWPAN). 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 https://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 October 7, 2018. 54 Copyright Notice 56 Copyright (c) 2018 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 (https://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. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 MUST 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. Even 165 header fields like TTL/Hop Limit that typically change in transit may 166 be relevant to specific tests. For example Neighbor Discovery 167 Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value 168 set to 255, and the validity test specifies that the Hop Limit MUST 169 have a value of 255 at the receiver, too. So, while other tests may 170 intentionally exclude the TTL/Hop Limit value from their Type-P 171 definition, for this particular test the correct Hop Limit value is 172 of high relevance and MUST be part of the Type-P definition. 174 Local policies in intermediate nodes based on examination of IPv6 175 Extension Headers may affect measurement repeatability. If 176 intermediate nodes follow the recommendations of [RFC7045], 177 repeatability may be improved to some degree. 179 A closely related note: it would be very useful to know if a given 180 Internet component (like host, link, or path) treats equally a class 181 C of different types of packets. If so, then any one of those types 182 of packets can be used for subsequent measurement of the component. 183 This suggests we devise a metric or suite of metrics that attempt to 184 determine C. 186 Load balancing over parallel paths is one particular example where 187 such a class C would be more complex to determine in IPPM 188 measurements. Load balancers often use flow identifiers, computed as 189 hashes of (specific parts of) the packet header, for deciding among 190 the available parallel paths a packet will traverse. Packets with 191 identical hashes are assigned to the same flow and forwarded to the 192 same resource in the load balancer's pool. The presence of a load 193 balancer on the measurement path, as well as the specific headers and 194 fields that are used for the forwarding decision, are not known when 195 measuring the path as a black-box. Potential assessment scenarios 196 include the measurement of one of the parallel paths, and the 197 measurement of all available parallel paths that the load balancer 198 can use. Knowledge of a load balancer's flow definition 199 (alternatively: its class C specific treatment in terms of header 200 fields in scope of hash operations) is therefore a prerequisite for 201 repeatable measurements. A path may have more than one stage of load 202 balancing, adding to class C definition complexity. 204 4. Standard-Formed Packets 206 Unless otherwise stated, all metric definitions that concern IP 207 packets include an implicit assumption that the packet is *standard- 208 formed*. A packet is standard-formed if it meets all of the following 209 criteria: 211 + It includes a valid IP header: see below for version-specific 212 criteria. 214 + It is not an IP fragment. 216 + The Source and Destination addresses correspond to the intended 217 Source and Destination, including Multicast Destination addresses. 219 + If a transport header is present, it contains a valid checksum and 220 other valid fields. 222 For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, 223 the following additional criteria are REQUIRED: 225 o The version field is 4 227 o The Internet Header Length (IHL) value is >= 5; the checksum is 228 correct. 230 o Its total length as given in the IPv4 header corresponds to the 231 size of the IPv4 header plus the size of the payload. 233 o Either the packet possesses sufficient TTL to travel from the 234 Source to the Destination if the TTL is decremented by one at each 235 hop, or it possesses the maximum TTL of 255. 237 o It does not contain IP options unless explicitly noted. 239 For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the 240 following criteria are REQUIRED: 242 o The version field is 6. 244 o Its total length corresponds to the size of the IPv6 header (40 245 octets) plus the length of the payload as given in the IPv6 246 header. 248 o The payload length value for this packet (including Extension 249 Headers) conforms to the IPv6 specifications. 251 o Either the packet possesses sufficient Hop Limit to travel from 252 the Source to the Destination if the Hop Limit is decremented by 253 one at each hop, or it possesses the maximum Hop Limit of 255. 255 o Either the packet does not contain IP Extension Headers, or it 256 contains the correct number and type of headers as specified in 257 the packet, and the headers appear in the standard-conforming 258 order (Next Header). 260 o All parameters used in the header and Extension Headers are found 261 in the IANA Registry of Internet Protocol Version 6 (IPv6) 262 Parameters, partly specified in [IANA-6P]. 264 Two mechanisms require some discussion in the context of standard- 265 formed packets, namely IPv6 over Low-Power Wireless Area Networks 266 (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). 267 IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in 268 [RFC4494] and updated by [RFC6282] with header compression and 269 [RFC6775] with neighbor discovery optimizations proposes solutions 270 for using IPv6 in resource-constrained environments. An adaptation 271 layer enables the transfer IPv6 packets over networks having a MTU 272 smaller than the minimum IPv6 MTU. Fragmentation and re-assembly of 273 IPv6 packets, as well as the resulting state that would be stored in 274 intermediate nodes, poses substantial challenges to measurements. 275 Likewise, ROHC operates stateful in compressing headers on subpaths, 276 storing state in intermediate hosts. The modification of measurement 277 packets' Type-P by ROHC and 6LowPAN, as well as requirements with 278 respect to the concept of standard-formed packets for these two 279 protocols requires substantial work. Because of these reasons we 280 consider ROHC and 6LowPAN packets to be out of the scope of this 281 document. 283 The topic of IPv6 Extension Headers brings current controversies into 284 focus as noted by [RFC6564] and [RFC7045]. However, measurement use 285 cases in the context of the IPPM framework like in-situ OAM in 286 enterprise environments or IPv6 Performance and Diagnostic Metrics 287 (PDM) Destination Option measurements [RFC8250] can benefit from 288 inspection, modification, addition or deletion of IPv6 extension 289 headers in hosts along the measurement path. 291 As a particular use case, hosts on the path may store sending and 292 intermediate timestamps into dedicated extension headers to support 293 measurements, monitoring, auditing, or reproducibility in critical 294 environments. [RFC8250] endorses the use and manipulation of IPv6 295 extension headers for measurement purposes, consistent with other 296 approved IETF specifications. 298 The following additional considerations apply when IPv6 Extension 299 Headers are present: 301 o Extension Header inspection: Some intermediate nodes may inspect 302 Extension Headers or the entire IPv6 packet while in transit. In 303 exceptional cases, they may drop the packet or route via a sub- 304 optimal path, and measurements may be unreliable or unrepeatable. 305 The packet (if it arrives) may be standard-formed, with a 306 corresponding Type-P. 308 o Extension Header modification: In Hop-by-Hop headers, some TLV 309 encoded options may be permitted to change at intermediate nodes 310 while in transit. The resulting packet may be standard-formed, 311 with a corresponding Type-P. 313 o Extension Header insertion or deletion: It is possible that 314 Extension Headers could be added to, or removed from the header 315 chain. The resulting packet may be standard-formed, with a 316 corresponding Type-P. 318 o A change in packet length (from the corresponding packet observed 319 at the Source) or header modification is a significant factor in 320 Internet measurement, and REQUIRES a new Type-P to be reported. 322 It is further REQUIRED that if a packet is described as having a 323 "length of B octets", then 0 <= B <= 65535; and if B is the payload 324 length in octets, then B <= (65535-IP header size in octets, 325 including any Extension Headers). The jumbograms defined in 326 [RFC2675] are not covered by the above length analysis, but if the 327 IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a 328 packet with corresponding length MUST be considered standard-formed. 329 In practice, the path MTU will restrict the length of standard-formed 330 packets that can successfully traverse the path. Path MTU Discovery 331 for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU 332 Discovery (PLPMTUD, [RFC4821]) is recommended to prevent 333 fragmentation (or ICMP error messages) as a result of IPv6 extension 334 header manipulation. 336 So, for example, one might imagine defining an IP connectivity metric 337 as "IP-type-P-connectivity for standard-formed packets with the IP 338 Diffserv field set to 0", or, more succinctly, "IP-type- 339 P-connectivity with the IP Diffserv Field set to 0", since standard- 340 formed is already implied by convention. Changing the contents of a 341 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 342 have a profound affect on packet handling during transit, but does 343 not affect a packet's status as standard-formed. Likewise, the 344 addition, modification, or deletion of extension headers may change 345 the handling of packets in transit hosts. 347 [RFC2330] defines the "minimal IP packet from A to B" as a particular 348 type of standard-formed packet often useful to consider. When 349 defining IP metrics no packet smaller or simpler than this can be 350 transmitted over a correctly operating IP network. However, the 351 concept of the minimal IP packet has not been employed (since typical 352 active measurement systems employ a transport layer and a payload) 353 and its practical use is limited. Therefore, this memo deprecates 354 the concept of the "minimal IP packet from A to B". 356 5. NAT, IPv4-IPv6 Transition and Compression Techniques 358 This memo adds the key considerations for utilizing IPv6 in two 359 critical conventions of the IPPM Framework, namely packets of Type-P 360 and standard-formed packets. The need for co-existence of IPv4 and 361 IPv6 has originated transitioning standards like the Framework for 362 IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms 363 in [RFC7915] and [RFC7757]. 365 The definition and execution of measurements within the context of 366 the IPPM Framework is challenged whenever such translation mechanisms 367 are present along the measurement path. In particular use cases like 368 IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header 369 compression may result in modification of the measurement packet's 370 Type-P along the path. All these changes MUST be reported. 371 Exemplary consequences include, but are not limited to: 373 o Modification or addition of headers or header field values in 374 intermediate nodes. As noted in Section 4 for IPv6 extension 375 header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header 376 compression mechanisms may result in changes of the measurement 377 packets' Type-P, too. Consequently, hosts along the measurement 378 path may treat packets differently because of the Type-P 379 modification. Measurements at observation points along the path 380 may also need extra context to uniquely identify a packet. 382 o Network Address Translators (NAT) on the path can have 383 unpredictable impact on latency measurement (in terms of the 384 amount of additional time added), and possibly other types of 385 measurements. It is not usually possible to control this impact 386 (as testers may not have any control of the underlying network or 387 middleboxes). There is a possibility that stateful NAT will lead 388 to unstable performance for a flow with specific Type-P, since 389 state needs to be created for the first packet of a flow, and 390 state may be lost later if the NAT runs out of resources. 391 However, this scenario does not invalidate the Type-P for testing 392 - for example the purpose of a test might be exactly to quantify 393 the NAT's impact on delay variation. The presence of NAT may mean 394 that the measured performance of Type-P will change between the 395 source and the destination. This can cause an issue when 396 attempting to correlate measurements conducted on segments of the 397 path that include or exclude the NAT. Thus, it is a factor to be 398 aware of when conducting measurements. 400 o Variable delay due to internal state. One side effect of changes 401 due to IPv4-IPv6 transitioning mechanisms is the variable delay 402 that intermediate nodes spend for header modifications. Similar 403 to NAT the allocation of internal state and establishment of 404 context within intermediate nodes may cause variable delays, 405 depending on the measurement stream pattern and position of a 406 packet within the stream. For example the first packet in a 407 stream will typically trigger allocation of internal state in an 408 intermediate IPv4-IPv6 transition host. Subsequent packets can 409 benefit from lower processing delay due to the existing internal 410 state. However, large inter-packet delays in the measurement 411 stream may result in the intermediate host deleting the associated 412 state and needing to re-establish it on arrival of another stream 413 packet. It is worth noting that this variable delay due to 414 internal state allocation in intermediate nodes can be an explicit 415 use case for measurements. 417 o Variable delay due to packet length. IPv4-IPv6 transitioning or 418 header compression mechanisms modify the length of measurement 419 packets. The modification of the packet size may or may not 420 change the way how the measurement path treats the packets. 422 6. Security Considerations 424 The security considerations that apply to any active measurement of 425 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 427 When considering privacy of those involved in measurement or those 428 whose traffic is measured, the sensitive information available to 429 potential observers is greatly reduced when using active techniques 430 which are within this scope of work. Passive observations of user 431 traffic for measurement purposes raise many privacy issues. We refer 432 the reader to the privacy considerations described in the Large Scale 433 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 434 which covers active and passive techniques. 436 7. IANA Considerations 438 This memo makes no requests of IANA. 440 8. Acknowledgements 442 The authors thank Brian Carpenter for identifying the lack of IPv6 443 coverage in IPPM's Framework, and for listing additional 444 distinguishing factors for packets of Type-P. Both Brian and Fred 445 Baker discussed many of the interesting aspects of IPv6 with the co- 446 authors, leading to a more solid first draft: thank you both. Thanks 447 to Bill Jouris for an editorial pass through the pre-00 text. 449 9. References 451 9.1. Normative References 453 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 454 DOI 10.17487/RFC0791, September 1981, 455 . 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 463 "Framework for IP Performance Metrics", RFC 2330, 464 DOI 10.17487/RFC2330, May 1998, 465 . 467 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 468 RFC 2675, DOI 10.17487/RFC2675, August 1999, 469 . 471 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 472 Values In the Internet Protocol and Related Headers", 473 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 474 . 476 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 477 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 478 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 479 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 480 Compression (ROHC): Framework and four profiles: RTP, UDP, 481 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 482 July 2001, . 484 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 485 of Explicit Congestion Notification (ECN) to IP", 486 RFC 3168, DOI 10.17487/RFC3168, September 2001, 487 . 489 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 490 Algorithm and Its Use with IPsec", RFC 4494, 491 DOI 10.17487/RFC4494, June 2006, 492 . 494 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 495 Zekauskas, "A One-way Active Measurement Protocol 496 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 497 . 499 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 500 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 501 . 503 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 504 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 505 DOI 10.17487/RFC4861, September 2007, 506 . 508 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 509 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 510 RFC 5357, DOI 10.17487/RFC5357, October 2008, 511 . 513 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 514 Metrics (IPPM): Spatial and Multicast", RFC 5644, 515 DOI 10.17487/RFC5644, October 2009, 516 . 518 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 519 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 520 2010, . 522 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 523 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 524 April 2011, . 526 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 527 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 528 DOI 10.17487/RFC6282, September 2011, 529 . 531 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 532 "IPv6 Flow Label Specification", RFC 6437, 533 DOI 10.17487/RFC6437, November 2011, 534 . 536 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 537 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 538 RFC 6564, DOI 10.17487/RFC6564, April 2012, 539 . 541 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 542 Bormann, "Neighbor Discovery Optimization for IPv6 over 543 Low-Power Wireless Personal Area Networks (6LoWPANs)", 544 RFC 6775, DOI 10.17487/RFC6775, November 2012, 545 . 547 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 548 of IPv6 Extension Headers", RFC 7045, 549 DOI 10.17487/RFC7045, December 2013, 550 . 552 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 553 Framework for IP Performance Metrics (IPPM)", RFC 7312, 554 DOI 10.17487/RFC7312, August 2014, 555 . 557 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 558 Mappings for Stateless IP/ICMP Translation", RFC 7757, 559 DOI 10.17487/RFC7757, February 2016, 560 . 562 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 563 "IP/ICMP Translation Algorithm", RFC 7915, 564 DOI 10.17487/RFC7915, June 2016, 565 . 567 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 568 (IPv6) Specification", STD 86, RFC 8200, 569 DOI 10.17487/RFC8200, July 2017, 570 . 572 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 573 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 574 DOI 10.17487/RFC8201, July 2017, 575 . 577 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 578 Performance and Diagnostic Metrics (PDM) Destination 579 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 580 . 582 9.2. Informative References 584 [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) 585 Parameters", Internet Assigned Numbers Authority 586 https://www.iana.org/assignments/ipv6-parameters, January 587 2018. 589 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 590 Aitken, P., and A. Akhter, "A Framework for Large-Scale 591 Measurement of Broadband Performance (LMAP)", RFC 7594, 592 DOI 10.17487/RFC7594, September 2015, 593 . 595 Authors' Addresses 597 Al Morton 598 AT&T Labs 599 200 Laurel Avenue South 600 Middletown, NJ 07748 601 USA 603 Phone: +1 732 420 1571 604 Fax: +1 732 368 1192 605 Email: acmorton@att.com 606 URI: http://home.comcast.net/~acmacm/ 608 Joachim Fabini 609 TU Wien 610 Gusshausstrasse 25/E389 611 Vienna 1040 612 Austria 614 Phone: +43 1 58801 38813 615 Fax: +43 1 58801 38898 616 Email: Joachim.Fabini@tuwien.ac.at 617 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 618 Nalini Elkins 619 Inside Products, Inc. 620 Carmel Valley, CA 93924 621 USA 623 Email: nalini.elkins@insidethestack.com 625 Michael S. Ackermann 626 Blue Cross Blue Shield of Michigan 628 Email: mackermann@bcbsm.com 630 Vinayak Hegde 631 Consultant 632 Brahma Sun City, Wadgaon-Sheri 633 Pune, Maharashtra 411014 634 INDIA 636 Phone: +91 9449834401 637 Email: vinayakh@gmail.com 638 URI: http://www.vinayakhegde.com