idnits 2.17.1 draft-ietf-ippm-2330-ipv6-03.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 (March 1, 2018) is 2245 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: September 2, 2018 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 March 1, 2018 14 IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework 15 draft-ietf-ippm-2330-ipv6-03 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 September 2, 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 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. 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 must be addressed in the context of standard-formed 265 packets, namely IPv6 over Low-Power Wireless Area Networks (6LowPAN, 266 [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). IPv6 267 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 must 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 We further require that if a packet is described as having a "length 323 of B octets", then 0 <= B <= 65535; and if B is the payload length in 324 octets, then B <= (65535-IP header size in octets, including any 325 Extension Headers). The jumbograms defined in [RFC2675] are not 326 covered by this length analysis. In practice, the path MTU will 327 restrict the length of standard-formed packets that can successfully 328 traverse the path. Path MTU Discovery for IP version 6 (PMTUD, 329 [RFC8201]) or Packetization Layer Path MTU Discovery (PLPMTUD, 330 [RFC4821]) is recommended to prevent fragmentation (or ICMP error 331 messages) as a result of IPv6 extension header manipulation. 333 So, for example, one might imagine defining an IP connectivity metric 334 as "IP-type-P-connectivity for standard-formed packets with the IP 335 Diffserv field set to 0", or, more succinctly, "IP-type- 336 P-connectivity with the IP Diffserv Field set to 0", since standard- 337 formed is already implied by convention. Changing the contents of a 338 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 339 have a profound affect on packet handling during transit, but does 340 not affect a packet's status as standard-formed. Likewise, the 341 addition, modification, or deletion of extension headers may change 342 the handling of packets in transit hosts. 344 [RFC2330] defines the "minimal IP packet from A to B" as a particular 345 type of standard-formed packet often useful to consider. When 346 defining IP metrics no packet smaller or simpler than this can be 347 transmitted over a correctly operating IP network. However, the 348 concept of the minimal IP packet has not been used in the meantime 349 and its practical use is limited. This is why this memo deprecates 350 the concept of the "minimal IP packet from A to B". 352 5. NAT, IPv4-IPv6 Transition and Compression Techniques 354 This memo adds the key considerations for utilizing IPv6 in two 355 critical conventions of the IPPM Framework, namely packets of Type-P 356 and standard-formed packets. The need for co-existence of IPv4 and 357 IPv6 has originated transitioning standards like the Framework for 358 IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms 359 in [RFC7915] and [RFC7757]. 361 The definition and execution of measurements within the context of 362 the IPPM Framework is challenged whenever such translation mechanisms 363 are present along the measurement path. In particular use cases like 364 IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header 365 compression may result in modification of the measurement packet's 366 Type-P along the path. All these changes must be reported. 367 Exemplary consequences include, but are not limited to: 369 o Modification or addition of headers or header field values in 370 intermediate nodes. As noted in Section 4 for IPv6 extension 371 header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header 372 compression mechanisms may result in changes of the measurement 373 packets' Type-P, too. Consequently, hosts along the measurement 374 path may treat packets differently because of the Type-P 375 modification. Measurements at observation points along the path 376 may also need extra context to uniquely identify a packet. 378 o Network Address Translators (NAT) on the path can have 379 unpredictable impact on latency measurement (in terms of the 380 amount of additional time added), and possibly other types of 381 measurements. It is not usually possible to control this impact 382 (as testers may not have any control of the underlying network or 383 middleboxes). There is a possibility that stateful NAT will lead 384 to unstable performance for a flow with specific Type-P, since 385 state needs to be created for the first packet of a flow, and 386 state may be lost later if the NAT runs out of resources. 388 However, this scenario does not invalidate the Type-P for testing 389 - for example the purpose of a test might be exactly to quantify 390 the NAT's impact on delay variation. The presence of NAT may mean 391 that the measured performance of Type-P will change between the 392 source and the destination. This can cause an issue when 393 attempting to correlate measurements conducted on segments of the 394 path that include or exclude the NAT. Thus, it is a factor to be 395 aware of when conducting measurements. 397 o Variable delay due to internal state. One side effect of changes 398 due to IPv4-IPv6 transitioning mechanisms is the variable delay 399 that intermediate nodes spend for header modifications. Similar 400 to NAT the allocation of internal state and establishment of 401 context within intermediate nodes may cause variable delays, 402 depending on the measurement stream pattern and position of a 403 packet within the stream. For example the first packet in a 404 stream will typically trigger allocation of internal state in an 405 intermediate IPv4-IPv6 transition host. Subsequent packets can 406 benefit from lower processing delay due to the existing internal 407 state. However, large inter-packet delays in the measurement 408 stream may result in the intermediate host deleting the associated 409 state and needing to re-establish it on arrival of another stream 410 packet. It is worth noting that this variable delay due to 411 internal state allocation in intermediate nodes can be an explicit 412 use case for measurements. 414 o Variable delay due to packet length. IPv4-IPv6 transitioning or 415 header compression mechanisms modify the length of measurement 416 packets. The modification of the packet size may or may not 417 change the way how the measurement path treats the packets. 419 Points that are worthwhile discussing further: handling of large 420 packets in IPv6 (including fragment extension headers, PMTUD, 421 PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression, and 422 the continued need to define a "minimal standard-formed packet". 424 . 426 6. Security Considerations 428 The security considerations that apply to any active measurement of 429 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 431 When considering privacy of those involved in measurement or those 432 whose traffic is measured, the sensitive information available to 433 potential observers is greatly reduced when using active techniques 434 which are within this scope of work. Passive observations of user 435 traffic for measurement purposes raise many privacy issues. We refer 436 the reader to the privacy considerations described in the Large Scale 437 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 438 which covers active and passive techniques. 440 7. IANA Considerations 442 This memo makes no requests of IANA. 444 8. Acknowledgements 446 The authors thank Brian Carpenter for identifying the lack of IPv6 447 coverage in IPPM's Framework, and for listing additional 448 distinguishing factors for packets of Type-P. Both Brian and Fred 449 Baker discussed many of the interesting aspects of IPv6 with the co- 450 authors, leading to a more solid first draft: thank you both. Thanks 451 to Bill Jouris for an editorial pass through the pre-00 text. 453 9. References 455 9.1. Normative References 457 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 458 DOI 10.17487/RFC0791, September 1981, 459 . 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 467 "Framework for IP Performance Metrics", RFC 2330, 468 DOI 10.17487/RFC2330, May 1998, 469 . 471 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 472 RFC 2675, DOI 10.17487/RFC2675, August 1999, 473 . 475 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 476 Values In the Internet Protocol and Related Headers", 477 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 478 . 480 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 481 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 482 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 483 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 484 Compression (ROHC): Framework and four profiles: RTP, UDP, 485 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 486 July 2001, . 488 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 489 of Explicit Congestion Notification (ECN) to IP", 490 RFC 3168, DOI 10.17487/RFC3168, September 2001, 491 . 493 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 494 Algorithm and Its Use with IPsec", RFC 4494, 495 DOI 10.17487/RFC4494, June 2006, 496 . 498 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 499 Zekauskas, "A One-way Active Measurement Protocol 500 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 501 . 503 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 504 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 505 . 507 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 508 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 509 DOI 10.17487/RFC4861, September 2007, 510 . 512 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 513 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 514 RFC 5357, DOI 10.17487/RFC5357, October 2008, 515 . 517 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 518 Metrics (IPPM): Spatial and Multicast", RFC 5644, 519 DOI 10.17487/RFC5644, October 2009, 520 . 522 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 523 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 524 2010, . 526 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 527 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 528 April 2011, . 530 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 531 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 532 DOI 10.17487/RFC6282, September 2011, 533 . 535 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 536 "IPv6 Flow Label Specification", RFC 6437, 537 DOI 10.17487/RFC6437, November 2011, 538 . 540 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 541 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 542 RFC 6564, DOI 10.17487/RFC6564, April 2012, 543 . 545 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 546 Bormann, "Neighbor Discovery Optimization for IPv6 over 547 Low-Power Wireless Personal Area Networks (6LoWPANs)", 548 RFC 6775, DOI 10.17487/RFC6775, November 2012, 549 . 551 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 552 of IPv6 Extension Headers", RFC 7045, 553 DOI 10.17487/RFC7045, December 2013, 554 . 556 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 557 Framework for IP Performance Metrics (IPPM)", RFC 7312, 558 DOI 10.17487/RFC7312, August 2014, 559 . 561 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 562 Mappings for Stateless IP/ICMP Translation", RFC 7757, 563 DOI 10.17487/RFC7757, February 2016, 564 . 566 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 567 "IP/ICMP Translation Algorithm", RFC 7915, 568 DOI 10.17487/RFC7915, June 2016, 569 . 571 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 572 (IPv6) Specification", STD 86, RFC 8200, 573 DOI 10.17487/RFC8200, July 2017, 574 . 576 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 577 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 578 DOI 10.17487/RFC8201, July 2017, 579 . 581 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 582 Performance and Diagnostic Metrics (PDM) Destination 583 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 584 . 586 9.2. Informative References 588 [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) 589 Parameters", Internet Assigned Numbers Authority 590 https://www.iana.org/assignments/ipv6-parameters, January 591 2018. 593 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 594 Aitken, P., and A. Akhter, "A Framework for Large-Scale 595 Measurement of Broadband Performance (LMAP)", RFC 7594, 596 DOI 10.17487/RFC7594, September 2015, 597 . 599 Authors' Addresses 601 Al Morton 602 AT&T Labs 603 200 Laurel Avenue South 604 Middletown, NJ 07748 605 USA 607 Phone: +1 732 420 1571 608 Fax: +1 732 368 1192 609 Email: acmorton@att.com 610 URI: http://home.comcast.net/~acmacm/ 611 Joachim Fabini 612 TU Wien 613 Gusshausstrasse 25/E389 614 Vienna 1040 615 Austria 617 Phone: +43 1 58801 38813 618 Fax: +43 1 58801 38898 619 Email: Joachim.Fabini@tuwien.ac.at 620 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 622 Nalini Elkins 623 Inside Products, Inc. 624 Carmel Valley, CA 93924 625 USA 627 Email: nalini.elkins@insidethestack.com 629 Michael S. Ackermann 630 Blue Cross Blue Shield of Michigan 632 Email: mackermann@bcbsm.com 634 Vinayak Hegde 635 Consultant 636 Brahma Sun City, Wadgaon-Sheri 637 Pune, Maharashtra 411014 638 INDIA 640 Phone: +91 9449834401 641 Email: vinayakh@gmail.com 642 URI: http://www.vinayakhegde.com