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/