draft-ietf-ippm-2330-ipv6-03.txt   draft-ietf-ippm-2330-ipv6-04.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: September 2, 2018 N. Elkins Expires: October 7, 2018 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
March 1, 2018 April 5, 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-03 draft-ietf-ippm-2330-ipv6-04
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 minimum standard-
formed packet, and augments distinguishing aspects of packets, formed packet, and augments distinguishing aspects of packets,
referred to as Type-P for test packets in RFC 2330. This memo referred to as Type-P for test packets in RFC 2330. This memo
identifies that IPv4-IPv6 co-existence can challenge measurements identifies that IPv4-IPv6 co-existence can challenge measurements
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 September 2, 2018. This Internet-Draft will expire on October 7, 2018.
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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
in the metric, the metric's name will include either a specific type in the metric, the metric's name will include either a specific type
or a phrase such as "Type-P". Thus we will not define an "IP- or a phrase such as "Type-P". Thus we will not define an "IP-
connectivity" metric but instead an "IP-Type-P-connectivity" metric connectivity" metric but instead an "IP-Type-P-connectivity" metric
and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming
convention serves as an important reminder that one must be conscious convention serves as an important reminder that one must be conscious
of the exact type of traffic being measured. of the exact type of traffic being measured.
If the information constituting Type-P at the Source is found to have If the information constituting Type-P at the Source is found to have
changed at the Destination (or at a measurement point between the changed at the Destination (or at a measurement point between the
Source and Destination, as in [RFC5644]), then the modified values Source and Destination, as in [RFC5644]), then the modified values
SHOULD be noted and reported with the results. Some modifications MUST be noted and reported with the results. Some modifications
occur according to the conditions encountered in transit (such as occur according to the conditions encountered in transit (such as
congestion notification) or due to the requirements of segments of congestion notification) or due to the requirements of segments of
the Source to Destination path. For example, the packet length will the Source to Destination path. For example, the packet length will
change if IP headers are converted to the alternate version/address change if IP headers are converted to the alternate version/address
family, or if optional Extension Headers are added or removed. Even family, or if optional Extension Headers are added or removed. Even
header fields like TTL/Hop Limit that typically change in transit may header fields like TTL/Hop Limit that typically change in transit may
be relevant to specific tests. For example Neighbor Discovery be relevant to specific tests. For example Neighbor Discovery
Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value
set to 255, and the validity test specifies that the Hop Limit must set to 255, and the validity test specifies that the Hop Limit MUST
have a value of 255 at the receiver, too. So, while other tests may have a value of 255 at the receiver, too. So, while other tests may
intentionally exclude the TTL/Hop Limit value from their Type-P intentionally exclude the TTL/Hop Limit value from their Type-P
definition, for this particular test the correct Hop Limit value is definition, for this particular test the correct Hop Limit value is
of high relevance and must be part of the Type-P definition. of high relevance and MUST be part of the Type-P definition.
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.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
+ 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 following additional criteria are required: the 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
Source to the Destination if the TTL is decremented by one at each Source to the Destination if the TTL is decremented by one at each
hop, or it possesses the maximum TTL of 255. hop, or it possesses the maximum TTL of 255.
o It does not contain IP options unless explicitly noted. o It does not contain IP options unless explicitly noted.
For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the
following criteria are required: following criteria are REQUIRED:
o The version field is 6. o The version field is 6.
o Its total length corresponds to the size of the IPv6 header (40 o Its total length corresponds to the size of the IPv6 header (40
octets) plus the length of the payload as given in the IPv6 octets) plus the length of the payload as given in the IPv6
header. header.
o The payload length value for this packet (including Extension o The payload length value for this packet (including Extension
Headers) conforms to the IPv6 specifications. Headers) conforms to the IPv6 specifications.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
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, partly specified in [IANA-6P].
Two mechanisms must be addressed in the context of standard-formed Two mechanisms require some discussion in the context of standard-
packets, namely IPv6 over Low-Power Wireless Area Networks (6LowPAN, formed packets, namely IPv6 over Low-Power Wireless Area Networks
[RFC4494]) and Robust Header Compression (ROHC, [RFC3095]). IPv6 (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]).
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 [RFC4494] 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 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 must 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 stateful in compressing headers on subpaths,
storing state in intermediate hosts. The modification of measurement storing state in intermediate hosts. The modification of measurement
packets' Type-P by ROHC and 6LowPAN, as well as requirements with packets' Type-P by ROHC and 6LowPAN, as well as requirements with
respect to the concept of standard-formed packets for these two respect to the concept of standard-formed packets for these two
protocols requires substantial work. Because of these reasons we protocols requires substantial work. Because of these reasons we
consider ROHC and 6LowPAN packets to be out of the scope of this consider ROHC and 6LowPAN packets to be out of the scope of this
document. document.
The topic of IPv6 Extension Headers brings current controversies into The topic of IPv6 Extension Headers brings current controversies into
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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: It is possible that
Extension Headers could be added to, or removed from the header Extension Headers could be added to, or removed from the header
chain. The resulting packet may be standard-formed, with a chain. The resulting packet may be standard-formed, with a
corresponding Type-P. corresponding Type-P.
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.
We further require that if a packet is described as having a "length It is further REQUIRED that if a packet is described as having a
of B octets", then 0 <= B <= 65535; and if B is the payload length in "length of B octets", then 0 <= B <= 65535; and if B is the payload
octets, then B <= (65535-IP header size in octets, including any length in octets, then B <= (65535-IP header size in octets,
Extension Headers). The jumbograms defined in [RFC2675] are not including any Extension Headers). The jumbograms defined in
covered by this length analysis. In practice, the path MTU will [RFC2675] are not covered by the above length analysis, but if the
restrict the length of standard-formed packets that can successfully IPv6 Jumbogram Payload Hop-by-Hop Option Header is present, then a
traverse the path. Path MTU Discovery for IP version 6 (PMTUD, packet with corresponding length MUST be considered standard-formed.
[RFC8201]) or Packetization Layer Path MTU Discovery (PLPMTUD, In practice, the path MTU will restrict the length of standard-formed
[RFC4821]) is recommended to prevent fragmentation (or ICMP error packets that can successfully traverse the path. Path MTU Discovery
messages) as a result of IPv6 extension header manipulation. 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.
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
the handling of packets in transit hosts. the handling of packets in transit hosts.
[RFC2330] defines the "minimal IP packet from A to B" as a particular [RFC2330] defines the "minimal IP packet from A to B" as a particular
type of standard-formed packet often useful to consider. When type of standard-formed packet often useful to consider. When
defining IP metrics no packet smaller or simpler than this can be defining IP metrics no packet smaller or simpler than this can be
transmitted over a correctly operating IP network. However, the transmitted over a correctly operating IP network. However, the
concept of the minimal IP packet has not been used in the meantime concept of the minimal IP packet has not been employed (since typical
and its practical use is limited. This is why this memo deprecates active measurement systems employ a transport layer and a payload)
and its practical use is limited. Therefore, this memo deprecates
the concept of the "minimal IP packet from A to B". the concept of the "minimal IP packet from A to B".
5. NAT, IPv4-IPv6 Transition and Compression Techniques 5. NAT, IPv4-IPv6 Transition and Compression Techniques
This memo adds the key considerations for utilizing IPv6 in two This memo adds the key considerations for utilizing IPv6 in two
critical conventions of the IPPM Framework, namely packets of Type-P critical conventions of the IPPM Framework, namely packets of Type-P
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.
Exemplary consequences include, but are not limited to: Exemplary 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. As noted in Section 4 for IPv6 extension
header manipulation, NAT, 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.
skipping to change at page 9, line 36 skipping to change at page 9, line 39
state and needing to re-establish it on arrival of another stream state and needing to re-establish it on arrival of another stream
packet. It is worth noting that this variable delay due to packet. It is worth noting that this variable delay due to
internal state allocation in intermediate nodes can be an explicit internal state allocation in intermediate nodes can be an explicit
use case for measurements. use case for measurements.
o Variable delay due to packet length. IPv4-IPv6 transitioning or o Variable delay due to packet length. IPv4-IPv6 transitioning or
header compression mechanisms modify the length of measurement header compression mechanisms modify the length of measurement
packets. The modification of the packet size may or may not packets. The modification of the packet size may or may not
change the way how the measurement path treats the packets. change the way how the measurement path treats the packets.
Points that are worthwhile discussing further: handling of large
packets in IPv6 (including fragment extension headers, PMTUD,
PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression, and
the continued need to define a "minimal standard-formed packet".
.
6. Security Considerations 6. Security Considerations
The security considerations that apply to any active measurement of The security considerations that apply to any active measurement of
live paths are relevant here as well. See [RFC4656] and [RFC5357]. live paths are relevant here as well. See [RFC4656] and [RFC5357].
When considering privacy of those involved in measurement or those When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer traffic for measurement purposes raise many privacy issues. We refer
 End of changes. 16 change blocks. 
35 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/