idnits 2.17.1 draft-ietf-ippm-2330-ipv6-05.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2018) is 2162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 Summary: 0 errors (**), 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: November 25, 2018 N. Elkins 7 Inside Products, Inc. 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 V. Hegde 11 Consultant 12 May 24, 2018 14 IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework 15 draft-ietf-ippm-2330-ipv6-05 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, or protocol 28 encapsulation. IPv6 header compression and use of IPv6 over Low- 29 Power Wireless Area Networks (6LoWPAN) are considered and excluded 30 from the standard-formed packet evaluation. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119] and updated 37 by [RFC8174]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on November 25, 2018. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 87 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 88 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 89 5. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 8 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 95 9.2. Informative References . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 The IETF IP Performance Metrics (IPPM) working group first created a 101 framework for metric development in [RFC2330]. This framework has 102 stood the test of time and enabled development of many fundamental 103 metrics. It has been updated in the area of metric composition 104 [RFC5835], and in several areas related to active stream measurement 105 of modern networks with reactive properties [RFC7312]. 107 The IPPM framework [RFC2330] recognized (in section 13) that many 108 aspects of IP packets can influence its processing during transfer 109 across the network. 111 In Section 15 of [RFC2330], the notion of a "standard-formed" packet 112 is defined. However, the definition was never updated to include 113 IPv6, as the original authors planned. 115 In particular, IPv6 Extension Headers and protocols which use IPv6 116 header compression are growing in use. This memo seeks to provide 117 the needed updates. 119 2. Scope 121 The purpose of this memo is to expand the coverage of IPPM metrics to 122 include IPv6, and to highlight additional aspects of test packets and 123 make them part of the IPPM performance metric framework. 125 The scope is to update key sections of [RFC2330], adding 126 considerations that will aid the development of new measurement 127 methodologies intended for today's IP networks. Specifically, this 128 memo expands the Type-P examples in section 13 of [RFC2330] and 129 expands the definition (in section 15 of [RFC2330]) of a standard- 130 formed packet to include IPv6 header aspects and other features. 132 Other topics in [RFC2330] which might be updated or augmented are 133 deferred to future work. This includes the topics of passive and 134 various forms of hybrid active/passive measurements. 136 3. Packets of Type-P 138 A fundamental property of many Internet metrics is that the measured 139 value of the metric depends on characteristics of the IP packet(s) 140 used to make the measurement. Potential influencing factors include 141 IP header fields and their values, but also higher-layer protocol 142 headers and their values. Consider an IP-connectivity metric: one 143 obtains different results depending on whether one is interested in 144 connectivity for packets destined for well-known TCP ports or 145 unreserved UDP ports, or those with invalid IPv4 checksums, or those 146 with TTL or Hop Limit of 16, for example. In some circumstances 147 these distinctions will result in special treatment of packets in 148 intermediate nodes and end systems (for example, if Diffserv 149 [RFC2474], ECN [RFC3168], Router Alert, Hop-by-hop extensions 150 [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of 151 firewalls or RSVP reservations). 153 Because of this distinction, we introduce the generic notion of a 154 "packet of Type-P", where in some contexts P will be explicitly 155 defined (i.e., exactly what type of packet we mean), partially 156 defined (e.g., "with a payload of B octets"), or left generic. Thus 157 we may talk about generic IP-Type-P-connectivity or more specific IP- 158 port-HTTP-connectivity. Some metrics and methodologies may be 159 fruitfully defined using generic Type-P definitions which are then 160 made specific when performing actual measurements. 162 Whenever a metric's value depends on the type of the packets involved 163 in the metric, the metric's name will include either a specific type 164 or a phrase such as "Type-P". Thus we will not define an "IP- 165 connectivity" metric but instead an "IP-Type-P-connectivity" metric 166 and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming 167 convention serves as an important reminder that one must be conscious 168 of the exact type of traffic being measured. 170 If the information constituting Type-P at the Source is found to have 171 changed at the Destination (or at a measurement point between the 172 Source and Destination, as in [RFC5644]), then the modified values 173 MUST be noted and reported with the results. Some modifications 174 occur according to the conditions encountered in transit (such as 175 congestion notification) or due to the requirements of segments of 176 the Source to Destination path. For example, the packet length will 177 change if IP headers are converted to the alternate version/address 178 family, or if optional Extension Headers are added or removed. Even 179 header fields like TTL/Hop Limit that typically change in transit may 180 be relevant to specific tests. For example Neighbor Discovery 181 Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value 182 set to 255, and the validity test specifies that the Hop Limit MUST 183 have a value of 255 at the receiver, too. So, while other tests may 184 intentionally exclude the TTL/Hop Limit value from their Type-P 185 definition, for this particular test the correct Hop Limit value is 186 of high relevance and MUST be part of the Type-P definition. 188 Local policies in intermediate nodes based on examination of IPv6 189 Extension Headers may affect measurement repeatability. If 190 intermediate nodes follow the recommendations of [RFC7045], 191 repeatability may be improved to some degree. 193 A closely related note: it would be very useful to know if a given 194 Internet component (like host, link, or path) treats equally a class 195 C of different types of packets. If so, then any one of those types 196 of packets can be used for subsequent measurement of the component. 197 This suggests we devise a metric or suite of metrics that attempt to 198 determine C. 200 Load balancing over parallel paths is one particular example where 201 such a class C would be more complex to determine in IPPM 202 measurements. Load balancers often use flow identifiers, computed as 203 hashes of (specific parts of) the packet header, for deciding among 204 the available parallel paths a packet will traverse. Packets with 205 identical hashes are assigned to the same flow and forwarded to the 206 same resource in the load balancer's pool. The presence of a load 207 balancer on the measurement path, as well as the specific headers and 208 fields that are used for the forwarding decision, are not known when 209 measuring the path as a black-box. Potential assessment scenarios 210 include the measurement of one of the parallel paths, and the 211 measurement of all available parallel paths that the load balancer 212 can use. Knowledge of a load balancer's flow definition 213 (alternatively: its class C specific treatment in terms of header 214 fields in scope of hash operations) is therefore a prerequisite for 215 repeatable measurements. A path may have more than one stage of load 216 balancing, adding to class C definition complexity. 218 4. Standard-Formed Packets 220 Unless otherwise stated, all metric definitions that concern IP 221 packets include an implicit assumption that the packet is *standard- 222 formed*. A packet is standard-formed if it meets all of the following 223 REQUIRED criteria: 225 + It includes a valid IP header: see below for version-specific 226 criteria. 228 + It is not an IP fragment. 230 + The Source and Destination addresses correspond to the intended 231 Source and Destination, including Multicast Destination addresses. 233 + If a transport header is present, it contains a valid checksum and 234 other valid fields. 236 For an IPv4 ([RFC0791] and updates) packet to be standard-formed, the 237 following additional criteria are REQUIRED: 239 o The version field is 4 240 o The Internet Header Length (IHL) value is >= 5; the checksum is 241 correct. 243 o Its total length as given in the IPv4 header corresponds to the 244 size of the IPv4 header plus the size of the payload. 246 o Either the packet possesses sufficient TTL to travel from the 247 Source to the Destination if the TTL is decremented by one at each 248 hop, or it possesses the maximum TTL of 255. 250 o It does not contain IP options unless explicitly noted. 252 For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the 253 following criteria are REQUIRED: 255 o The version field is 6. 257 o Its total length corresponds to the size of the IPv6 header (40 258 octets) plus the length of the payload as given in the IPv6 259 header. 261 o The payload length value for this packet (including Extension 262 Headers) conforms to the IPv6 specifications. 264 o Either the packet possesses sufficient Hop Limit to travel from 265 the Source to the Destination if the Hop Limit is decremented by 266 one at each hop, or it possesses the maximum Hop Limit of 255. 268 o Either the packet does not contain IP Extension Headers, or it 269 contains the correct number and type of headers as specified in 270 the packet, and the headers appear in the standard-conforming 271 order (Next Header). 273 o All parameters used in the header and Extension Headers are found 274 in the IANA Registry of Internet Protocol Version 6 (IPv6) 275 Parameters, partly specified in [IANA-6P]. 277 Two mechanisms require some discussion in the context of standard- 278 formed packets, namely IPv6 over Low-Power Wireless Area Networks 279 (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). 280 IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in 281 [RFC4494] and updated by [RFC6282] with header compression and 282 [RFC6775] with neighbor discovery optimizations proposes solutions 283 for using IPv6 in resource-constrained environments. An adaptation 284 layer enables the transfer of IPv6 packets over networks having a MTU 285 smaller than the minimum IPv6 MTU. Fragmentation and re-assembly of 286 IPv6 packets, as well as the resulting state that would be stored in 287 intermediate nodes, poses substantial challenges to measurements. 289 Likewise, ROHC operates statefully in compressing headers on 290 subpaths, storing state in intermediate hosts. The modification of 291 measurement packets' Type-P by ROHC and 6LowPAN, as well as 292 requirements with respect to the concept of standard-formed packets 293 for these two protocols requires substantial work. Because of these 294 reasons we consider ROHC and 6LowPAN packets to be out of the scope 295 for the standard-formed packet evaluation. 297 The topic of IPv6 Extension Headers brings current controversies into 298 focus as noted by [RFC6564] and [RFC7045]. However, measurement use 299 cases in the context of the IPPM framework like in-situ OAM 300 [I-D.ietf-ippm-ioam-data] in enterprise environments can benefit from 301 inspection, modification, addition or deletion of IPv6 extension 302 headers in hosts along the measurement path. 304 [RFC8250] endorses the use of IPv6 extension headers for measurement 305 purposes, consistent with other approved IETF specifications. 307 The following additional considerations apply when IPv6 Extension 308 Headers are present: 310 o Extension Header inspection: Some intermediate nodes may inspect 311 Extension Headers or the entire IPv6 packet while in transit. In 312 exceptional cases, they may drop the packet or route via a sub- 313 optimal path, and measurements may be unreliable or unrepeatable. 314 The packet (if it arrives) may be standard-formed, with a 315 corresponding Type-P. 317 o Extension Header modification: In Hop-by-Hop headers, some TLV 318 encoded options may be permitted to change at intermediate nodes 319 while in transit. The resulting packet may be standard-formed, 320 with a corresponding Type-P. 322 o Extension Header insertion or deletion: Although such behavior is 323 not endorsed by current standards, it is possible that Extension 324 Headers could be added to, or removed from the header chain. The 325 resulting packet may be standard-formed, with a corresponding 326 Type-P. 328 o A change in packet length (from the corresponding packet observed 329 at the Source) or header modification is a significant factor in 330 Internet measurement, and REQUIRES a new Type-P to be reported 331 with the test results. 333 It is further REQUIRED that if a packet is described as having a 334 "length of B octets", then 0 <= B <= 65535; and if B is the payload 335 length in octets, then B <= (65535-IP header size in octets, 336 including any Extension Headers). The jumbograms defined in 338 [RFC2675] are not covered by the above length analysis, but if the 339 IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a 340 packet with corresponding length MUST be considered standard-formed. 341 In practice, the path MTU will restrict the length of standard-formed 342 packets that can successfully traverse the path. Path MTU Discovery 343 for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU 344 Discovery (PLPMTUD, [RFC4821]) is recommended to prevent 345 fragmentation. 347 So, for example, one might imagine defining an IP connectivity metric 348 as "IP-type-P-connectivity for standard-formed packets with the IP 349 Diffserv field set to 0", or, more succinctly, "IP-type- 350 P-connectivity with the IP Diffserv Field set to 0", since standard- 351 formed is already implied by convention. Changing the contents of a 352 field, such as the Diffserv Code Point, ECN bits, or Flow Label may 353 have a profound affect on packet handling during transit, but does 354 not affect a packet's status as standard-formed. Likewise, the 355 addition, modification, or deletion of extension headers may change 356 the handling of packets in transit hosts. 358 [RFC2330] defines the "minimal IP packet from A to B" as a particular 359 type of standard-formed packet often useful to consider. When 360 defining IP metrics no packet smaller or simpler than this can be 361 transmitted over a correctly operating IP network. However, the 362 concept of the minimal IP packet has not been employed (since typical 363 active measurement systems employ a transport layer and a payload) 364 and its practical use is limited. Therefore, this memo deprecates 365 the concept of the "minimal IP packet from A to B". 367 5. NAT, IPv4-IPv6 Transition and Compression Techniques 369 This memo adds the key considerations for utilizing IPv6 in two 370 critical conventions of the IPPM Framework, namely packets of Type-P 371 and standard-formed packets. The need for co-existence of IPv4 and 372 IPv6 has originated transitioning standards like the Framework for 373 IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms 374 in [RFC7915] and [RFC7757]. 376 The definition and execution of measurements within the context of 377 the IPPM Framework is challenged whenever such translation mechanisms 378 are present along the measurement path. In particular use cases like 379 IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header 380 compression may result in modification of the measurement packet's 381 Type-P along the path. All these changes MUST be reported. 382 Exemplary consequences include, but are not limited to: 384 o Modification or addition of headers or header field values in 385 intermediate nodes. IPv4-IPv6 transitioning or IPv6 header 386 compression mechanisms may result in changes of the measurement 387 packets' Type-P, too. Consequently, hosts along the measurement 388 path may treat packets differently because of the Type-P 389 modification. Measurements at observation points along the path 390 may also need extra context to uniquely identify a packet. 392 o Network Address Translators (NAT) on the path can have 393 unpredictable impact on latency measurement (in terms of the 394 amount of additional time added), and possibly other types of 395 measurements. It is not usually possible to control this impact 396 (as testers may not have any control of the underlying network or 397 middleboxes). There is a possibility that stateful NAT will lead 398 to unstable performance for a flow with specific Type-P, since 399 state needs to be created for the first packet of a flow, and 400 state may be lost later if the NAT runs out of resources. 401 However, this scenario does not invalidate the Type-P for testing 402 - for example the purpose of a test might be exactly to quantify 403 the NAT's impact on delay variation. The presence of NAT may mean 404 that the measured performance of Type-P will change between the 405 source and the destination. This can cause an issue when 406 attempting to correlate measurements conducted on segments of the 407 path that include or exclude the NAT. Thus, it is a factor to be 408 aware of when conducting measurements. 410 o Variable delay due to internal state. One side effect of changes 411 due to IPv4-IPv6 transitioning mechanisms is the variable delay 412 that intermediate nodes spend for header modifications. Similar 413 to NAT the allocation of internal state and establishment of 414 context within intermediate nodes may cause variable delays, 415 depending on the measurement stream pattern and position of a 416 packet within the stream. For example the first packet in a 417 stream will typically trigger allocation of internal state in an 418 intermediate IPv4-IPv6 transition host. Subsequent packets can 419 benefit from lower processing delay due to the existing internal 420 state. However, large inter-packet delays in the measurement 421 stream may result in the intermediate host deleting the associated 422 state and needing to re-establish it on arrival of another stream 423 packet. It is worth noting that this variable delay due to 424 internal state allocation in intermediate nodes can be an explicit 425 use case for measurements. 427 o Variable delay due to packet length. IPv4-IPv6 transitioning or 428 header compression mechanisms modify the length of measurement 429 packets. The modification of the packet size may or may not 430 change the way how the measurement path treats the packets. 432 6. Security Considerations 434 The security considerations that apply to any active measurement of 435 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 437 When considering privacy of those involved in measurement or those 438 whose traffic is measured, the sensitive information available to 439 potential observers is greatly reduced when using active techniques 440 which are within this scope of work. Passive observations of user 441 traffic for measurement purposes raise many privacy issues. We refer 442 the reader to the privacy considerations described in the Large Scale 443 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 444 which covers active and passive techniques. 446 7. IANA Considerations 448 This memo makes no requests of IANA. 450 8. Acknowledgements 452 The authors thank Brian Carpenter for identifying the lack of IPv6 453 coverage in IPPM's Framework, and for listing additional 454 distinguishing factors for packets of Type-P. Both Brian and Fred 455 Baker discussed many of the interesting aspects of IPv6 with the co- 456 authors, leading to a more solid first draft: thank you both. Thanks 457 to Bill Jouris for an editorial pass through the pre-00 text. 459 9. References 461 9.1. Normative References 463 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 464 DOI 10.17487/RFC0791, September 1981, 465 . 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, 469 DOI 10.17487/RFC2119, March 1997, 470 . 472 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 473 "Framework for IP Performance Metrics", RFC 2330, 474 DOI 10.17487/RFC2330, May 1998, 475 . 477 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 478 "Definition of the Differentiated Services Field (DS 479 Field) in the IPv4 and IPv6 Headers", RFC 2474, 480 DOI 10.17487/RFC2474, December 1998, 481 . 483 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 484 RFC 2675, DOI 10.17487/RFC2675, August 1999, 485 . 487 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 488 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 489 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 490 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 491 Compression (ROHC): Framework and four profiles: RTP, UDP, 492 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 493 July 2001, . 495 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 496 of Explicit Congestion Notification (ECN) to IP", 497 RFC 3168, DOI 10.17487/RFC3168, September 2001, 498 . 500 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 501 Algorithm and Its Use with IPsec", RFC 4494, 502 DOI 10.17487/RFC4494, June 2006, 503 . 505 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 506 Zekauskas, "A One-way Active Measurement Protocol 507 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 508 . 510 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 511 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 512 . 514 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 515 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 516 DOI 10.17487/RFC4861, September 2007, 517 . 519 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 520 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 521 RFC 5357, DOI 10.17487/RFC5357, October 2008, 522 . 524 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 525 Metrics (IPPM): Spatial and Multicast", RFC 5644, 526 DOI 10.17487/RFC5644, October 2009, 527 . 529 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 530 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 531 2010, . 533 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 534 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 535 April 2011, . 537 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 538 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 539 DOI 10.17487/RFC6282, September 2011, 540 . 542 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 543 "IPv6 Flow Label Specification", RFC 6437, 544 DOI 10.17487/RFC6437, November 2011, 545 . 547 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 548 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 549 RFC 6564, DOI 10.17487/RFC6564, April 2012, 550 . 552 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 553 Bormann, "Neighbor Discovery Optimization for IPv6 over 554 Low-Power Wireless Personal Area Networks (6LoWPANs)", 555 RFC 6775, DOI 10.17487/RFC6775, November 2012, 556 . 558 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 559 of IPv6 Extension Headers", RFC 7045, 560 DOI 10.17487/RFC7045, December 2013, 561 . 563 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 564 Framework for IP Performance Metrics (IPPM)", RFC 7312, 565 DOI 10.17487/RFC7312, August 2014, 566 . 568 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 569 Mappings for Stateless IP/ICMP Translation", RFC 7757, 570 DOI 10.17487/RFC7757, February 2016, 571 . 573 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 574 "IP/ICMP Translation Algorithm", RFC 7915, 575 DOI 10.17487/RFC7915, June 2016, 576 . 578 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 579 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 580 May 2017, . 582 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 583 (IPv6) Specification", STD 86, RFC 8200, 584 DOI 10.17487/RFC8200, July 2017, 585 . 587 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 588 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 589 DOI 10.17487/RFC8201, July 2017, 590 . 592 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 593 Performance and Diagnostic Metrics (PDM) Destination 594 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 595 . 597 9.2. Informative References 599 [I-D.ietf-ippm-ioam-data] 600 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 601 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 602 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 603 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 604 data-02 (work in progress), March 2018. 606 [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) 607 Parameters", Internet Assigned Numbers Authority 608 https://www.iana.org/assignments/ipv6-parameters, January 609 2018. 611 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 612 Aitken, P., and A. Akhter, "A Framework for Large-Scale 613 Measurement of Broadband Performance (LMAP)", RFC 7594, 614 DOI 10.17487/RFC7594, September 2015, 615 . 617 Authors' Addresses 619 Al Morton 620 AT&T Labs 621 200 Laurel Avenue South 622 Middletown, NJ 07748 623 USA 625 Phone: +1 732 420 1571 626 Fax: +1 732 368 1192 627 Email: acmorton@att.com 628 URI: http://home.comcast.net/~acmacm/ 630 Joachim Fabini 631 TU Wien 632 Gusshausstrasse 25/E389 633 Vienna 1040 634 Austria 636 Phone: +43 1 58801 38813 637 Fax: +43 1 58801 38898 638 Email: Joachim.Fabini@tuwien.ac.at 639 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 641 Nalini Elkins 642 Inside Products, Inc. 643 Carmel Valley, CA 93924 644 USA 646 Email: nalini.elkins@insidethestack.com 648 Michael S. Ackermann 649 Blue Cross Blue Shield of Michigan 651 Email: mackermann@bcbsm.com 652 Vinayak Hegde 653 Consultant 654 Brahma Sun City, Wadgaon-Sheri 655 Pune, Maharashtra 411014 656 INDIA 658 Phone: +91 9449834401 659 Email: vinayakh@gmail.com 660 URI: http://www.vinayakhegde.com