--- 1/draft-ietf-ippm-2330-ipv6-04.txt 2018-05-24 07:14:33.753358319 -0700 +++ 2/draft-ietf-ippm-2330-ipv6-05.txt 2018-05-24 07:14:33.845360509 -0700 @@ -1,92 +1,106 @@ Network Working Group A. Morton Internet-Draft AT&T Labs Updates: 2330 (if approved) J. Fabini Intended status: Informational TU Wien -Expires: October 7, 2018 N. Elkins +Expires: November 25, 2018 N. Elkins Inside Products, Inc. M. Ackermann Blue Cross Blue Shield of Michigan V. Hegde Consultant - April 5, 2018 + May 24, 2018 IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework - draft-ietf-ippm-2330-ipv6-04 + draft-ietf-ippm-2330-ipv6-05 Abstract This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets in RFC 2330 to include IPv6 packets, deprecates the definition of minimum standard- formed packet, and augments distinguishing aspects of packets, referred to as Type-P for test packets in RFC 2330. This memo identifies that IPv4-IPv6 co-existence can challenge measurements within the scope of the IPPM Framework. Exemplary use cases include, - but are not limited to IPv4-IPv6 translation, NAT, protocol - encapsulation, IPv6 header compression, or use of IPv6 over Low-Power - Wireless Area Networks (6LoWPAN). + but are not limited to IPv4-IPv6 translation, NAT, or protocol + encapsulation. IPv6 header compression and use of IPv6 over Low- + Power Wireless Area Networks (6LoWPAN) are considered and excluded + from the standard-formed packet evaluation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + document are to be interpreted as described in [RFC2119] and updated + by [RFC8174]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 7, 2018. + This Internet-Draft will expire on November 25, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 5. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The IETF IP Performance Metrics (IPPM) working group first created a framework for metric development in [RFC2330]. This framework has stood the test of time and enabled development of many fundamental metrics. It has been updated in the area of metric composition [RFC5835], and in several areas related to active stream measurement of modern networks with reactive properties [RFC7312]. @@ -125,21 +139,21 @@ value of the metric depends on characteristics of the IP packet(s) used to make the measurement. Potential influencing factors include IP header fields and their values, but also higher-layer protocol headers and their values. Consider an IP-connectivity metric: one obtains different results depending on whether one is interested in connectivity for packets destined for well-known TCP ports or unreserved UDP ports, or those with invalid IPv4 checksums, or those with TTL or Hop Limit of 16, for example. In some circumstances these distinctions will result in special treatment of packets in intermediate nodes and end systems (for example, if Diffserv - [RFC2780], ECN [RFC3168], Router Alert, Hop-by-hop extensions + [RFC2474], ECN [RFC3168], Router Alert, Hop-by-hop extensions [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of firewalls or RSVP reservations). Because of this distinction, we introduce the generic notion of a "packet of Type-P", where in some contexts P will be explicitly defined (i.e., exactly what type of packet we mean), partially defined (e.g., "with a payload of B octets"), or left generic. Thus we may talk about generic IP-Type-P-connectivity or more specific IP- port-HTTP-connectivity. Some metrics and methodologies may be fruitfully defined using generic Type-P definitions which are then @@ -199,38 +213,37 @@ (alternatively: its class C specific treatment in terms of header fields in scope of hash operations) is therefore a prerequisite for repeatable measurements. A path may have more than one stage of load balancing, adding to class C definition complexity. 4. Standard-Formed Packets Unless otherwise stated, all metric definitions that concern IP packets include an implicit assumption that the packet is *standard- formed*. A packet is standard-formed if it meets all of the following - criteria: + REQUIRED criteria: + It includes a valid IP header: see below for version-specific criteria. + It is not an IP fragment. + The Source and Destination addresses correspond to the intended Source and Destination, including Multicast Destination addresses. + If a transport header is present, it contains a valid checksum and other valid fields. - For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, - the following additional criteria are REQUIRED: + For an IPv4 ([RFC0791] and updates) packet to be standard-formed, the + following additional criteria are REQUIRED: o The version field is 4 - o The Internet Header Length (IHL) value is >= 5; the checksum is correct. o Its total length as given in the IPv4 header corresponds to the size of the IPv4 header plus the size of the payload. o Either the packet possesses sufficient TTL to travel from the Source to the Destination if the TTL is decremented by one at each hop, or it possesses the maximum TTL of 255. @@ -261,84 +274,82 @@ in the IANA Registry of Internet Protocol Version 6 (IPv6) Parameters, partly specified in [IANA-6P]. Two mechanisms require some discussion in the context of standard- formed packets, namely IPv6 over Low-Power Wireless Area Networks (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in [RFC4494] and updated by [RFC6282] with header compression and [RFC6775] with neighbor discovery optimizations proposes solutions for using IPv6 in resource-constrained environments. An adaptation - layer enables the transfer IPv6 packets over networks having a MTU + layer enables the transfer of IPv6 packets over networks having a MTU smaller than the minimum IPv6 MTU. Fragmentation and re-assembly of IPv6 packets, as well as the resulting state that would be stored in intermediate nodes, poses substantial challenges to measurements. - Likewise, ROHC operates stateful in compressing headers on subpaths, - storing state in intermediate hosts. The modification of measurement - packets' Type-P by ROHC and 6LowPAN, as well as requirements with - respect to the concept of standard-formed packets for these two - protocols requires substantial work. Because of these reasons we - consider ROHC and 6LowPAN packets to be out of the scope of this - document. + + Likewise, ROHC operates statefully in compressing headers on + subpaths, storing state in intermediate hosts. The modification of + measurement packets' Type-P by ROHC and 6LowPAN, as well as + requirements with respect to the concept of standard-formed packets + for these two protocols requires substantial work. Because of these + reasons we consider ROHC and 6LowPAN packets to be out of the scope + for the standard-formed packet evaluation. The topic of IPv6 Extension Headers brings current controversies into focus as noted by [RFC6564] and [RFC7045]. However, measurement use - cases in the context of the IPPM framework like in-situ OAM in - enterprise environments or IPv6 Performance and Diagnostic Metrics - (PDM) Destination Option measurements [RFC8250] can benefit from + cases in the context of the IPPM framework like in-situ OAM + [I-D.ietf-ippm-ioam-data] in enterprise environments can benefit from inspection, modification, addition or deletion of IPv6 extension headers in hosts along the measurement path. - As a particular use case, hosts on the path may store sending and - intermediate timestamps into dedicated extension headers to support - measurements, monitoring, auditing, or reproducibility in critical - environments. [RFC8250] endorses the use and manipulation of IPv6 - extension headers for measurement purposes, consistent with other - approved IETF specifications. + [RFC8250] endorses the use of IPv6 extension headers for measurement + purposes, consistent with other approved IETF specifications. The following additional considerations apply when IPv6 Extension Headers are present: o Extension Header inspection: Some intermediate nodes may inspect Extension Headers or the entire IPv6 packet while in transit. In exceptional cases, they may drop the packet or route via a sub- optimal path, and measurements may be unreliable or unrepeatable. The packet (if it arrives) may be standard-formed, with a corresponding Type-P. o Extension Header modification: In Hop-by-Hop headers, some TLV encoded options may be permitted to change at intermediate nodes while in transit. The resulting packet may be standard-formed, with a corresponding Type-P. - o Extension Header insertion or deletion: It is possible that - Extension Headers could be added to, or removed from the header - chain. The resulting packet may be standard-formed, with a - corresponding Type-P. + o Extension Header insertion or deletion: Although such behavior is + not endorsed by current standards, it is possible that Extension + Headers could be added to, or removed from the header chain. The + resulting packet may be standard-formed, with a corresponding + Type-P. o A change in packet length (from the corresponding packet observed at the Source) or header modification is a significant factor in - Internet measurement, and REQUIRES a new Type-P to be reported. + Internet measurement, and REQUIRES a new Type-P to be reported + with the test results. It is further REQUIRED that if a packet is described as having a "length of B octets", then 0 <= B <= 65535; and if B is the payload length in octets, then B <= (65535-IP header size in octets, including any Extension Headers). The jumbograms defined in + [RFC2675] are not covered by the above length analysis, but if the IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a packet with corresponding length MUST be considered standard-formed. In practice, the path MTU will restrict the length of standard-formed packets that can successfully traverse the path. Path MTU Discovery for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU Discovery (PLPMTUD, [RFC4821]) is recommended to prevent - fragmentation (or ICMP error messages) as a result of IPv6 extension - header manipulation. + fragmentation. So, for example, one might imagine defining an IP connectivity metric as "IP-type-P-connectivity for standard-formed packets with the IP Diffserv field set to 0", or, more succinctly, "IP-type- P-connectivity with the IP Diffserv Field set to 0", since standard- formed is already implied by convention. Changing the contents of a field, such as the Diffserv Code Point, ECN bits, or Flow Label may have a profound affect on packet handling during transit, but does not affect a packet's status as standard-formed. Likewise, the addition, modification, or deletion of extension headers may change @@ -364,22 +375,21 @@ The definition and execution of measurements within the context of the IPPM Framework is challenged whenever such translation mechanisms are present along the measurement path. In particular use cases like IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header compression may result in modification of the measurement packet's Type-P along the path. All these changes MUST be reported. Exemplary consequences include, but are not limited to: o Modification or addition of headers or header field values in - intermediate nodes. As noted in Section 4 for IPv6 extension - header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header + intermediate nodes. IPv4-IPv6 transitioning or IPv6 header compression mechanisms may result in changes of the measurement packets' Type-P, too. Consequently, hosts along the measurement path may treat packets differently because of the Type-P modification. Measurements at observation points along the path may also need extra context to uniquely identify a packet. o Network Address Translators (NAT) on the path can have unpredictable impact on latency measurement (in terms of the amount of additional time added), and possibly other types of measurements. It is not usually possible to control this impact @@ -457,29 +467,30 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + DOI 10.17487/RFC2474, December 1998, + . + [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . - [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For - Values In the Internet Protocol and Related Headers", - BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, - . - [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", @@ -557,37 +568,48 @@ [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, . [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, . 9.2. Informative References + [I-D.ietf-ippm-ioam-data] + Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., + Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, + P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, + "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- + data-02 (work in progress), March 2018. + [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) Parameters", Internet Assigned Numbers Authority https://www.iana.org/assignments/ipv6-parameters, January 2018. [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, .