< draft-ietf-6man-ipv6-alt-mark-05.txt		draft-ietf-6man-ipv6-alt-mark-06.txt >
	6MAN Working Group G. Fioccola		6MAN Working Group G. Fioccola
	Internet-Draft T. Zhou		Internet-Draft T. Zhou
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: November 26, 2021 M. Cociglio		Expires: December 2, 2021 M. Cociglio
	Telecom Italia		Telecom Italia
	F. Qin		F. Qin
	China Mobile		China Mobile
	R. Pang		R. Pang
	China Unicom		China Unicom
	May 25, 2021		May 31, 2021
	IPv6 Application of the Alternate Marking Method		IPv6 Application of the Alternate Marking Method
	draft-ietf-6man-ipv6-alt-mark-05		draft-ietf-6man-ipv6-alt-mark-06
	Abstract		Abstract
	This document describes how the Alternate Marking Method can be used		This document describes how the Alternate Marking Method can be used
	as a passive performance measurement tool in an IPv6 domain. It		as a passive performance measurement tool in an IPv6 domain. It
	defines a new Extension Header Option to encode alternate marking		defines a new Extension Header Option to encode alternate marking
	information in both the Hop-by-Hop Options Header and Destination		information in both the Hop-by-Hop Options Header and Destination
	Options Header.		Options Header.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 November 26, 2021.		This Internet-Draft will expire on December 2, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	[RFC8321] and [RFC8889] describe a passive performance measurement		[RFC8321] and [RFC8889] describe a passive performance measurement
	method, which can be used to measure packet loss, latency and jitter		method, which can be used to measure packet loss, latency and jitter
	on live traffic. Since this method is based on marking consecutive		on live traffic. Since this method is based on marking consecutive
	batches of packets, the method is often referred as the Alternate		batches of packets, the method is often referred to as the Alternate
	Marking Method.		Marking Method.
	This document defines how the Alternate Marking Method can be used to		This document defines how the Alternate Marking Method can be used to
	measure packet loss and delay metrics in IPv6.		measure packet loss and delay metrics in IPv6.
	The format of IPv6 addresses is defined in [RFC4291] while [RFC8200]		The format of IPv6 addresses is defined in [RFC4291] while [RFC8200]
	defines the IPv6 Header, including a 20-bit Flow Label and the IPv6		defines the IPv6 Header, including a 20-bit Flow Label and the IPv6
	Extension Headers.		Extension Headers.
	[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes the possible		[I-D.fioccola-v6ops-ipv6-alt-mark] summarizes the possible
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	Method in an IPv6 domain. This document, starting from the outcome		Method in an IPv6 domain. This document, starting from the outcome
	of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can		of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a new TLV that can
	be encoded in the Options Headers (Hop-by-Hop or Destination) for the		be encoded in the Options Headers (Hop-by-Hop or Destination) for the
	purpose of the Alternate Marking Method application in an IPv6		purpose of the Alternate Marking Method application in an IPv6
	domain. While the case of Segment Routing Header (SRH), defined in		domain. While the case of Segment Routing Header (SRH), defined in
	[RFC8754], is also discussed, it is valid for all the types of		[RFC8754], is also discussed, it is valid for all the types of
	Routing Header (RH).		Routing Header (RH).
	1.1. Terminology		1.1. Terminology
	This document uses the terms related to the the Alternate Marking		This document uses the terms related to the Alternate Marking Method
	Method as defined in [RFC8321] and [RFC8889].		as defined in [RFC8321] and [RFC8889].
	1.2. Requirements Language		1.2. 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Alternate Marking application to IPv6		2. Alternate Marking application to IPv6
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	not affect the traffic throughput on nodes that do not recognize		not affect the traffic throughput on nodes that do not recognize
	the Option, as further discussed in Section 4.		the Option, as further discussed in Section 4.
	o In case of Destination Option Header carrying Alternate Marking		o In case of Destination Option Header carrying Alternate Marking
	bits, it is not processed, inserted, or deleted by any node along		bits, it is not processed, inserted, or deleted by any node along
	the path until the packet reaches the destination node. Note		the path until the packet reaches the destination node. Note
	that, if there is also a Routing Header (RH), any visited		that, if there is also a Routing Header (RH), any visited
	destination in the route list can process the Option Header.		destination in the route list can process the Option Header.
	Hop-by-Hop Option Header is also useful to signal to routers on the		Hop-by-Hop Option Header is also useful to signal to routers on the
	path to process the Alternate Marking, anyway it is to be expected		path to process the Alternate Marking. However, as said, routers
	that some routers cannot process it unless explicitly configured.		will examine this option if properly configured.
	The optimization of both implementation and scaling of the Alternate		The optimization of both implementation and scaling of the Alternate
	Marking Method is also considered and a way to identify flows is		Marking Method is also considered and a way to identify flows is
	required. The Flow Monitoring Identification field (FlowMonID), as		required. The Flow Monitoring Identification field (FlowMonID), as
	introduced in the next sections, goes in this direction and it is		introduced in the next sections, goes in this direction and it is
	used to identify a monitored flow.		used to identify a monitored flow.
	Note that the FlowMonID is different from the Flow Label field of the		Note that the FlowMonID is different from the Flow Label field of the
	IPv6 Header ([RFC8200]). Flow Label is used for load-balancing/equal		IPv6 Header ([RFC8200]). Flow Label is used for load-balancing/equal
	cost multi-path (LB/ECMP). Instead, FlowMonID is only used to		cost multi-path (LB/ECMP). Instead, FlowMonID is only used to
	identify the monitored flow. The reuse of flow label field for		identify the monitored flow. The reuse of flow label field for
	identifying monitored flows is not considered since it may change the		identifying monitored flows is not considered since it may change the
	application intent and forwarding behaviour. Furthermore the flow		application intent and forwarding behaviour. Furthermore the flow
	label may be changed en route and this may also violate the		label may be changed en route and this may also violate the
	measurement task. Also, since the flow label is pseudo-random, there		measurement task. Also, since the flow label is pseudo-random, there
	is always a finite probability of collision. Those reasons make the		is always a finite probability of collision. Those reasons make the
	definition of the FlowMonID necessary for IPv6. Flow Label and		definition of the FlowMonID necessary for IPv6. Flow Label and
	FlowMonID within the same packet have different scope, identify		FlowMonID within the same packet have different scope, identify
	different flows, and associate different uses.		different flows, and are intended for different use cases.
	An important point that will also be discussed in this document is		An important point that will also be discussed in this document is
	the the uniqueness of the FlowMonID and how to allow disambiguation		the uniqueness of the FlowMonID and how to allow disambiguation of
	of the FlowMonID in case of collision. [RFC6437] states that the		the FlowMonID in case of collision. [RFC6437] states that the Flow
	Flow Label cannot be considered alone to avoid ambiguity since it		Label cannot be considered alone to avoid ambiguity since it could be
	could be accidentally or intentionally changed en route for		accidentally or intentionally changed en route for compelling
	compelling operational security reasons and this could also happen to		operational security reasons. But the Alternate Marking is usually
	the IP addresses that can change due to NAT. But the Alternate		applied in a controlled domain and there is no security issue that
	Marking is usually applied in a controlled domain, which would not		would necessitate rewriting Flow Labels. So, for the purposes of
	have NAT and there is no security issue that would necessitate		this document, both IP addresses and Flow Label should not change in
	rewriting Flow Labels. So, for the purposes of this document, both		flight and, in some cases, they could be considered together with the
	IP addresses and Flow Label should not change in flight and, in some		FlowMonID for disambiguation.
	cases, they could be considered together with the FlowMonID for
	disambiguation.
	2.1. Controlled Domain		2.1. Controlled Domain
	[RFC8799] introduces the concept of specific limited domain solutions		[RFC8799] introduces the concept of specific limited domain solutions
	and, in this regard, it is reported the IPv6 Application of the		and, in this regard, it is reported the IPv6 Application of the
	Alternate Marking Method as an example.		Alternate Marking Method as an example.
	IPv6 has much more flexibility than IPv4 and innovative applications		IPv6 has much more flexibility than IPv4 and innovative applications
	have been proposed, but for a number of reasons, such as the options		have been proposed, but for a number of reasons, such as the options
	supported, the style of network management and security requirements,		supported, the style of network management and security requirements,
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	mean that, in this case, the performance measurement does not account		mean that, in this case, the performance measurement does not account
	for all links and nodes along a path.		for all links and nodes along a path.
	Another application that can be mentioned is the presence of a		Another application that can be mentioned is the presence of a
	Routing Header, in particular it is possible to consider SRv6. A new		Routing Header, in particular it is possible to consider SRv6. A new
	type of Routing Header, referred as SRH, has been defined for SRv6.		type of Routing Header, referred as SRH, has been defined for SRv6.
	Like any other use case of IPv6, Hop-by-Hop and Destination Options		Like any other use case of IPv6, Hop-by-Hop and Destination Options
	are useable when SRv6 header is present. Because SRv6 is implemented		are useable when SRv6 header is present. Because SRv6 is implemented
	through a Segment Routing Header (SRH), Destination Options before		through a Segment Routing Header (SRH), Destination Options before
	the Routing Header are processed by each destination in the route		the Routing Header are processed by each destination in the route
	list, that means, in case of SRH, by every node that is an identity		list, that means, in case of SRH, by every SR node that is identified
	in the SR path.		by the SR path.
	In summary, it is possible to list the alternative possibilities:		In summary, it is possible to list the alternative possibilities:
	o Destination Option not preceding a Routing Header => measurement		o Destination Option not preceding a Routing Header => measurement
	only by node in Destination Address.		only by node in Destination Address.
	o Hop-by-Hop Option => every router on the path with feature		o Hop-by-Hop Option => every router on the path with feature
	enabled.		enabled.
	o Destination Option preceding a Routing Header => every destination		o Destination Option preceding a Routing Header => every destination
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	"skip if do not recognize and data do not change en route".		"skip if do not recognize and data do not change en route".
	[RFC8200] also mentions that the nodes only examine and process the		[RFC8200] also mentions that the nodes only examine and process the
	Hop-by-Hop Options header if explicitly configured to do so. For		Hop-by-Hop Options header if explicitly configured to do so. For
	these reasons, this HbH Option should not affect the throughput.		these reasons, this HbH Option should not affect the throughput.
	Anyway, in practice, it is important to be aware for the		Anyway, in practice, it is important to be aware for the
	implementation that the things may be different and it can happen		implementation that the things may be different and it can happen
	that packets with Hop-by-Hop are forced onto the slow path, but this		that packets with Hop-by-Hop are forced onto the slow path, but this
	is a general issue, as also explained in		is a general issue, as also explained in
	[I-D.hinden-6man-hbh-processing].		[I-D.hinden-6man-hbh-processing].
	In addition to the previous alternatives, it could be possible to
	consider a non-conventional application of the Destination Options
	for hop by hop action, but this would cause worse performance than
	Hop-by-Hop. The only motivation for the hop by hop usage of
	Destination Options can be for compatibility reasons but in general
	it is not recommended.
	5. Alternate Marking Method Operation		5. Alternate Marking Method Operation
	This section describes how the method operates. [RFC8321] introduces		This section describes how the method operates. [RFC8321] introduces
	several alternatives but in this section the most applicable methods		several alternatives but in this section the most applicable methods
	are reported and a new field is introduced to facilitate the		are reported and a new field is introduced to facilitate the
	deployment and improve the scalability.		deployment and improve the scalability.
	5.1. Packet Loss Measurement		5.1. Packet Loss Measurement
	The measurement of the packet loss is really straightforward. The		The measurement of the packet loss is really straightforward. The
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 44 ¶
	There are two types of security concerns: potential harm caused by		There are two types of security concerns: potential harm caused by
	the measurements and potential harm to the measurements.		the measurements and potential harm to the measurements.
	Harm caused by the measurement: Alternate Marking implies		Harm caused by the measurement: Alternate Marking implies
	modifications on the fly to an Option Header of IPv6 packets by the		modifications on the fly to an Option Header of IPv6 packets by the
	source node but this must be performed in a way that does not alter		source node but this must be performed in a way that does not alter
	the quality of service experienced by the packets and that preserves		the quality of service experienced by the packets and that preserves
	stability and performance of routers doing the measurements. The		stability and performance of routers doing the measurements. The
	advantage of the Alternate Marking method is that the marking bits		advantage of the Alternate Marking method is that the marking bits
	are the only information that is exchanged between the network nodes.		are the only small information that is exchanged between the network
	Therefore, network reconnaissance through passive eavesdropping on		nodes. Therefore, due to this intrinsic characteristic, network
	data-plane traffic does not allow attackers to gain information about		reconnaissance through passive eavesdropping on data-plane traffic is
	the network performance. Moreover, Alternate Marking should usually		difficult. Indeed the only way for an attacker can be to eavesdrop
	be applied in a controlled domain and this also helps to limit the		on multiple nodes at the same time, apply the methodology and finally
	problem.		gain information about the network performance, but this is not
			immediate. Moreover, Alternate Marking should usually be applied in
			a controlled domain and this also helps to limit the problem.
	Harm to the Measurement: Alternate Marking measurements could be		Harm to the Measurement: Alternate Marking measurements could be
	harmed by routers altering the marking of the packets or by an		harmed by routers altering the marking of the packets or by an
	attacker injecting artificial traffic. Since the measurement itself		attacker injecting artificial traffic. Since the measurement itself
	may be affected by network nodes along the path intentionally		may be affected by network nodes along the path intentionally
	altering the value of the marking bits of IPv6 packets, the Alternate		altering the value of the marking bits of IPv6 packets, the Alternate
	Marking should be applied in the context of a controlled domain,		Marking should be applied in the context of a controlled domain,
	where the network nodes are locally administered and this type of		where the network nodes are locally administered and this type of
	attack can be avoided. Indeed the source and destination addresses		attack can be avoided. Indeed the source and destination addresses
	are within the controlled domain and therefore it is unlikely subject		are within the controlled domain and therefore it is unlikely subject
	skipping to change at page 13, line 44 ¶		skipping to change at page 13, line 47 ¶
	on an time synchronization protocol. Thus, by attacking the time		on an time synchronization protocol. Thus, by attacking the time
	protocol, an attacker can potentially compromise the integrity of the		protocol, an attacker can potentially compromise the integrity of the
	measurement. A detailed discussion about the threats against time		measurement. A detailed discussion about the threats against time
	protocols and how to mitigate them is presented in [RFC7384].		protocols and how to mitigate them is presented in [RFC7384].
	7. IANA Considerations		7. IANA Considerations
	The Option Type should be assigned in IANA's "Destination Options and		The Option Type should be assigned in IANA's "Destination Options and
	Hop-by-Hop Options" registry.		Hop-by-Hop Options" registry.
	This draft requests the following IPv6 Option Type assignments from		This draft requests the following IPv6 Option Type assignment from
	the Destination Options and Hop-by-Hop Options sub-registry of		the Destination Options and Hop-by-Hop Options sub-registry of
	Internet Protocol Version 6 (IPv6) Parameters		Internet Protocol Version 6 (IPv6) Parameters
	(https://www.iana.org/assignments/ipv6-parameters/).		(https://www.iana.org/assignments/ipv6-parameters/).
	Hex Value Binary Value Description Reference		Hex Value Binary Value Description Reference
	act chg rest		act chg rest
	----------------------------------------------------------------		----------------------------------------------------------------
	TBD 00 0 tbd AltMark [This draft]		TBD 00 0 tbd AltMark [This draft]
	8. Acknowledgements		8. Acknowledgements
End of changes. 13 change blocks.
	38 lines changed or deleted		31 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/