| < draft-ietf-ippm-2330-ipv6-04.txt | draft-ietf-ippm-2330-ipv6-06.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Morton | Network Working Group A. Morton | |||
| Internet-Draft AT&T Labs | Internet-Draft AT&T Labs | |||
| Updates: 2330 (if approved) J. Fabini | Updates: 2330 (if approved) J. Fabini | |||
| Intended status: Informational TU Wien | Intended status: Informational TU Wien | |||
| Expires: October 7, 2018 N. Elkins | Expires: January 1, 2019 N. Elkins | |||
| Inside Products, Inc. | Inside Products, Inc. | |||
| M. Ackermann | M. Ackermann | |||
| Blue Cross Blue Shield of Michigan | Blue Cross Blue Shield of Michigan | |||
| V. Hegde | V. Hegde | |||
| Consultant | Consultant | |||
| April 5, 2018 | June 30, 2018 | |||
| IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework | IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework | |||
| draft-ietf-ippm-2330-ipv6-04 | draft-ietf-ippm-2330-ipv6-06 | |||
| Abstract | Abstract | |||
| This memo updates the IP Performance Metrics (IPPM) Framework RFC | This memo updates the IP Performance Metrics (IPPM) Framework RFC | |||
| 2330 with new considerations for measurement methodology and testing. | 2330 with new considerations for measurement methodology and testing. | |||
| It updates the definition of standard-formed packets in RFC 2330 to | It updates the definition of standard-formed packets in RFC 2330 to | |||
| include IPv6 packets, deprecates the definition of minimum standard- | include IPv6 packets, deprecates the definition of minimal IP packet, | |||
| formed packet, and augments distinguishing aspects of packets, | and augments distinguishing aspects of packets, referred to as Type-P | |||
| referred to as Type-P for test packets in RFC 2330. This memo | for test packets in RFC 2330. This memo identifies that IPv4-IPv6 | |||
| identifies that IPv4-IPv6 co-existence can challenge measurements | co-existence can challenge measurements within the scope of the IPPM | |||
| within the scope of the IPPM Framework. Exemplary use cases include, | Framework. Example use cases include, but are not limited to | |||
| but are not limited to IPv4-IPv6 translation, NAT, protocol | IPv4-IPv6 translation, NAT, or protocol encapsulation. IPv6 header | |||
| encapsulation, IPv6 header compression, or use of IPv6 over Low-Power | compression and use of IPv6 over Low-Power Wireless Area Networks | |||
| Wireless Area Networks (6LoWPAN). | (6LoWPAN) are considered and excluded from the standard-formed packet | |||
| evaluation. | ||||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14[RFC2119] [RFC8174] when, and only when, they appear in all | ||||
| capitals, as shown here. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | 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 January 1, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | 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 | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Packets of Type-P . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 | 4. Standard-Formed Packets . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 8 | 5. NAT, IPv4-IPv6 Transition and Compression Techniques . . . . 8 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 13 | 9.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 1. Introduction | 1. Introduction | |||
| The IETF IP Performance Metrics (IPPM) working group first created a | The IETF IP Performance Metrics (IPPM) working group first created a | |||
| framework for metric development in [RFC2330]. This framework has | framework for metric development in [RFC2330]. This framework has | |||
| stood the test of time and enabled development of many fundamental | stood the test of time and enabled development of many fundamental | |||
| metrics. It has been updated in the area of metric composition | metrics. It has been updated in the area of metric composition | |||
| [RFC5835], and in several areas related to active stream measurement | [RFC5835], and in several areas related to active stream measurement | |||
| of modern networks with reactive properties [RFC7312]. | of modern networks with reactive properties [RFC7312]. | |||
| The IPPM framework [RFC2330] recognized (in section 13) that many | The IPPM framework [RFC2330] recognized (in section 13) that many | |||
| aspects of IP packets can influence its processing during transfer | aspects of IP packets can influence its processing during transfer | |||
| across the network. | across the network. | |||
| In Section 15 of [RFC2330], the notion of a "standard-formed" packet | In Section 15 of [RFC2330], the notion of a "standard-formed" packet | |||
| is defined. However, the definition was never updated to include | is defined. However, the definition was never updated to include | |||
| IPv6, as the original authors planned. | IPv6, as the original authors originally desired to do. | |||
| In particular, IPv6 Extension Headers and protocols which use IPv6 | In particular, IPv6 Extension Headers and protocols which use IPv6 | |||
| header compression are growing in use. This memo seeks to provide | header compression are growing in use. This memo seeks to provide | |||
| the needed updates. | the needed updates. | |||
| 2. Scope | 2. Scope | |||
| The purpose of this memo is to expand the coverage of IPPM metrics to | The purpose of this memo is to expand the coverage of IPPM metrics to | |||
| include IPv6, and to highlight additional aspects of test packets and | include IPv6, and to highlight additional aspects of test packets and | |||
| make them part of the IPPM performance metric framework. | make them part of the IPPM performance metric framework. | |||
| skipping to change at page 3, line 43 ¶ | skipping to change at page 4, line 7 ¶ | |||
| value of the metric depends on characteristics of the IP packet(s) | value of the metric depends on characteristics of the IP packet(s) | |||
| used to make the measurement. Potential influencing factors include | used to make the measurement. Potential influencing factors include | |||
| IP header fields and their values, but also higher-layer protocol | IP header fields and their values, but also higher-layer protocol | |||
| headers and their values. Consider an IP-connectivity metric: one | headers and their values. Consider an IP-connectivity metric: one | |||
| obtains different results depending on whether one is interested in | obtains different results depending on whether one is interested in | |||
| connectivity for packets destined for well-known TCP ports or | connectivity for packets destined for well-known TCP ports or | |||
| unreserved UDP ports, or those with invalid IPv4 checksums, or those | unreserved UDP ports, or those with invalid IPv4 checksums, or those | |||
| with TTL or Hop Limit of 16, for example. In some circumstances | with TTL or Hop Limit of 16, for example. In some circumstances | |||
| these distinctions will result in special treatment of packets in | these distinctions will result in special treatment of packets in | |||
| intermediate nodes and end systems (for example, if Diffserv | intermediate nodes and end systems (for example, if Diffserv | |||
| [RFC2780], ECN [RFC3168], Router Alert, Hop-by-hop extensions | [RFC2474], ECN [RFC3168], Router Alert [RFC6398], Hop-by-hop | |||
| [RFC7045], or Flow Labels [RFC6437] are used, or in the presence of | extensions [RFC7045], or Flow Labels [RFC6437] are used, or in the | |||
| firewalls or RSVP reservations). | presence of firewalls or RSVP reservations). | |||
| Because of this distinction, we introduce the generic notion of a | Because of this distinction, we introduce the generic notion of a | |||
| "packet of Type-P", where in some contexts P will be explicitly | "packet of Type-P", where in some contexts P will be explicitly | |||
| defined (i.e., exactly what type of packet we mean), partially | defined (i.e., exactly what type of packet we mean), partially | |||
| defined (e.g., "with a payload of B octets"), or left generic. Thus | 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- | we may talk about generic IP-Type-P-connectivity or more specific IP- | |||
| port-HTTP-connectivity. Some metrics and methodologies may be | port-HTTP-connectivity. Some metrics and methodologies may be | |||
| fruitfully defined using generic Type-P definitions which are then | fruitfully defined using generic Type-P definitions which are then | |||
| made specific when performing actual measurements. | made specific when performing actual measurements. | |||
| skipping to change at page 4, line 43 ¶ | skipping to change at page 5, line 10 ¶ | |||
| Local policies in intermediate nodes based on examination of IPv6 | Local policies in intermediate nodes based on examination of IPv6 | |||
| Extension Headers may affect measurement repeatability. If | Extension Headers may affect measurement repeatability. If | |||
| intermediate nodes follow the recommendations of [RFC7045], | intermediate nodes follow the recommendations of [RFC7045], | |||
| repeatability may be improved to some degree. | repeatability may be improved to some degree. | |||
| A closely related note: it would be very useful to know if a given | A closely related note: it would be very useful to know if a given | |||
| Internet component (like host, link, or path) treats equally a class | Internet component (like host, link, or path) treats equally a class | |||
| C of different types of packets. If so, then any one of those types | C of different types of packets. If so, then any one of those types | |||
| of packets can be used for subsequent measurement of the component. | of packets can be used for subsequent measurement of the component. | |||
| This suggests we devise a metric or suite of metrics that attempt to | This suggests we devise a metric or suite of metrics that attempt to | |||
| determine C. | determine class C (a designation which has no relationship to address | |||
| assignments, of course). | ||||
| Load balancing over parallel paths is one particular example where | Load balancing over parallel paths is one particular example where | |||
| such a class C would be more complex to determine in IPPM | such a class C would be more complex to determine in IPPM | |||
| measurements. Load balancers often use flow identifiers, computed as | measurements. Load balancers and routers often use flow identifiers, | |||
| hashes of (specific parts of) the packet header, for deciding among | computed as hashes of (specific parts of) the packet header, for | |||
| the available parallel paths a packet will traverse. Packets with | deciding among the available parallel paths a packet will traverse. | |||
| identical hashes are assigned to the same flow and forwarded to the | Packets with identical hashes are assigned to the same flow and | |||
| same resource in the load balancer's pool. The presence of a load | forwarded to the same resource in the load balancer's (or router's) | |||
| balancer on the measurement path, as well as the specific headers and | pool. The presence of a load balancer on the measurement path, as | |||
| fields that are used for the forwarding decision, are not known when | well as the specific headers and fields that are used for the | |||
| measuring the path as a black-box. Potential assessment scenarios | forwarding decision, are not known when measuring the path as a | |||
| include the measurement of one of the parallel paths, and the | black-box. Potential assessment scenarios include the measurement of | |||
| measurement of all available parallel paths that the load balancer | one of the parallel paths, and the measurement of all available | |||
| can use. Knowledge of a load balancer's flow definition | parallel paths that the load balancer can use. Knowledge of a load | |||
| (alternatively: its class C specific treatment in terms of header | balancer's flow definition (alternatively: its class C specific | |||
| fields in scope of hash operations) is therefore a prerequisite for | treatment in terms of header fields in scope of hash operations) is | |||
| repeatable measurements. A path may have more than one stage of load | therefore a prerequisite for repeatable measurements. A path may | |||
| balancing, adding to class C definition complexity. | have more than one stage of load balancing, adding to class C | |||
| definition complexity. | ||||
| 4. Standard-Formed Packets | 4. Standard-Formed Packets | |||
| Unless otherwise stated, all metric definitions that concern IP | Unless otherwise stated, all metric definitions that concern IP | |||
| packets include an implicit assumption that the packet is *standard- | packets include an implicit assumption that the packet is *standard- | |||
| formed*. A packet is standard-formed if it meets all of the following | 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 | + It includes a valid IP header: see below for version-specific | |||
| criteria. | criteria. | |||
| + It is not an IP fragment. | + It is not an IP fragment. | |||
| + The Source and Destination addresses correspond to the intended | + The Source and Destination addresses correspond to the intended | |||
| Source and Destination, including Multicast Destination addresses. | Source and Destination, including Multicast Destination addresses. | |||
| + If a transport header is present, it contains a valid checksum and | + If a transport header is present, it contains a valid checksum and | |||
| other valid fields. | other valid fields. | |||
| For an IPv4 ( [RFC0791] and updates) packet to be standard-formed, | For an IPv4 ([RFC0791] and updates) packet to be standard-formed, the | |||
| the following additional criteria are REQUIRED: | following additional criteria are REQUIRED: | |||
| o The version field is 4 | o The version field is 4 | |||
| o The Internet Header Length (IHL) value is >= 5; the checksum is | o The Internet Header Length (IHL) value is >= 5; the checksum is | |||
| correct. | correct. | |||
| o Its total length as given in the IPv4 header corresponds to the | o Its total length as given in the IPv4 header corresponds to the | |||
| size of the IPv4 header plus the size of the payload. | size of the IPv4 header plus the size of the payload. | |||
| o Either the packet possesses sufficient TTL to travel from the | o Either the packet possesses sufficient TTL to travel from the | |||
| skipping to change at page 6, line 25 ¶ | skipping to change at page 6, line 42 ¶ | |||
| the Source to the Destination if the Hop Limit is decremented by | the Source to the Destination if the Hop Limit is decremented by | |||
| one at each hop, or it possesses the maximum Hop Limit of 255. | one at each hop, or it possesses the maximum Hop Limit of 255. | |||
| o Either the packet does not contain IP Extension Headers, or it | o Either the packet does not contain IP Extension Headers, or it | |||
| contains the correct number and type of headers as specified in | contains the correct number and type of headers as specified in | |||
| the packet, and the headers appear in the standard-conforming | the packet, and the headers appear in the standard-conforming | |||
| order (Next Header). | order (Next Header). | |||
| o All parameters used in the header and Extension Headers are found | o All parameters used in the header and Extension Headers are found | |||
| in the IANA Registry of Internet Protocol Version 6 (IPv6) | in the IANA Registry of Internet Protocol Version 6 (IPv6) | |||
| Parameters, partly specified in [IANA-6P]. | Parameters, specified in [IANA-6P]. | |||
| Two mechanisms require some discussion in the context of standard- | Two mechanisms require some discussion in the context of standard- | |||
| formed packets, namely IPv6 over Low-Power Wireless Area Networks | formed packets, namely IPv6 over Low-Power Wireless Area Networks | |||
| (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). | (6LowPAN, [RFC4944]) and Robust Header Compression (ROHC, [RFC3095]). | |||
| IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in | IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in | |||
| [RFC4494] and updated by [RFC6282] with header compression and | [RFC4944] and updated by [RFC6282] with header compression and | |||
| [RFC6775] with neighbor discovery optimizations proposes solutions | [RFC6775] with neighbor discovery optimizations, proposes solutions | |||
| for using IPv6 in resource-constrained environments. An adaptation | 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 | smaller than the minimum IPv6 MTU. Fragmentation and re-assembly of | |||
| IPv6 packets, as well as the resulting state that would be stored in | IPv6 packets, as well as the resulting state that would be stored in | |||
| intermediate nodes, poses substantial challenges to measurements. | intermediate nodes, poses substantial challenges to measurements. | |||
| Likewise, ROHC operates stateful in compressing headers on subpaths, | Likewise, ROHC operates statefully in compressing headers on | |||
| storing state in intermediate hosts. The modification of measurement | subpaths, storing state in intermediate hosts. The modification of | |||
| packets' Type-P by ROHC and 6LowPAN, as well as requirements with | measurement packets' Type-P by ROHC and 6LowPAN, as well as | |||
| respect to the concept of standard-formed packets for these two | requirements with respect to the concept of standard-formed packets | |||
| protocols requires substantial work. Because of these reasons we | for these two protocols requires substantial work. Because of these | |||
| consider ROHC and 6LowPAN packets to be out of the scope of this | reasons we consider ROHC and 6LowPAN packets to be out of the scope | |||
| document. | for the standard-formed packet evaluation. | |||
| The topic of IPv6 Extension Headers brings current controversies into | The topic of IPv6 Extension Headers brings current controversies into | |||
| focus as noted by [RFC6564] and [RFC7045]. However, measurement use | focus as noted by [RFC6564] and [RFC7045]. However, measurement use | |||
| cases in the context of the IPPM framework like in-situ OAM in | cases in the context of the IPPM framework like in-situ OAM | |||
| enterprise environments or IPv6 Performance and Diagnostic Metrics | [I-D.ietf-ippm-ioam-data] in enterprise environments can benefit from | |||
| (PDM) Destination Option measurements [RFC8250] can benefit from | ||||
| inspection, modification, addition or deletion of IPv6 extension | inspection, modification, addition or deletion of IPv6 extension | |||
| headers in hosts along the measurement path. | headers in hosts along the measurement path. | |||
| As a particular use case, hosts on the path may store sending and | [RFC8250] endorses the use of IPv6 Destination Option for measurement | |||
| intermediate timestamps into dedicated extension headers to support | purposes, consistent with other approved IETF specifications. | |||
| 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. | ||||
| The following additional considerations apply when IPv6 Extension | The following additional considerations apply when IPv6 Extension | |||
| Headers are present: | Headers are present: | |||
| o Extension Header inspection: Some intermediate nodes may inspect | o Extension Header inspection: Some intermediate nodes may inspect | |||
| Extension Headers or the entire IPv6 packet while in transit. In | Extension Headers or the entire IPv6 packet while in transit. In | |||
| exceptional cases, they may drop the packet or route via a sub- | exceptional cases, they may drop the packet or route via a sub- | |||
| optimal path, and measurements may be unreliable or unrepeatable. | optimal path, and measurements may be unreliable or unrepeatable. | |||
| The packet (if it arrives) may be standard-formed, with a | The packet (if it arrives) may be standard-formed, with a | |||
| corresponding Type-P. | corresponding Type-P. | |||
| o Extension Header modification: In Hop-by-Hop headers, some TLV | o Extension Header modification: In Hop-by-Hop headers, some TLV | |||
| encoded options may be permitted to change at intermediate nodes | encoded options may be permitted to change at intermediate nodes | |||
| while in transit. The resulting packet may be standard-formed, | while in transit. The resulting packet may be standard-formed, | |||
| with a corresponding Type-P. | with a corresponding Type-P. | |||
| o Extension Header insertion or deletion: It is possible that | o Extension Header insertion or deletion: Although such behavior is | |||
| Extension Headers could be added to, or removed from the header | not endorsed by current standards, it is possible that Extension | |||
| chain. The resulting packet may be standard-formed, with a | Headers could be added to, or removed from the header chain. The | |||
| corresponding Type-P. | resulting packet may be standard-formed, with a corresponding | |||
| Type-P. This point simply encourages measurement system designers | ||||
| to be prepared for the unexpected, and to notify users when such | ||||
| events occur. There are issues with Extension Header insertion | ||||
| and deletion of course, such as exceeding the path MTU due to | ||||
| insertion, etc. | ||||
| o A change in packet length (from the corresponding packet observed | o A change in packet length (from the corresponding packet observed | |||
| at the Source) or header modification is a significant factor in | 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 | 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 of B octets", then 0 <= B <= 65535; and if B is the payload | |||
| length in octets, then B <= (65535-IP header size in octets, | length in octets, then B <= (65535-IP header size in octets, | |||
| including any Extension Headers). The jumbograms defined in | including any Extension Headers). The jumbograms defined in | |||
| [RFC2675] are not covered by the above length analysis, but if the | [RFC2675] are not covered by the above length analysis, but if the | |||
| IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a | IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a | |||
| packet with corresponding length MUST be considered standard-formed. | packet with corresponding length MUST be considered standard-formed. | |||
| In practice, the path MTU will restrict the length of standard-formed | In practice, the path MTU will restrict the length of standard-formed | |||
| packets that can successfully traverse the path. Path MTU Discovery | packets that can successfully traverse the path. Path MTU Discovery | |||
| for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU | for IP version 6 (PMTUD, [RFC8201]) or Packetization Layer Path MTU | |||
| Discovery (PLPMTUD, [RFC4821]) is recommended to prevent | Discovery (PLPMTUD, [RFC4821]) is recommended to prevent | |||
| fragmentation (or ICMP error messages) as a result of IPv6 extension | fragmentation. | |||
| header manipulation. | ||||
| So, for example, one might imagine defining an IP connectivity metric | So, for example, one might imagine defining an IP connectivity metric | |||
| as "IP-type-P-connectivity for standard-formed packets with the IP | as "IP-type-P-connectivity for standard-formed packets with the IP | |||
| Diffserv field set to 0", or, more succinctly, "IP-type- | Diffserv field set to 0", or, more succinctly, "IP-type- | |||
| P-connectivity with the IP Diffserv Field set to 0", since standard- | P-connectivity with the IP Diffserv Field set to 0", since standard- | |||
| formed is already implied by convention. Changing the contents of a | formed is already implied by convention. Changing the contents of a | |||
| field, such as the Diffserv Code Point, ECN bits, or Flow Label may | field, such as the Diffserv Code Point, ECN bits, or Flow Label may | |||
| have a profound affect on packet handling during transit, but does | have a profound affect on packet handling during transit, but does | |||
| not affect a packet's status as standard-formed. Likewise, the | not affect a packet's status as standard-formed. Likewise, the | |||
| addition, modification, or deletion of extension headers may change | addition, modification, or deletion of extension headers may change | |||
| skipping to change at page 8, line 35 ¶ | skipping to change at page 9, line 6 ¶ | |||
| and standard-formed packets. The need for co-existence of IPv4 and | and standard-formed packets. The need for co-existence of IPv4 and | |||
| IPv6 has originated transitioning standards like the Framework for | IPv6 has originated transitioning standards like the Framework for | |||
| IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms | IPv4/IPv6 Translation in [RFC6144] or IP/ICMP Translation Algorithms | |||
| in [RFC7915] and [RFC7757]. | in [RFC7915] and [RFC7757]. | |||
| The definition and execution of measurements within the context of | The definition and execution of measurements within the context of | |||
| the IPPM Framework is challenged whenever such translation mechanisms | the IPPM Framework is challenged whenever such translation mechanisms | |||
| are present along the measurement path. In particular use cases like | are present along the measurement path. In particular use cases like | |||
| IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header | IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header | |||
| compression may result in modification of the measurement packet's | compression may result in modification of the measurement packet's | |||
| Type-P along the path. All these changes MUST be reported. | Type-P along the path. All these changes MUST be reported. Example | |||
| Exemplary consequences include, but are not limited to: | consequences include, but are not limited to: | |||
| o Modification or addition of headers or header field values in | o Modification or addition of headers or header field values in | |||
| intermediate nodes. As noted in Section 4 for IPv6 extension | intermediate nodes. IPv4-IPv6 transitioning or IPv6 header | |||
| header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header | ||||
| compression mechanisms may result in changes of the measurement | compression mechanisms may result in changes of the measurement | |||
| packets' Type-P, too. Consequently, hosts along the measurement | packets' Type-P, too. Consequently, hosts along the measurement | |||
| path may treat packets differently because of the Type-P | path may treat packets differently because of the Type-P | |||
| modification. Measurements at observation points along the path | modification. Measurements at observation points along the path | |||
| may also need extra context to uniquely identify a packet. | may also need extra context to uniquely identify a packet. | |||
| o Network Address Translators (NAT) on the path can have | o Network Address Translators (NAT) on the path can have | |||
| unpredictable impact on latency measurement (in terms of the | unpredictable impact on latency measurement (in terms of the | |||
| amount of additional time added), and possibly other types of | amount of additional time added), and possibly other types of | |||
| measurements. It is not usually possible to control this impact | measurements. It is not usually possible to control this impact | |||
| skipping to change at page 10, line 16 ¶ | skipping to change at page 10, line 35 ¶ | |||
| This memo makes no requests of IANA. | This memo makes no requests of IANA. | |||
| 8. Acknowledgements | 8. Acknowledgements | |||
| The authors thank Brian Carpenter for identifying the lack of IPv6 | The authors thank Brian Carpenter for identifying the lack of IPv6 | |||
| coverage in IPPM's Framework, and for listing additional | coverage in IPPM's Framework, and for listing additional | |||
| distinguishing factors for packets of Type-P. Both Brian and Fred | distinguishing factors for packets of Type-P. Both Brian and Fred | |||
| Baker discussed many of the interesting aspects of IPv6 with the co- | Baker discussed many of the interesting aspects of IPv6 with the co- | |||
| authors, leading to a more solid first draft: thank you both. Thanks | authors, leading to a more solid first draft: thank you both. Thanks | |||
| to Bill Jouris for an editorial pass through the pre-00 text. | to Bill Jouris for an editorial pass through the pre-00 text. As we | |||
| completed our journey, Nevil Brownlee, Mike Heard, Spencer Dawkins, | ||||
| Warren Kumari, and Suresh Krishnan all contributed useful | ||||
| suggestions. | ||||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||
| "Framework for IP Performance Metrics", RFC 2330, | "Framework for IP Performance Metrics", RFC 2330, | |||
| DOI 10.17487/RFC2330, May 1998, | DOI 10.17487/RFC2330, May 1998, | |||
| <https://www.rfc-editor.org/info/rfc2330>. | <https://www.rfc-editor.org/info/rfc2330>. | |||
| [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, | ||||
| <https://www.rfc-editor.org/info/rfc2474>. | ||||
| [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", | [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", | |||
| RFC 2675, DOI 10.17487/RFC2675, August 1999, | RFC 2675, DOI 10.17487/RFC2675, August 1999, | |||
| <https://www.rfc-editor.org/info/rfc2675>. | <https://www.rfc-editor.org/info/rfc2675>. | |||
| [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, | ||||
| <https://www.rfc-editor.org/info/rfc2780>. | ||||
| [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | |||
| Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | |||
| K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | |||
| Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | |||
| Compression (ROHC): Framework and four profiles: RTP, UDP, | Compression (ROHC): Framework and four profiles: RTP, UDP, | |||
| ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, | ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, | |||
| July 2001, <https://www.rfc-editor.org/info/rfc3095>. | July 2001, <https://www.rfc-editor.org/info/rfc3095>. | |||
| [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
| of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
| RFC 3168, DOI 10.17487/RFC3168, September 2001, | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
| <https://www.rfc-editor.org/info/rfc3168>. | <https://www.rfc-editor.org/info/rfc3168>. | |||
| [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 | ||||
| Algorithm and Its Use with IPsec", RFC 4494, | ||||
| DOI 10.17487/RFC4494, June 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4494>. | ||||
| [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | |||
| Zekauskas, "A One-way Active Measurement Protocol | Zekauskas, "A One-way Active Measurement Protocol | |||
| (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | |||
| <https://www.rfc-editor.org/info/rfc4656>. | <https://www.rfc-editor.org/info/rfc4656>. | |||
| [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU | |||
| Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, | |||
| <https://www.rfc-editor.org/info/rfc4821>. | <https://www.rfc-editor.org/info/rfc4821>. | |||
| [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
| "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
| DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4861>. | <https://www.rfc-editor.org/info/rfc4861>. | |||
| [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | ||||
| "Transmission of IPv6 Packets over IEEE 802.15.4 | ||||
| Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4944>. | ||||
| [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. | |||
| Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", | |||
| RFC 5357, DOI 10.17487/RFC5357, October 2008, | RFC 5357, DOI 10.17487/RFC5357, October 2008, | |||
| <https://www.rfc-editor.org/info/rfc5357>. | <https://www.rfc-editor.org/info/rfc5357>. | |||
| [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance | [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance | |||
| Metrics (IPPM): Spatial and Multicast", RFC 5644, | Metrics (IPPM): Spatial and Multicast", RFC 5644, | |||
| DOI 10.17487/RFC5644, October 2009, | DOI 10.17487/RFC5644, October 2009, | |||
| <https://www.rfc-editor.org/info/rfc5644>. | <https://www.rfc-editor.org/info/rfc5644>. | |||
| skipping to change at page 12, line 5 ¶ | skipping to change at page 12, line 28 ¶ | |||
| [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for | [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for | |||
| IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, | IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, | |||
| April 2011, <https://www.rfc-editor.org/info/rfc6144>. | April 2011, <https://www.rfc-editor.org/info/rfc6144>. | |||
| [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | |||
| Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | |||
| DOI 10.17487/RFC6282, September 2011, | DOI 10.17487/RFC6282, September 2011, | |||
| <https://www.rfc-editor.org/info/rfc6282>. | <https://www.rfc-editor.org/info/rfc6282>. | |||
| [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and | ||||
| Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October | ||||
| 2011, <https://www.rfc-editor.org/info/rfc6398>. | ||||
| [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, | [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, | |||
| "IPv6 Flow Label Specification", RFC 6437, | "IPv6 Flow Label Specification", RFC 6437, | |||
| DOI 10.17487/RFC6437, November 2011, | DOI 10.17487/RFC6437, November 2011, | |||
| <https://www.rfc-editor.org/info/rfc6437>. | <https://www.rfc-editor.org/info/rfc6437>. | |||
| [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and | [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and | |||
| M. Bhatia, "A Uniform Format for IPv6 Extension Headers", | M. Bhatia, "A Uniform Format for IPv6 Extension Headers", | |||
| RFC 6564, DOI 10.17487/RFC6564, April 2012, | RFC 6564, DOI 10.17487/RFC6564, April 2012, | |||
| <https://www.rfc-editor.org/info/rfc6564>. | <https://www.rfc-editor.org/info/rfc6564>. | |||
| skipping to change at page 12, line 41 ¶ | skipping to change at page 13, line 20 ¶ | |||
| [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address | [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address | |||
| Mappings for Stateless IP/ICMP Translation", RFC 7757, | Mappings for Stateless IP/ICMP Translation", RFC 7757, | |||
| DOI 10.17487/RFC7757, February 2016, | DOI 10.17487/RFC7757, February 2016, | |||
| <https://www.rfc-editor.org/info/rfc7757>. | <https://www.rfc-editor.org/info/rfc7757>. | |||
| [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, | [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, | |||
| "IP/ICMP Translation Algorithm", RFC 7915, | "IP/ICMP Translation Algorithm", RFC 7915, | |||
| DOI 10.17487/RFC7915, June 2016, | DOI 10.17487/RFC7915, June 2016, | |||
| <https://www.rfc-editor.org/info/rfc7915>. | <https://www.rfc-editor.org/info/rfc7915>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, | (IPv6) Specification", STD 86, RFC 8200, | |||
| DOI 10.17487/RFC8200, July 2017, | DOI 10.17487/RFC8200, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8200>. | <https://www.rfc-editor.org/info/rfc8200>. | |||
| [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., | [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., | |||
| "Path MTU Discovery for IP version 6", STD 87, RFC 8201, | "Path MTU Discovery for IP version 6", STD 87, RFC 8201, | |||
| DOI 10.17487/RFC8201, July 2017, | DOI 10.17487/RFC8201, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8201>. | <https://www.rfc-editor.org/info/rfc8201>. | |||
| [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 | [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 | |||
| Performance and Diagnostic Metrics (PDM) Destination | Performance and Diagnostic Metrics (PDM) Destination | |||
| Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, | Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, | |||
| <https://www.rfc-editor.org/info/rfc8250>. | <https://www.rfc-editor.org/info/rfc8250>. | |||
| 9.2. Informative References | 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-03 (work in progress), June 2018. | ||||
| [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) | [IANA-6P] IANA, "IANA Internet Protocol Version 6 (IPv6) | |||
| Parameters", Internet Assigned Numbers Authority | Parameters", Internet Assigned Numbers Authority | |||
| https://www.iana.org/assignments/ipv6-parameters, January | https://www.iana.org/assignments/ipv6-parameters, January | |||
| 2018. | 2018. | |||
| [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., | |||
| Aitken, P., and A. Akhter, "A Framework for Large-Scale | Aitken, P., and A. Akhter, "A Framework for Large-Scale | |||
| Measurement of Broadband Performance (LMAP)", RFC 7594, | Measurement of Broadband Performance (LMAP)", RFC 7594, | |||
| DOI 10.17487/RFC7594, September 2015, | DOI 10.17487/RFC7594, September 2015, | |||
| <https://www.rfc-editor.org/info/rfc7594>. | <https://www.rfc-editor.org/info/rfc7594>. | |||
| End of changes. 36 change blocks. | ||||
| 83 lines changed or deleted | 118 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||