draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08v3.original		draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08v3.txt
	Benchmarking Working Group M. Georgescu
	Internet Draft L. Pislaru
	Intended status: Informational RCS&RDS
	Expires: December 2017 G. Lencse
	Szechenyi Istvan University
	June 12, 2017
	Benchmarking Methodology for IPv6 Transition Technologies		Benchmarking Working Group M. Georgescu
	draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt		Internet-Draft L. Pislaru
			Expires: December 14, 2017 RCS&RDS
			G. Lencse
			Szechenyi Istvan University
			June 12, 2017
			Benchmarking Methodology for IPv6 Transition Technologies
			draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt
	Abstract		Abstract
	There are benchmarking methodologies addressing the performance of		There are benchmarking methodologies addressing the performance of
	network interconnect devices that are IPv4- or IPv6-capable, but the		network interconnect devices that are IPv4- or IPv6-capable, but the
	IPv6 transition technologies are outside of their scope. This		IPv6 transition technologies are outside of their scope. This
	document provides complementary guidelines for evaluating the		document provides complementary guidelines for evaluating the
	performance of IPv6 transition technologies. More specifically,		performance of IPv6 transition technologies. More specifically, this
	this document targets IPv6 transition technologies that employ		document targets IPv6 transition technologies that employ
	encapsulation or translation mechanisms, as dual-stack nodes can be		encapsulation or translation mechanisms, as dual-stack nodes can be
	very well tested using the recommendations of RFC2544 and RFC5180.		very well tested using the recommendations of RFC2544 and RFC5180.
	The methodology also includes a metric for benchmarking load		The methodology also includes a metric for benchmarking load
	scalability.		scalability.
	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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Internet-Drafts are draft documents valid for a maximum of six months
	http://www.ietf.org/shadow.html		and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 12, 2016.		This Internet-Draft will expire on December 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with
	respect to this document.
	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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described in		include Simplified BSD License text as described in Section 4.e of
	Section 4.e of the Trust Legal Provisions and are provided without		the Trust Legal Provisions and are provided without warranty as
	warranty as described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. IPv6 Transition Technologies..............................4		1.1. IPv6 Transition Technologies . . . . . . . . . . . . . . 3
	2. Conventions used in this document..............................6		2. Conventions used in this document . . . . . . . . . . . . . . 5
	3. Terminology....................................................6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Test Setup.....................................................6		4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Single translation Transition Technologies................7		4.1. Single translation Transition Technologies . . . . . . . 7
	4.2. Encapsulation/Double translation Transition Technologies..7		4.2. Encapsulation/Double translation Transition Technologies 7
	5. Test Traffic...................................................8		5. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Frame Formats and Sizes...................................8		5.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 8
	5.1.1. Frame Sizes to Be Used over Ethernet.................9		5.1.1. Frame Sizes to Be Used over Ethernet . . . . . . . . 9
	5.2. Protocol Addresses........................................9		5.2. Protocol Addresses . . . . . . . . . . . . . . . . . . . 9
	5.3. Traffic Setup.............................................9		5.3. Traffic Setup . . . . . . . . . . . . . . . . . . . . . . 9
	6. Modifiers.....................................................10		6. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Benchmarking Tests............................................10		7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Throughput...............................................11		7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . 10
	Use Section 26.1 of RFC2544 unmodified........................11		7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Latency..................................................11		7.3. Packet Delay Variation . . . . . . . . . . . . . . . . . 11
	7.3. Packet Delay Variation...................................12		7.3.1. PDV . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3.1. PDV.................................................12		7.3.2. IPDV . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3.2. IPDV................................................13		7.4. Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 13
	7.4. Frame Loss Rate..........................................14		7.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 13
	7.5. Back-to-back Frames......................................14		7.6. System Recovery . . . . . . . . . . . . . . . . . . . . . 13
	7.6. System Recovery..........................................14		7.7. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.7. Reset....................................................14		8. Additional Benchmarking Tests for Stateful IPv6 Transition
			Technologies . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Additional Benchmarking Tests for Stateful IPv6 Transition		8.1. Concurrent TCP Connection Capacity . . . . . . . . . . . 14
	Technologies.....................................................14		8.2. Maximum TCP Connection Establishment Rate . . . . . . . . 14
	8.1. Concurrent TCP Connection Capacity.......................14		9. DNS Resolution Performance . . . . . . . . . . . . . . . . . 14
	8.2. Maximum TCP Connection Establishment Rate................14		9.1. Test and Traffic Setup . . . . . . . . . . . . . . . . . 14
	9. DNS Resolution Performance....................................14		9.2. Benchmarking DNS Resolution Performance . . . . . . . . . 15
	9.1. Test and Traffic Setup...................................14		9.2.1. Requirements for the Tester . . . . . . . . . . . . . 17
	9.2. Benchmarking DNS Resolution Performance..................16		10. Overload Scalability . . . . . . . . . . . . . . . . . . . . 17
	9.2.1. Requirements for the Tester.........................17		10.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Overload Scalability.........................................18		10.1.1. Single Translation Transition Technologies . . . . . 18
	10.1. Test Setup..............................................18		10.1.2. Encapsulation/Double Translation Transition
	10.1.1. Single Translation Transition Technologies.........18		Technologies . . . . . . . . . . . . . . . . . . . . 18
	10.1.2. Encapsulation/Double Translation Transition		10.2. Benchmarking Performance Degradation . . . . . . . . . . 19
	Technologies...............................................19		10.2.1. Network performance degradation with simultaneous
	10.2. Benchmarking Performance Degradation....................19		load . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.2.1. Network performance degradation with simultaneous load		10.2.2. Network performance degradation with incremental
	...........................................................19		load . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.2.2. Network performance degradation with incremental load		11. NAT44 and NAT66 . . . . . . . . . . . . . . . . . . . . . . . 21
	...........................................................20		12. Summarizing function and variation . . . . . . . . . . . . . 21
	11. NAT44 and NAT66..............................................21		13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	12. Summarizing function and variation...........................21		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	13. Security Considerations......................................22		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	14. IANA Considerations..........................................22		15.1. Normative References . . . . . . . . . . . . . . . . . . 22
	15. References...................................................22		15.2. Informative References . . . . . . . . . . . . . . . . . 23
	15.1. Normative References....................................22		Appendix A. Theoretical Maximum Frame Rates . . . . . . . . . . 25
	15.2. Informative References..................................23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	16. Acknowledgements.............................................26
	Appendix A. Theoretical Maximum Frame Rates......................27
	1. Introduction		1. Introduction
	The methodologies described in [RFC2544] and [RFC5180] help vendors		The methodologies described in [RFC2544] and [RFC5180] help vendors
	and network operators alike analyze the performance of IPv4 and		and network operators alike analyze the performance of IPv4 and
	IPv6-capable network devices. The methodology presented in [RFC2544]		IPv6-capable network devices. The methodology presented in [RFC2544]
	is mostly IP version independent, while [RFC5180] contains		is mostly IP version independent, while [RFC5180] contains
	complementary recommendations, which are specific to the latest IP		complementary recommendations, which are specific to the latest IP
	version, IPv6. However, [RFC5180] does not cover IPv6 transition		version, IPv6. However, [RFC5180] does not cover IPv6 transition
	technologies.		technologies.
	IPv6 is not backwards compatible, which means that IPv4-only nodes		IPv6 is not backwards compatible, which means that IPv4-only nodes
	cannot directly communicate with IPv6-only nodes. To solve this		cannot directly communicate with IPv6-only nodes. To solve this
	issue, IPv6 transition technologies have been proposed and		issue, IPv6 transition technologies have been proposed and
	implemented.		implemented.
	This document presents benchmarking guidelines dedicated to IPv6		This document presents benchmarking guidelines dedicated to IPv6
	transition technologies. The benchmarking tests can provide insights		transition technologies. The benchmarking tests can provide insights
	about the performance of these technologies, which can act as useful		about the performance of these technologies, which can act as useful
	feedback for developers, as well as for network operators going		feedback for developers, as well as for network operators going
	through the IPv6 transition process.		through the IPv6 transition process.
	The document also includes an approach to quantify performance when		The document also includes an approach to quantify performance when
	operating in overload. Overload scalability can be defined as a		operating in overload. Overload scalability can be defined as a
	system's ability to gracefully accommodate greater numbers of flows		system's ability to gracefully accommodate greater numbers of flows
	than the maximum number of flows which the Device under test (DUT)		than the maximum number of flows which the Device under test (DUT)
	can operate normally. The approach taken here is to quantify the		can operate normally. The approach taken here is to quantify the
	overload scalability by measuring the performance created by an		overload scalability by measuring the performance created by an
	excessive number of network flows, and comparing performance to the		excessive number of network flows, and comparing performance to the
	non-overloaded case.		non-overloaded case.
	1.1. IPv6 Transition Technologies		1.1. IPv6 Transition Technologies
	Two of the basic transition technologies, dual IP layer (also known		Two of the basic transition technologies, dual IP layer (also known
	as dual stack) and encapsulation are presented in [RFC4213].		as dual stack) and encapsulation are presented in [RFC4213]. IPv4/
	IPv4/IPv6 Translation is presented in [RFC6144]. Most of the		IPv6 Translation is presented in [RFC6144]. Most of the transition
	transition technologies employ at least one variation of these		technologies employ at least one variation of these mechanisms. In
	mechanisms. In this context, a generic classification of the		this context, a generic classification of the transition technologies
	transition technologies can prove useful.		can prove useful.
	We can consider a production network transitioning to IPv6 as being		We can consider a production network transitioning to IPv6 as being
	constructed using the following IP domains:		constructed using the following IP domains:
	o Domain A: IPvX specific domain		o Domain A: IPvX specific domain
	o Core domain: which may be IPvY specific or dual-stack(IPvX and		o Core domain: which may be IPvY specific or dual-stack(IPvX and
	IPvY)		IPvY)
	o Domain B: IPvX specific domain		o Domain B: IPvX specific domain
	Note: X,Y are part of the set {4,6}, and X NOT.EQUAL Y.		Note: X,Y are part of the set {4,6}, and X NOT.EQUAL Y.
	According to the technology used for the core domain traversal the		According to the technology used for the core domain traversal the
	transition technologies can be categorized as follows:		transition technologies can be categorized as follows:
	1. Dual-stack: the core domain devices implement both IP protocols.		1. Dual-stack: the core domain devices implement both IP protocols.
	2. Single Translation: In this case, the production network is		2. Single Translation: In this case, the production network is
	assumed to have only two domains, Domain A and the Core domain.		assumed to have only two domains, Domain A and the Core domain.
	The core domain is assumed to be IPvY specific. IPvX packets are		The core domain is assumed to be IPvY specific. IPvX packets are
	translated to IPvY at the edge between Domain A and the Core		translated to IPvY at the edge between Domain A and the Core
	domain.		domain.
	3. Double translation: The production network is assumed to have all		3. Double translation: The production network is assumed to have all
	three domains; Domains A and B are IPvX specific, while the core		three domains; Domains A and B are IPvX specific, while the core
	domain is IPvY specific. A translation mechanism is employed for		domain is IPvY specific. A translation mechanism is employed for
	the traversal of the core network. The IPvX packets are		the traversal of the core network. The IPvX packets are
	translated to IPvY packets at the edge between Domain A and the		translated to IPvY packets at the edge between Domain A and the
	Core domain. Subsequently, the IPvY packets are translated back		Core domain. Subsequently, the IPvY packets are translated back
	to IPvX at the edge between the Core domain and Domain B.		to IPvX at the edge between the Core domain and Domain B.
	4. Encapsulation: The production network is assumed to have all		4. Encapsulation: The production network is assumed to have all
	three domains; Domains A and B are IPvX specific, while the core		three domains; Domains A and B are IPvX specific, while the core
	domain is IPvY specific. An encapsulation mechanism is used to		domain is IPvY specific. An encapsulation mechanism is used to
	traverse the core domain. The IPvX packets are encapsulated to		traverse the core domain. The IPvX packets are encapsulated to
	IPvY packets at the edge between Domain A and the Core domain.		IPvY packets at the edge between Domain A and the Core domain.
	Subsequently, the IPvY packets are de-encapsulated at the edge		Subsequently, the IPvY packets are de-encapsulated at the edge
	between the Core domain and Domain B.		between the Core domain and Domain B.
	The performance of Dual-stack transition technologies can be fully		The performance of Dual-stack transition technologies can be fully
	evaluated using the benchmarking methodologies presented by		evaluated using the benchmarking methodologies presented by [RFC2544]
	[RFC2544] and [RFC5180]. Consequently, this document focuses on the		and [RFC5180]. Consequently, this document focuses on the other 3
	other 3 categories: Single translation, Encapsulation and Double		categories: Single translation, Encapsulation and Double translation
	translation transition technologies.		transition technologies.
	Another important aspect by which the IPv6 transition technologies		Another important aspect by which the IPv6 transition technologies
	can be categorized is their use of stateful or stateless mapping		can be categorized is their use of stateful or stateless mapping
	algorithms. The technologies that use stateful mapping algorithms		algorithms. The technologies that use stateful mapping algorithms
	(e.g. Stateful NAT64 [RFC6146]) create dynamic correlations between		(e.g. Stateful NAT64 [RFC6146]) create dynamic correlations between
	IP addresses or {IP address, transport protocol, transport port		IP addresses or {IP address, transport protocol, transport port
	number} tuples, which are stored in a state table. For ease of		number} tuples, which are stored in a state table. For ease of
	reference, the IPv6 transition technologies which employ stateful		reference, the IPv6 transition technologies which employ stateful
	mapping algorithms will be called stateful IPv6 transition		mapping algorithms will be called stateful IPv6 transition
	technologies. The efficiency with which the state table is managed		technologies. The efficiency with which the state table is managed
	can be an important performance indicator for these technologies.		can be an important performance indicator for these technologies.
	Hence, for the stateful IPv6 transition technologies additional		Hence, for the stateful IPv6 transition technologies additional
	benchmarking tests are RECOMMENDED.		benchmarking tests are RECOMMENDED.
	Table 1 contains the generic categories as well as associations with		Table 1 contains the generic categories as well as associations with
	some of the IPv6 transition technologies proposed in the IETF.		some of the IPv6 transition technologies proposed in the IETF.
	Please note that the list is not exhaustive.		Please note that the list is not exhaustive.
	Table 1. IPv6 Transition Technologies Categories		Figure 1: IPv6 Transition Technologies Categories
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+ | |
	| | Generic category | IPv6 Transition Technology |		Generic category | IPv6 Transition Technology |
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+ | 1 |
	| 1 | Dual-stack | Dual IP Layer Operations [RFC4213] |		Dual-stack | Dual IP Layer Operations [RFC4213] |
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+ | 2 |
	| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |		Single translation | NAT64 [RFC6146], IVI [RFC6219] |
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+ | 3 |
	| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |		Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+ | 4 |
	| 4 | Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] |		Encapsulation | DSLite[RFC6333], MAP-E [RFC7597] | | | | Lightweight
	| | | Lightweight 4over6 [RFC7596] |		4over6 [RFC7596] | | | | 6RD [RFC5569], 6PE [RFC4798], 6VPE | | | |
	| | | 6RD [RFC5569], 6PE [RFC4798], 6VPE |		6VPE [RFC4659] |
	| | | 6VPE [RFC4659] |
	+---+--------------------+------------------------------------+		+---+--------------------+------------------------------------+
	2. Conventions used in this document		2. Conventions used in this document
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	In this document, these words will appear with that interpretation		In this document, these words will appear with that interpretation
	only when in ALL CAPS. Lower case uses of these words are not to be		only when in ALL CAPS. Lower case uses of these words are not to be
	interpreted as carrying [RFC2119] significance.		interpreted as carrying [RFC2119] significance.
	Although these terms are usually associated with protocol		Although these terms are usually associated with protocol
	requirements, in this document the terms are requirements for users		requirements, in this document the terms are requirements for users
	and systems that intend to implement the test conditions and claim		and systems that intend to implement the test conditions and claim
	conformance with this specification.		conformance with this specification.
	3. Terminology		3. Terminology
	A number of terms used in this memo have been defined in other RFCs.		A number of terms used in this memo have been defined in other RFCs.
	Please refer to those RFCs for definitions, testing procedures and		Please refer to those RFCs for definitions, testing procedures and
	reporting formats.		reporting formats.
	Throughput (Benchmark) - [RFC2544]		Throughput (Benchmark) - [RFC2544]
	Frame Loss Rate (Benchmark) - [RFC2544]		Frame Loss Rate (Benchmark) - [RFC2544]
	Back-to-back Frames (Benchmark) - [RFC2544]		Back-to-back Frames (Benchmark) - [RFC2544]
	System Recovery (Benchmark) - [RFC2544]		System Recovery (Benchmark) - [RFC2544]
	Reset (Benchmark) - [RFC6201]		Reset (Benchmark) - [RFC6201]
	Concurrent TCP Connection Capacity (Benchmark) - [RFC3511]		Concurrent TCP Connection Capacity (Benchmark) - [RFC3511]
	Maximum TCP Connection Establishment Rate (Benchmark) - [RFC3511]		Maximum TCP Connection Establishment Rate (Benchmark) - [RFC3511]
	4. Test Setup		4. Test Setup
	The test environment setup options recommended for IPv6 transition		The test environment setup options recommended for IPv6 transition
	technologies benchmarking are very similar to the ones presented in		technologies benchmarking are very similar to the ones presented in
	Section 6 of [RFC2544]. In the case of the tester setup, the options		Section 6 of [RFC2544]. In the case of the tester setup, the options
	presented in [RFC2544] and [RFC5180] can be applied here as well.		presented in [RFC2544] and [RFC5180] can be applied here as well.
	However, the Device under test (DUT) setup options should be		However, the Device under test (DUT) setup options should be
	explained in the context of the targeted categories of IPv6		explained in the context of the targeted categories of IPv6
	transition technologies: Single translation, Double translation and		transition technologies: Single translation, Double translation and
	Encapsulation transition technologies.		Encapsulation transition technologies.
	Although both single tester and sender/receiver setups are		Although both single tester and sender/receiver setups are applicable
	applicable to this methodology, the single tester setup will be used		to this methodology, the single tester setup will be used to describe
	to describe the DUT setup options.		the DUT setup options.
	For the test setups presented in this memo, dynamic routing SHOULD		For the test setups presented in this memo, dynamic routing SHOULD be
	be employed. However, the presence of routing and management frames		employed. However, the presence of routing and management frames can
	can represent unwanted background data that can affect the		represent unwanted background data that can affect the benchmarking
	benchmarking result. To that end, the procedures defined in		result. To that end, the procedures defined in [RFC2544] (Sections
	[RFC2544] (Sections 11.2 and 11.3) related to routing and management		11.2 and 11.3) related to routing and management frames SHOULD be
	frames SHOULD be used here. Moreover, the "Trial description"		used here. Moreover, the "Trial description" recommendations
	recommendations presented in [RFC2544] (Section 23) are also valid		presented in [RFC2544] (Section 23) are also valid for this memo.
	for this memo.
	In terms of route setup, the recommendations of [RFC2544] Section 13		In terms of route setup, the recommendations of [RFC2544] Section 13
	are valid for this document assuming that IPv6 capable routing		are valid for this document assuming that IPv6 capable routing
	protocols are used..		protocols are used..
	4.1. Single translation Transition Technologies		4.1. Single translation Transition Technologies
	For the evaluation of Single translation transition technologies, a		For the evaluation of Single translation transition technologies, a
	single DUT setup (see Figure 1) SHOULD be used. The DUT is		single DUT setup (see Figure 1) SHOULD be used. The DUT is
	responsible for translating the IPvX packets into IPvY packets. In		responsible for translating the IPvX packets into IPvY packets. In
	this context, the tester device SHOULD be configured to support both		this context, the tester device SHOULD be configured to support both
	IPvX and IPvY.		IPvX and IPvY.
	+--------------------+		+--------------------+
	| |		| |
	+------------|IPvX tester IPvY|<-------------+		+------------|IPvX tester IPvY|<-------------+
	| | | |		| | | |
	| +--------------------+ |		| +--------------------+ |
	| |		| |
	| +--------------------+ |		| +--------------------+ |
	| | | |		| | | |
	+----------->|IPvX DUT IPvY|--------------+		+----------->|IPvX DUT IPvY|--------------+
	| |		| |
	+--------------------+		+--------------------+
	Figure 1. Test setup 1		Figure 1. Test setup 1
	4.2. Encapsulation/Double translation Transition Technologies		4.2. Encapsulation/Double translation Transition Technologies
	For evaluating the performance of Encapsulation and Double		For evaluating the performance of Encapsulation and Double
	translation transition technologies, a dual DUT setup (see Figure 2)		translation transition technologies, a dual DUT setup (see Figure 2)
	SHOULD be employed. The tester creates a network flow of IPvX		SHOULD be employed. The tester creates a network flow of IPvX
	packets. The first DUT is responsible for the encapsulation or		packets. The first DUT is responsible for the encapsulation or
	translation of IPvX packets into IPvY packets. The IPvY packets are		translation of IPvX packets into IPvY packets. The IPvY packets are
	de-encapsulated/translated back to IPvX packets by the second DUT		de-encapsulated/translated back to IPvX packets by the second DUT and
	and forwarded to the tester.		forwarded to the tester.
	+--------------------+		+--------------------+
	| |		| |
	+---------------------|IPvX tester IPvX|<------------------+		+---------------------|IPvX tester IPvX|<------------------+
	| | | |		| | | |
	| +--------------------+ |		| +--------------------+ |
	| |		| |
	| +--------------------+ +--------------------+ |		| +--------------------+ +--------------------+ |
	| | | | | |		| | | | | |
	+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+		+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
	| | | |		| | | |
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	Figure 2. Test setup 2		Figure 2. Test setup 2
	One of the limitations of the dual DUT setup is the inability to		One of the limitations of the dual DUT setup is the inability to
	reflect asymmetries in behavior between the DUTs. Considering this,		reflect asymmetries in behavior between the DUTs. Considering this,
	additional performance tests SHOULD be performed using the single		additional performance tests SHOULD be performed using the single DUT
	DUT setup.		setup.
	Note: For encapsulation IPv6 transition technologies, in the single		Note: For encapsulation IPv6 transition technologies, in the single
	DUT setup, in order to test the de-encapsulation efficiency, the		DUT setup, in order to test the de-encapsulation efficiency, the
	tester SHOULD be able to send IPvX packets encasulated as IPvY.		tester SHOULD be able to send IPvX packets encasulated as IPvY.
	5. Test Traffic		5. Test Traffic
	The test traffic represents the experimental workload and SHOULD		The test traffic represents the experimental workload and SHOULD meet
	meet the requirements specified in this section. The requirements		the requirements specified in this section. The requirements are
	are dedicated to unicast IP traffic. Multicast IP traffic is outside		dedicated to unicast IP traffic. Multicast IP traffic is outside of
	of the scope of this document.		the scope of this document.
	5.1. Frame Formats and Sizes		5.1. Frame Formats and Sizes
	[RFC5180] describes the frame size requirements for two commonly		[RFC5180] describes the frame size requirements for two commonly used
	used media types: Ethernet and SONET (Synchronous Optical Network).		media types: Ethernet and SONET (Synchronous Optical Network).
	[RFC2544] covers also other media types, such as token ring and		[RFC2544] covers also other media types, such as token ring and FDDI.
	FDDI. The recommendations of the two documents can be used for the		The recommendations of the two documents can be used for the dual-
	dual-stack transition technologies. For the rest of the transition		stack transition technologies. For the rest of the transition
	technologies, the frame overhead introduced by translation or		technologies, the frame overhead introduced by translation or
	encapsulation MUST be considered.		encapsulation MUST be considered.
	The encapsulation/translation process generates different size		The encapsulation/translation process generates different size frames
	frames on different segments of the test setup. For instance, the		on different segments of the test setup. For instance, the single
	single translation transition technologies will create different		translation transition technologies will create different frame sizes
	frame sizes on the receiving segment of the test setup, as IPvX		on the receiving segment of the test setup, as IPvX packets are
	packets are translated to IPvY. This is not a problem if the		translated to IPvY. This is not a problem if the bandwidth of the
	bandwidth of the employed media is not exceeded. To prevent		employed media is not exceeded. To prevent exceeding the limitations
	exceeding the limitations imposed by the media, the frame size		imposed by the media, the frame size overhead needs to be taken into
	overhead needs to be taken into account when calculating the maximum		account when calculating the maximum theoretical frame rates. The
	theoretical frame rates. The calculation method for the Ethernet, as		calculation method for the Ethernet, as well as a calculation
	well as a calculation example, are detailed in Appendix A. The		example, are detailed in Appendix A. The details of the media
	details of the media employed for the benchmarking tests MUST be		employed for the benchmarking tests MUST be noted in all test
	noted in all test reports.		reports.
	In the context of frame size overhead, MTU recommendations are		In the context of frame size overhead, MTU recommendations are needed
	needed in order to avoid frame loss due to MTU mismatch between the		in order to avoid frame loss due to MTU mismatch between the virtual
	virtual encapsulation/translation interfaces and the physical		encapsulation/translation interfaces and the physical network
	network interface controllers (NICs). To avoid this situation, the		interface controllers (NICs). To avoid this situation, the larger
	larger MTU between the physical NICs and virtual		MTU between the physical NICs and virtual encapsulation/translation
	encapsulation/translation interfaces SHOULD be set for all		interfaces SHOULD be set for all interfaces of the DUT and tester.
	interfaces of the DUT and tester. To be more specific, the minimum		To be more specific, the minimum IPv6 MTU size (1280 bytes) plus the
	IPv6 MTU size (1280 bytes) plus the encapsulation/translation		encapsulation/translation overhead is the RECOMMENDED value for the
	overhead is the RECOMMENDED value for the physical interfaces as		physical interfaces as well as virtual ones.
	well as virtual ones.
	5.1.1. Frame Sizes to Be Used over Ethernet		5.1.1. Frame Sizes to Be Used over Ethernet
	Based on the recommendations of [RFC5180], the following frame sizes		Based on the recommendations of [RFC5180], the following frame sizes
	SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links:		SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links:
	64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and		64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and
	9216.		9216.
	For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC]		For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC]
	standard can be consulted.		standard can be consulted.
	Note: for single translation transition technologies (e.g. NAT64) in		Note: for single translation transition technologies (e.g. NAT64) in
	the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be		the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be
	replaced by 84 byte frames. This would allow the frames to be		replaced by 84 byte frames. This would allow the frames to be
	transported over media such as the ones described by the IEEE 802.1Q		transported over media such as the ones described by the IEEE 802.1Q
	standard. Moreover, this would also allow the implementation of a		standard. Moreover, this would also allow the implementation of a
	frame identifier in the UDP data.		frame identifier in the UDP data.
	The theoretical maximum frame rates considering an example of frame		The theoretical maximum frame rates considering an example of frame
	overhead are presented in Appendix A.		overhead are presented in Appendix A.
	5.2. Protocol Addresses		5.2. Protocol Addresses
	The selected protocol addresses should follow the recommendations of		The selected protocol addresses should follow the recommendations of
	[RFC5180](Section 5) for IPv6 and [RFC2544](Section 12) for IPv4.		[RFC5180](Section 5) for IPv6 and [RFC2544](Section 12) for IPv4.
	Note: testing traffic with extension headers might not be possible		Note: testing traffic with extension headers might not be possible
	for the transition technologies, which employ translation. Proposed		for the transition technologies, which employ translation. Proposed
	IPvX/IPvY translation algorithms such as IP/ICMP translation		IPvX/IPvY translation algorithms such as IP/ICMP translation
	[RFC7915] do not support the use of extension headers.		[RFC7915] do not support the use of extension headers.
	5.3. Traffic Setup		5.3. Traffic Setup
	Following the recommendations of [RFC5180], all tests described		Following the recommendations of [RFC5180], all tests described
	SHOULD be performed with bi-directional traffic. Uni-directional		SHOULD be performed with bi-directional traffic. Uni-directional
	traffic tests MAY also be performed for a fine grained performance		traffic tests MAY also be performed for a fine grained performance
	assessment.		assessment.
	Because of the simplicity of UDP, UDP measurements offer a more		Because of the simplicity of UDP, UDP measurements offer a more
	reliable basis for comparison than other transport layer protocols.		reliable basis for comparison than other transport layer protocols.
	Consequently, for the benchmarking tests described in Section 7 of		Consequently, for the benchmarking tests described in Section 7 of
	this document UDP traffic SHOULD be employed.		this document UDP traffic SHOULD be employed.
	Considering that a transition technology could process both native		Considering that a transition technology could process both native
	IPv6 traffic and translated/encapsulated traffic, the following		IPv6 traffic and translated/encapsulated traffic, the following
	skipping to change at page 10, line 18		skipping to change at page 10, line 4
	reliable basis for comparison than other transport layer protocols.		reliable basis for comparison than other transport layer protocols.
	Consequently, for the benchmarking tests described in Section 7 of		Consequently, for the benchmarking tests described in Section 7 of
	this document UDP traffic SHOULD be employed.		this document UDP traffic SHOULD be employed.
	Considering that a transition technology could process both native		Considering that a transition technology could process both native
	IPv6 traffic and translated/encapsulated traffic, the following		IPv6 traffic and translated/encapsulated traffic, the following
	traffic setups are recommended:		traffic setups are recommended:
	i) IPvX only traffic (where the IPvX traffic is to be		i) IPvX only traffic (where the IPvX traffic is to be
	translated/encapsulated by the DUT)		translated/encapsulated by the DUT)
	ii) 90% IPvX traffic and 10% IPvY native traffic		ii) 90% IPvX traffic and 10% IPvY native traffic
	iii) 50% IPvX traffic and 50% IPvY native traffic		iii) 50% IPvX traffic and 50% IPvY native traffic iv) 10% IPvX
	iv) 10% IPvX traffic and 90% IPvY native traffic		traffic and 90% IPvY native traffic
	For the benchmarks dedicated to stateful IPv6 transition		For the benchmarks dedicated to stateful IPv6 transition
	technologies, included in Section 8 of this memo (Concurrent TCP		technologies, included in Section 8 of this memo (Concurrent TCP
	Connection Capacity and Maximum TCP Connection Establishment Rate),		Connection Capacity and Maximum TCP Connection Establishment Rate),
	the traffic SHOULD follow the recommendations of [RFC3511], Sections		the traffic SHOULD follow the recommendations of [RFC3511], Sections
	5.2.2.2 and 5.3.2.2.		5.2.2.2 and 5.3.2.2.
	6. Modifiers		6. Modifiers
	The idea of testing under different operational conditions was first		The idea of testing under different operational conditions was first
	introduced in [RFC2544](Section 11) and represents an important		introduced in [RFC2544](Section 11) and represents an important
	aspect of benchmarking network elements, as it emulates, to some		aspect of benchmarking network elements, as it emulates, to some
	extent, the conditions of a production environment. Section 6 of		extent, the conditions of a production environment. Section 6 of
	[RFC5180] describes complementary testing conditions specific to		[RFC5180] describes complementary testing conditions specific to
	IPv6. Their recommendations can also be followed for IPv6 transition		IPv6. Their recommendations can also be followed for IPv6 transition
	technologies testing.		technologies testing.
	7. Benchmarking Tests		7. Benchmarking Tests
	The following sub-sections contain the list of all recommended		The following sub-sections contain the list of all recommended
	benchmarking tests.		benchmarking tests.
	7.1. Throughput		7.1. Throughput
	Use Section 26.1 of RFC2544 unmodified.		Use Section 26.1 of RFC2544 unmodified.
	7.2. Latency		7.2. Latency
	Objective: To determine the latency. Typical latency is based on the		Objective: To determine the latency. Typical latency is based on the
	definitions of latency from [RFC1242]. However, this memo provides a		definitions of latency from [RFC1242]. However, this memo provides a
	new measurement procedure.		new measurement procedure.
	Procedure: Similar to [RFC2544], the throughput for DUT at each of		Procedure: Similar to [RFC2544], the throughput for DUT at each of
	the listed frame sizes SHOULD be determined. Send a stream of frames		the listed frame sizes SHOULD be determined. Send a stream of frames
	at a particular frame size through the DUT at the determined		at a particular frame size through the DUT at the determined
	throughput rate to a specific destination. The stream SHOULD be at		throughput rate to a specific destination. The stream SHOULD be at
	least 120 seconds in duration.		least 120 seconds in duration.
	Identifying tags SHOULD be included in at least 500 frames after 60		Identifying tags SHOULD be included in at least 500 frames after 60
	seconds. For each tagged frame, the time at which the frame was		seconds. For each tagged frame, the time at which the frame was
	fully transmitted (timestamp A) and the time at which the frame was		fully transmitted (timestamp A) and the time at which the frame was
	received (timestamp B) MUST be recorded. The latency is timestamp B		received (timestamp B) MUST be recorded. The latency is timestamp B
	minus timestamp A as per the relevant definition from RFC 1242,		minus timestamp A as per the relevant definition from RFC 1242,
	namely latency as defined for store and forward devices or latency		namely latency as defined for store and forward devices or latency as
	as defined for bit forwarding devices.		defined for bit forwarding devices.
	We recommend to encode the identifying tag in the payload of the		We recommend to encode the identifying tag in the payload of the
	frame. To be more exact, the identifier SHOULD be inserted after the		frame. To be more exact, the identifier SHOULD be inserted after the
	UDP header.		UDP header.
	From the resulted (at least 500) latencies, 2 quantities SHOULD be		From the resulted (at least 500) latencies, 2 quantities SHOULD be
	calculated. One is the typical latency, which SHOULD be calculated		calculated. One is the typical latency, which SHOULD be calculated
	with the following formula:		with the following formula:
	TL=Median(Li)		TL=Median(Li)
	Where: TL - the reported typical latency of the stream		Where: TL - the reported typical latency of the stream
	Li -the latency for tagged frame i		Li -the latency for tagged frame i
	The other measure is the worst case latency, which SHOULD be		The other measure is the worst case latency, which SHOULD be
	calculated with the following formula:		calculated with the following formula:
	WCL=L99.9thPercentile		WCL=L99.9thPercentile
	Where: WCL - The reported worst case latency		Where: WCL - The reported worst case latency
	L99.9thPercentile - The 99.9th Percentile of the stream measured		L99.9thPercentile - The 99.9th Percentile of the stream measured
	latencies		latencies
	The test MUST be repeated at least 20 times with the reported
	value being the median of the recorded values for TL and WCL.
	Reporting Format: The report MUST state which definition of latency		The test MUST be repeated at least 20 times with the reported
	(from RFC 1242) was used for this test. The summarized latency
	results SHOULD be reported in the format of a table with a row for
	each of the tested frame sizes. There SHOULD be columns for the
	frame size, the rate at which the latency test was run for that
	frame size, for the media types tested, and for the resultant
	typical latency and worst case latency values for each type of data
	stream tested. To account for the variation, the 1st and 99th
	percentiles of the 20 iterations MAY be reported in two separated
	columns. For a fine grained analysis, the histogram (as exemplified
	in [RFC5481] Section 4.4) of one of the iterations MAY be
	displayed .
	7.3. Packet Delay Variation		value being the median of the recorded values for TL and WCL.
			Reporting Format: The report MUST state which definition of
			latency
			(from RFC 1242) was used for this test. The summarized latency
			results SHOULD be reported in the format of a table with a row for
			each of the tested frame sizes. There SHOULD be columns for the
			frame size, the rate at which the latency test was run for that
			frame size, for the media types tested, and for the resultant
			typical latency and worst case latency values for each type of data
			stream tested. To account for the variation, the 1st and 99th
			percentiles of the 20 iterations MAY be reported in two separated
			columns. For a fine grained analysis, the histogram (as exemplified
			in [RFC5481] Section 4.4) of one of the iterations MAY be displayed
			.
			7.3. Packet Delay Variation
	Considering two of the metrics presented in [RFC5481], Packet Delay		Considering two of the metrics presented in [RFC5481], Packet Delay
	Variation (PDV) and Inter Packet Delay Variation (IPDV), it is		Variation (PDV) and Inter Packet Delay Variation (IPDV), it is
	RECOMMENDED to measure PDV. For a fine grained analysis of delay		RECOMMENDED to measure PDV. For a fine grained analysis of delay
	variation, IPDV measurements MAY be performed.		variation, IPDV measurements MAY be performed.
	7.3.1. PDV		7.3.1. PDV
	Objective: To determine the Packet Delay Variation as defined in		Objective: To determine the Packet Delay Variation as defined in
	[RFC5481].		[RFC5481].
	Procedure: As described by [RFC2544], first determine the throughput		Procedure: As described by [RFC2544], first determine the throughput
	for the DUT at each of the listed frame sizes. Send a stream of		for the DUT at each of the listed frame sizes. Send a stream of
	frames at a particular frame size through the DUT at the determined		frames at a particular frame size through the DUT at the determined
	throughput rate to a specific destination. The stream SHOULD be at		throughput rate to a specific destination. The stream SHOULD be at
	least 60 seconds in duration. Measure the One-way delay as described		least 60 seconds in duration. Measure the One-way delay as described
	by [RFC3393] for all frames in the stream. Calculate the PDV of the		by [RFC3393] for all frames in the stream. Calculate the PDV of the
	stream using the formula:		stream using the formula:
	PDV=D99.9thPercentile - Dmin		PDV=D99.9thPercentile - Dmin
	Where: D99.9thPercentile - the 99.9th Percentile (as it was		Where: D99.9thPercentile - the 99.9th Percentile (as it was
	described in [RFC5481]) of the One-way delay for the stream		described in [RFC5481]) of the One-way delay for the stream
	Dmin - the minimum One-way delay in the stream		Dmin - the minimum One-way delay in the stream
	As recommended in [RFC2544], the test MUST be repeated at least 20		As recommended in [RFC2544], the test MUST be repeated at least 20
	times with the reported value being the median of the recorded		times with the reported value being the median of the recorded
	values. Moreover, the 1st and 99th percentiles SHOULD be calculated		values. Moreover, the 1st and 99th percentiles SHOULD be calculated
	to account for the variation of the dataset.		to account for the variation of the dataset.
	Reporting Format: The PDV results SHOULD be reported in a table with		Reporting Format: The PDV results SHOULD be reported in a table with
	a row for each of the tested frame sizes and columns for the frame		a row for each of the tested frame sizes and columns for the frame
	size and the applied frame rate for the tested media types. Two		size and the applied frame rate for the tested media types. Two
	columns for the 1st and 99th percentile values MAY be displayed.		columns for the 1st and 99th percentile values MAY be displayed.
	Following the recommendations of [RFC5481], the RECOMMENDED units of		Following the recommendations of [RFC5481], the RECOMMENDED units of
	measurement are milliseconds.		measurement are milliseconds.
	7.3.2. IPDV		7.3.2. IPDV
	Objective: To determine the Inter Packet Delay Variation as defined		Objective: To determine the Inter Packet Delay Variation as defined
	in [RFC5481].		in [RFC5481].
	Procedure: As described by [RFC2544], first determine the throughput		Procedure: As described by [RFC2544], first determine the throughput
	for the DUT at each of the listed frame sizes. Send a stream of		for the DUT at each of the listed frame sizes. Send a stream of
	frames at a particular frame size through the DUT at the determined		frames at a particular frame size through the DUT at the determined
	throughput rate to a specific destination. The stream SHOULD be at		throughput rate to a specific destination. The stream SHOULD be at
	least 60 seconds in duration. Measure the One-way delay as described		least 60 seconds in duration. Measure the One-way delay as described
	by [RFC3393] for all frames in the stream. Calculate the IPDV for		by [RFC3393] for all frames in the stream. Calculate the IPDV for
	each of the frames using the formula:		each of the frames using the formula:
	IPDV(i)=D(i) - D(i-1)		IPDV(i)=D(i) - D(i-1)
	Where: D(i) - the One-way delay of the i th frame in the stream		Where: D(i) - the One-way delay of the i th frame in the stream
	D(i-1) - the One-way delay of i-1 th frame in the stream		D(i-1) - the One-way delay of i-1 th frame in the stream
	Given the nature of IPDV, reporting a single number might lead to		Given the nature of IPDV, reporting a single number might lead to
	over-summarization. In this context, the report for each measurement		over-summarization. In this context, the report for each measurement
	SHOULD include 3 values: Dmin, Dmed, and Dmax		SHOULD include 3 values: Dmin, Dmed, and Dmax
	Where: Dmin - the minimum IPDV in the stream		Where: Dmin - the minimum IPDV in the stream
	Dmed - the median IPDV of the stream		Dmed - the median IPDV of the stream
	Dmax - the maximum IPDV in the stream		Dmax - the maximum IPDV in the stream
	The test MUST be repeated at least 20 times. To summarize the 20		The test MUST be repeated at least 20 times. To summarize the 20
	repetitions, for each of the 3 (Dmin, Dmed and Dmax) the median		repetitions, for each of the 3 (Dmin, Dmed and Dmax) the median value
	value SHOULD be reported.		SHOULD be reported.
	Reporting format: The median for the 3 proposed values SHOULD be		Reporting format: The median for the 3 proposed values SHOULD be
	reported. The IPDV results SHOULD be reported in a table with a row		reported. The IPDV results SHOULD be reported in a table with a row
	for each of the tested frame sizes. The columns SHOULD include the		for each of the tested frame sizes. The columns SHOULD include the
	frame size and associated frame rate for the tested media types and		frame size and associated frame rate for the tested media types and
	sub-columns for the three proposed reported values. Following the		sub-columns for the three proposed reported values. Following the
	recommendations of [RFC5481], the RECOMMENDED units of measurement		recommendations of [RFC5481], the RECOMMENDED units of measurement
	are milliseconds.		are milliseconds.
	7.4. Frame Loss Rate		7.4. Frame Loss Rate
	Use Section 26.3 of [RFC2544] unmodified.		Use Section 26.3 of [RFC2544] unmodified.
	7.5. Back-to-back Frames		7.5. Back-to-back Frames
	Use Section 26.4 of [RFC2544] unmodified.		Use Section 26.4 of [RFC2544] unmodified.
	7.6. System Recovery		7.6. System Recovery
	Use Section 26.5 of [RFC2544] unmodified.		Use Section 26.5 of [RFC2544] unmodified.
	7.7. Reset		7.7. Reset
	Use Section 4 of [RFC6201] unmodified.		Use Section 4 of [RFC6201] unmodified.
	8. Additional Benchmarking Tests for Stateful IPv6 Transition		8. Additional Benchmarking Tests for Stateful IPv6 Transition
	Technologies		Technologies
	This section describes additional tests dedicated to the stateful		This section describes additional tests dedicated to the stateful
	IPv6 transition technologies. For the tests described in this		IPv6 transition technologies. For the tests described in this
	section, the DUT devices SHOULD follow the test setup and test		section, the DUT devices SHOULD follow the test setup and test
	parameters recommendations presented in [RFC3511] (Sections 5.2 and		parameters recommendations presented in [RFC3511] (Sections 5.2 and
	5.3)		5.3)
	The following additional tests SHOULD be performed.		The following additional tests SHOULD be performed.
	8.1. Concurrent TCP Connection Capacity		8.1. Concurrent TCP Connection Capacity
	Use Section 5.2 of [RFC3511] unmodified.		Use Section 5.2 of [RFC3511] unmodified.
	8.2. Maximum TCP Connection Establishment Rate		8.2. Maximum TCP Connection Establishment Rate
	Use Section 5.3 of RFC3511 unmodified.		Use Section 5.3 of RFC3511 unmodified.
	9. DNS Resolution Performance		9. DNS Resolution Performance
	This section describes benchmarking tests dedicated to DNS64 (see		This section describes benchmarking tests dedicated to DNS64 (see
	[RFC6147]), used as DNS support for single translation technologies		[RFC6147]), used as DNS support for single translation technologies
	such as NAT64.		such as NAT64.
	9.1. Test and Traffic Setup		9.1. Test and Traffic Setup
	The test setup in Figure 3 follows the setup proposed for single		The test setup in Figure 3 follows the setup proposed for single
	translation IPv6 transition technologies in Figure 1.		translation IPv6 transition technologies in Figure 1.
	1:AAAA query +--------------------+		1:AAAA query +--------------------+
	+------------| |<-------------+		+------------| |<-------------+
	| |IPv6 Tester IPv4| |		| |IPv6 Tester IPv4| |
	| +-------->| |----------+ |		| +-------->| |----------+ |
	| | +--------------------+ 3:empty | |		| | +--------------------+ 3:empty | |
	| | 6:synt'd AAAA, | |		| | 6:synt'd AAAA, | |
	| | AAAA +--------------------+ 5:valid A| |		| | AAAA +--------------------+ 5:valid A| |
	| +---------| |<---------+ |		| +---------| |<---------+ |
	| |IPv6 DUT IPv4| |		| |IPv6 DUT IPv4| |
	+----------->| (DNS64) |--------------+		+----------->| (DNS64) |--------------+
	+--------------------+ 2:AAAA query, 4:A query		+--------------------+ 2:AAAA query, 4:A query
	Figure 3. DNS64 test setup		Figure 3. DNS64 test setup
	The test traffic SHOULD follow the following steps.		The test traffic SHOULD follow the following steps.
	1. Query for the AAAA record of a domain name (from client to DNS64		1. Query for the AAAA record of a domain name (from client to DNS64
	server)		server)
	2. Query for the AAAA record of the same domain name (from DNS64		2. Query for the AAAA record of the same domain name (from DNS64
	server to authoritative DNS server)		server to authoritative DNS server)
	3. Empty AAAA record answer (from authoritative DNS server to DNS64		3. Empty AAAA record answer (from authoritative DNS server to DNS64
	server)		server)
			4. Query for the A record of the same domain name (from DNS64 server
	4. Query for the A record of the same domain name (from DNS64 server
	to authoritative DNS server)		to authoritative DNS server)
	5. Valid A record answer (from authoritative DNS server to DNS64		5. Valid A record answer (from authoritative DNS server to DNS64
	server)		server)
	6. Synthesized AAAA record answer (from DNS64 server to client)		1. Synthesized AAAA record answer (from DNS64 server to client)
	The Tester plays the role of DNS client as well as authoritative DNS		The Tester plays the role of DNS client as well as authoritative DNS
	server. It MAY be realized as a single physical device, or		server. It MAY be realized as a single physical device, or
	alternatively, two physical devices MAY be used.		alternatively, two physical devices MAY be used.
	Please note that:		Please note that:
	- If the DNS64 server implements caching and there is a cache		- If the DNS64 server implements caching and there is a cache hit,
	hit, then step 1 is followed by step 6 (and steps 2 through 5		then step 1 is followed by step 6 (and steps 2 through 5 are
	are omitted).		omitted).
	- If the domain name has an AAAA record, then it is returned in		- If the domain name has an AAAA record, then it is returned in
	step 3 by the authoritative DNS server; steps 4 and 5 are		step 3 by the authoritative DNS server; steps 4 and 5 are
	omitted, and the DNS64 server does not synthesizes an AAAA		omitted, and the DNS64 server does not synthesizes an AAAA
	record, but returns the received AAAA record to the client.		record, but returns the received AAAA record to the client.
			- As for the IP version used between the tester and the DUT, IPv6
			MUST be used between the client and the DNS64 server (as a DNS64
			server provides service for an IPv6-only client), but either
			IPv4 or IPv6 MAY be used between the DNS64 server and the
			authoritative DNS server.
	- As for the IP version used between the tester and the DUT, IPv6		9.2. Benchmarking DNS Resolution Performance
	MUST be used between the client and the DNS64 server (as a
	DNS64 server provides service for an IPv6-only client), but
	either IPv4 or IPv6 MAY be used between the DNS64 server and
	the authoritative DNS server.
	9.2. Benchmarking DNS Resolution Performance
	Objective: To determine DNS64 performance by means of the maximum		Objective: To determine DNS64 performance by means of the maximum
	number of successfully processed DNS requests per second.		number of successfully processed DNS requests per second.
	Procedure: Send a specific number of DNS queries at a specific rate		Procedure: Send a specific number of DNS queries at a specific rate
	to the DUT and then count the replies received in time (within a		to the DUT and then count the replies received in time (within a
	predefined timeout period from the sending time of the corresponding		predefined timeout period from the sending time of the corresponding
	query, having the default value 1 second) and valid (contains an		query, having the default value 1 second) and valid (contains an AAAA
	AAAA record) from the DUT. If the count of sent queries is equal to		record) from the DUT. If the count of sent queries is equal to the
	the count of received replies, the rate of the queries is raised and		count of received replies, the rate of the queries is raised and the
	the test is rerun. If fewer replies are received than queries were		test is rerun. If fewer replies are received than queries were sent,
	sent, the rate of the queries is reduced and the test is rerun. The		the rate of the queries is reduced and the test is rerun. The
	duration of each trial SHOULD be at least 60 seconds. This will		duration of each trial SHOULD be at least 60 seconds. This will
	reduce the potential gain of a DNS64 server, which is able to		reduce the potential gain of a DNS64 server, which is able to exhibit
	exhibit higher performance by storing the requests and thus		higher performance by storing the requests and thus utilizing also
	utilizing also the timeout time for answering them. For the same		the timeout time for answering them. For the same reason, no higher
	reason, no higher timeout time than 1 second SHOULD be used. For		timeout time than 1 second SHOULD be used. For further
	further considerations, see [Lencse1].		considerations, see [Lencse1].
	The maximum number of processed DNS queries per second is the		The maximum number of processed DNS queries per second is the fastest
	fastest rate at which the count of DNS replies sent by the DUT is		rate at which the count of DNS replies sent by the DUT is equal to
	equal to the number of DNS queries sent to it by the test equipment.		the number of DNS queries sent to it by the test equipment.
	The test SHOULD be repeated at least 20 times and the median and 1st		The test SHOULD be repeated at least 20 times and the median and 1st
	/99th percentiles of the number of processed DNS queries per second		/99th percentiles of the number of processed DNS queries per second
	SHOULD be calculated.		SHOULD be calculated.
	Details and parameters:		Details and parameters:
	1. Caching		1. Caching
	First, all the DNS queries MUST contain different domain names (or		First, all the DNS queries MUST contain different domain names (or
	domain names MUST NOT be repeated before the cache of the DUT is		domain names MUST NOT be repeated before the cache of the DUT is
	skipping to change at page 17, line 9		skipping to change at page 16, line 32
	and "early enough" to be still present in the cache.		and "early enough" to be still present in the cache.
	2. Existence of AAAA record		2. Existence of AAAA record
	First, all the DNS queries MUST contain domain names which do not		First, all the DNS queries MUST contain domain names which do not
	have an AAAA record and have exactly one A record.		have an AAAA record and have exactly one A record.
	Then new tests MAY be executed with domain names, 20%, 40%, 60%, 80%		Then new tests MAY be executed with domain names, 20%, 40%, 60%, 80%
	and 100% of which have an AAAA record.		and 100% of which have an AAAA record.
	Please note that the two conditions above are orthogonal, thus all		Please note that the two conditions above are orthogonal, thus all
	their combinations are possible and MAY be tested. The testing with		their combinations are possible and MAY be tested. The testing with
	0% cached domain names and with 0% existing AAAA record is REQUIRED		0% cached domain names and with 0% existing AAAA record is REQUIRED
	and the other combinations are OPTIONAL. (When all the domain names		and the other combinations are OPTIONAL. (When all the domain names
	are cached, then the results do not depend on what percentage of the		are cached, then the results do not depend on what percentage of the
	domain names have AAAA records, thus these combinations are not		domain names have AAAA records, thus these combinations are not worth
	worth testing one by one.)		testing one by one.)
	Reporting format: The primary result of the DNS64 test is the median		Reporting format: The primary result of the DNS64 test is the median
	of the number of processed DNS queries per second measured with the		of the number of processed DNS queries per second measured with the
	above mentioned "0% + 0% combination". The median SHOULD be		above mentioned "0% + 0% combination". The median SHOULD be
	complemented with the 1st and 99th percentiles to show the stability		complemented with the 1st and 99th percentiles to show the stability
	of the result. If optional tests are done, the median and the 1st		of the result. If optional tests are done, the median and the 1st
	and 99th percentiles MAY be presented in a two dimensional table		and 99th percentiles MAY be presented in a two dimensional table
	where the dimensions are the proportion of the repeated domain names		where the dimensions are the proportion of the repeated domain names
	and the proportion of the DNS names having AAAA records. The two		and the proportion of the DNS names having AAAA records. The two
	table headings SHOULD contain these percentage values.		table headings SHOULD contain these percentage values.
	Alternatively, the results MAY be presented as the corresponding two		Alternatively, the results MAY be presented as the corresponding two
	dimensional graph, too. In this case the graph SHOULD show the		dimensional graph, too. In this case the graph SHOULD show the
	median values with the percentiles as error bars. From both the		median values with the percentiles as error bars. From both the
	table and the graph, one dimensional excerpts MAY be made at any		table and the graph, one dimensional excerpts MAY be made at any
	given fixed percentage value of the other dimension. In this case,		given fixed percentage value of the other dimension. In this case,
	the fixed value MUST be given together with a one dimensional table		the fixed value MUST be given together with a one dimensional table
	or graph.		or graph.
	9.2.1. Requirements for the Tester		9.2.1. Requirements for the Tester
	Before a Tester can be used for testing a DUT at rate r queries per		Before a Tester can be used for testing a DUT at rate r queries per
	second with t seconds timeout, it MUST perform a self-test in order		second with t seconds timeout, it MUST perform a self-test in order
	to exclude the possibility that the poor performance of the Tester		to exclude the possibility that the poor performance of the Tester
	itself influences the results. For performing a self-test, the		itself influences the results. For performing a self-test, the
	tester is looped back (leaving out DUT) and its authoritative DNS		tester is looped back (leaving out DUT) and its authoritative DNS
	server subsystem is configured to be able to answer all the AAAA		server subsystem is configured to be able to answer all the AAAA
	record queries. For passing the self-test, the Tester SHOULD be able		record queries. For passing the self-test, the Tester SHOULD be able
	to answer AAAA record queries at 2*(r+delta) rate within 0.25*t		to answer AAAA record queries at 2*(r+delta) rate within 0.25*t
	timeout, where the value of delta is at least 0.1.		timeout, where the value of delta is at least 0.1.
	Explanation: When performing DNS64 testing, each AAAA record query		Explanation: When performing DNS64 testing, each AAAA record query
	may result in at most two queries sent by the DUT, the first one of		may result in at most two queries sent by the DUT, the first one of
	them is for an AAAA record and the second one is for an A record		them is for an AAAA record and the second one is for an A record (the
	(the are both sent when there is no cache hit and also no AAAA		are both sent when there is no cache hit and also no AAAA record
	record exists). The parameters above guarantee that the		exists). The parameters above guarantee that the authoritative DNS
	authoritative DNS server subsystem of the DUT is able to answer the		server subsystem of the DUT is able to answer the queries at the
	queries at the required frequency using up not more than the half of		required frequency using up not more than the half of the timeout
	the timeout time.		time.
	Remark: a sample open-source test program, dns64perf++, is available		Remark: a sample open-source test program, dns64perf++, is available
	from [Dns64perf] and it is documented in [Lencse2]. It implements		from [Dns64perf] and it is documented in [Lencse2]. It implements
	only the client part of the Tester and it should be used together		only the client part of the Tester and it should be used together
	with an authoritative DNS server implementation, e.g. BIND, NSD or		with an authoritative DNS server implementation, e.g. BIND, NSD or
	YADIFA. Its experimental extension for testing caching is available		YADIFA. Its experimental extension for testing caching is available
	from [Lencse3] and it is documented in [Lencse4].		from [Lencse3] and it is documented in [Lencse4].
	10. Overload Scalability		10. Overload Scalability
	Scalability has been often discussed; however, in the context of		Scalability has been often discussed; however, in the context of
	network devices, a formal definition or a measurement method has not		network devices, a formal definition or a measurement method has not
	yet been proposed. In this context, we can define overload		yet been proposed. In this context, we can define overload
	scalability as the ability of each transition technology to		scalability as the ability of each transition technology to
	accommodate network growth. Poor scalability usually leads to poor		accommodate network growth. Poor scalability usually leads to poor
	performance. Considering this, overload scalability can be measured		performance. Considering this, overload scalability can be measured
	by quantifying the network performance degradation associated with		by quantifying the network performance degradation associated with an
	an increased number of network flows.		increased number of network flows.
	The following subsections describe how the test setups can be		The following subsections describe how the test setups can be
	modified to create network growth and how the associated performance		modified to create network growth and how the associated performance
	degradation can be quantified.		degradation can be quantified.
	10.1. Test Setup		10.1. Test Setup
	The test setups defined in Section 3 have to be modified to create		The test setups defined in Section 3 have to be modified to create
	network growth.		network growth.
	10.1.1. Single Translation Transition Technologies		10.1.1. Single Translation Transition Technologies
	In the case of single translation transition technologies the		In the case of single translation transition technologies the network
	network growth can be generated by increasing the number of network		growth can be generated by increasing the number of network flows
	flows generated by the tester machine (see Figure 4).		generated by the tester machine (see Figure 4).
	+-------------------------+		+-------------------------+
	+------------|NF1 NF1|<-------------+		+------------|NF1 NF1|<-------------+
	| +---------|NF2 tester NF2|<----------+ |		| +---------|NF2 tester NF2|<----------+ |
	| | ...| | | |		| | ...| | | |
	| | +-----|NFn NFn|<------+ | |		| | +-----|NFn NFn|<------+ | |
	| | | +-------------------------+ | | |		| | | +-------------------------+ | | |
	| | | | | |		| | | | | |
	| | | +-------------------------+ | | |		| | | +-------------------------+ | | |
	| | +---->|NFn NFn|-------+ | |		| | +---->|NFn NFn|-------+ | |
	| | ...| DUT | | |		| | ...| DUT | | |
	| +-------->|NF2 (translator) NF2|-----------+ |		| +-------->|NF2 (translator) NF2|-----------+ |
	+----------->|NF1 NF1|--------------+		+----------->|NF1 NF1|--------------+
	+-------------------------+		+-------------------------+
	Figure 4. Test setup 3		Figure 4. Test setup 3
	10.1.2. Encapsulation/Double Translation Transition Technologies		10.1.2. Encapsulation/Double Translation Transition Technologies
	Similarly, for the encapsulation/double translation technologies a		Similarly, for the encapsulation/double translation technologies a
	multi-flow setup is recommended. Considering a multipoint-to-point		multi-flow setup is recommended. Considering a multipoint-to-point
	scenario, for most transition technologies, one of the edge nodes is		scenario, for most transition technologies, one of the edge nodes is
	designed to support more than one connecting devices. Hence, the		designed to support more than one connecting devices. Hence, the
	recommended test setup is a n:1 design, where n is the number of		recommended test setup is a n:1 design, where n is the number of
	client DUTs connected to the same server DUT (See Figure 5).		client DUTs connected to the same server DUT (See Figure 5).
	+-------------------------+		+-------------------------+
	+--------------------|NF1 NF1|<--------------+		+--------------------|NF1 NF1|<--------------+
	| +-----------------|NF2 tester NF2|<-----------+ |		| +-----------------|NF2 tester NF2|<-----------+ |
	| | ...| | | |		| | ...| | | |
	| | +-------------|NFn NFn|<-------+ | |		| | +-------------|NFn NFn|<-------+ | |
	| | | +-------------------------+ | | |		| | | +-------------------------+ | | |
	| | | | | |		| | | | | |
	skipping to change at page 19, line 44		skipping to change at page 19, line 35
	device. However, for testing the overload scalability of the client		device. However, for testing the overload scalability of the client
	DUTs additional recommendations are needed.		DUTs additional recommendations are needed.
	For encapsulation transition technologies, a m:n setup can be		For encapsulation transition technologies, a m:n setup can be
	created, where m is the number of flows applied to the same client		created, where m is the number of flows applied to the same client
	device and n the number of client devices connected to the same		device and n the number of client devices connected to the same
	server device.		server device.
	For the translation based transition technologies, the client		For the translation based transition technologies, the client
	devices can be separately tested with n network flows using the test		devices can be separately tested with n network flows using the test
	setup presented in Figure 4.		setup presented in Figure 4.
	10.2. Benchmarking Performance Degradation		10.2. Benchmarking Performance Degradation
	10.2.1. Network performance degradation with simultaneous load		10.2.1. Network performance degradation with simultaneous load
	Objective: To quantify the performance degradation introduced by n		Objective: To quantify the performance degradation introduced by n
	parallel and simultaneous network flows.		parallel and simultaneous network flows.
	Procedure: First, the benchmarking tests presented in Section 7 have		Procedure: First, the benchmarking tests presented in Section 7 have
	to be performed for one network flow.		to be performed for one network flow.
	The same tests have to be repeated for n network flows, where the		The same tests have to be repeated for n network flows, where the
	network flows are started simultaneously. The performance		network flows are started simultaneously. The performance
	degradation of the X benchmarking dimension SHOULD be calculated as		degradation of the X benchmarking dimension SHOULD be calculated as
	relative performance change between the 1-flow (single flow) results		relative performance change between the 1-flow (single flow) results
	and the n-flow results, using the following formula:		and the n-flow results, using the following formula:
	Xn - X1		Xn - X1
	Xpd= ----------- * 100, where: X1 - result for 1-flow		Xpd= ----------- * 100, where: X1 - result for 1-flow
	X1 Xn - result for n-flows		X1 Xn - result for n-flows
	This formula SHOULD be applied only for lower is better benchmarks		This formula SHOULD be applied only for lower is better benchmarks
	(e.g. latency).		(e.g. latency).
	skipping to change at page 20, line 30		skipping to change at page 20, line 24
	X1 - Xn		X1 - Xn
	Xpd= ----------- * 100, where: X1 - result for 1-flow		Xpd= ----------- * 100, where: X1 - result for 1-flow
	X1 Xn - result for n-flows		X1 Xn - result for n-flows
	As a guideline for the maximum number of flows n, the value can be		As a guideline for the maximum number of flows n, the value can be
	deduced by measuring the Concurrent TCP Connection Capacity as		deduced by measuring the Concurrent TCP Connection Capacity as
	described by [RFC3511], following the test setups specified by		described by [RFC3511], following the test setups specified by
	Section 4.		Section 4.
	Reporting Format: The performance degradation SHOULD be expressed as		Reporting Format: The performance degradation SHOULD be expressed as
	a percentage. The number of tested parallel flows n MUST be clearly		a percentage. The number of tested parallel flows n MUST be clearly
	specified. For each of the performed benchmarking tests, there		specified. For each of the performed benchmarking tests, there
	SHOULD be a table containing a column for each frame size. The table		SHOULD be a table containing a column for each frame size. The table
	SHOULD also state the applied frame rate. In the case of benchmarks		SHOULD also state the applied frame rate. In the case of benchmarks
	for which more than one value is reported (e.g. IPDV Section 7.3.2),		for which more than one value is reported (e.g. IPDV Section 7.3.2),
	a column for each of the values SHOULD be included.		a column for each of the values SHOULD be included.
	10.2.2. Network performance degradation with incremental load		10.2.2. Network performance degradation with incremental load
	Objective: To quantify the performance degradation introduced by n		Objective: To quantify the performance degradation introduced by n
	parallel and incrementally started network flows.		parallel and incrementally started network flows.
	Procedure: First, the benchmarking tests presented in Section 7 have		Procedure: First, the benchmarking tests presented in Section 7 have
	to be performed for one network flow.		to be performed for one network flow.
	The same tests have to be repeated for n network flows, where the		The same tests have to be repeated for n network flows, where the
	network flows are started incrementally in succession, each after		network flows are started incrementally in succession, each after
	time t. In other words, if flow i is started at time x, flow i+1		time t. In other words, if flow i is started at time x, flow i+1
	will be started at time x+t. Considering the time t, the time		will be started at time x+t. Considering the time t, the time
	duration of each iteration must be extended with the time necessary		duration of each iteration must be extended with the time necessary
	to start all the flows, namely (n-1)xt. The measurement for the		to start all the flows, namely (n-1)xt. The measurement for the
	first flow SHOULD be at least 60 seconds in duration.		first flow SHOULD be at least 60 seconds in duration.
	The performance degradation of the x benchmarking dimension SHOULD		The performance degradation of the x benchmarking dimension SHOULD be
	be calculated as relative performance change between the 1-flow		calculated as relative performance change between the 1-flow results
	results and the n-flow results, using the formula presented in		and the n-flow results, using the formula presented in
	Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n and		Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n and
	3/4*n MAY also be performed.		3/4*n MAY also be performed.
	Reporting Format: The performance degradation SHOULD be expressed as		Reporting Format: The performance degradation SHOULD be expressed as
	a percentage. The number of tested parallel flows n MUST be clearly		a percentage. The number of tested parallel flows n MUST be clearly
	specified. For each of the performed benchmarking tests, there		specified. For each of the performed benchmarking tests, there
	SHOULD be a table containing a column for each frame size. The table		SHOULD be a table containing a column for each frame size. The table
	SHOULD also state the applied frame rate and time duration T, used		SHOULD also state the applied frame rate and time duration T, used as
	as increment step between the network flows. The units of		increment step between the network flows. The units of measurement
	measurement for T SHOULD be seconds. A column for the intermediary		for T SHOULD be seconds. A column for the intermediary degradation
	degradation points MAY also be displayed. In the case of benchmarks		points MAY also be displayed. In the case of benchmarks for which
	for which more than one value is reported (e.g. IPDV Section 7.3.2),		more than one value is reported (e.g. IPDV Section 7.3.2), a column
	a column for each of the values SHOULD be included.		for each of the values SHOULD be included.
	11. NAT44 and NAT66		11. NAT44 and NAT66
	Although these technologies are not the primary scope of this		Although these technologies are not the primary scope of this
	document, the benchmarking methodology associated with single		document, the benchmarking methodology associated with single
	translation technologies as defined in Section 4.1 can be employed		translation technologies as defined in Section 4.1 can be employed to
	to benchmark NAT44 (as defined by [RFC2663] with the behavior		benchmark NAT44 (as defined by [RFC2663] with the behavior described
	described by [RFC7857]) implementations and NAT66 (as defined by		by [RFC7857]) implementations and NAT66 (as defined by [RFC6296])
	[RFC6296]) implementations.		implementations.
	12. Summarizing function and variation		12. Summarizing function and variation
	To ensure the stability of the benchmarking scores obtained using		To ensure the stability of the benchmarking scores obtained using the
	the tests presented in Sections 7 through 9, multiple test		tests presented in Sections 7 through 9, multiple test iterations are
	iterations are RECOMMENDED. Using a summarizing function (or measure		RECOMMENDED. Using a summarizing function (or measure of central
	of central tendency) can be a simple and effective way to compare		tendency) can be a simple and effective way to compare the results
	the results obtained across different iterations. However, over-		obtained across different iterations. However, over- summarization
	summarization is an unwanted effect of reporting a single number.		is an unwanted effect of reporting a single number.
	Measuring the variation (dispersion index) can be used to counter		Measuring the variation (dispersion index) can be used to counter the
	the over-summarization effect. Empirical data obtained following the		over-summarization effect. Empirical data obtained following the
	proposed methodology can also offer insights on which summarizing		proposed methodology can also offer insights on which summarizing
	function would fit better.		function would fit better.
	To that end, data presented in [ietf95pres] indicate the median as		To that end, data presented in [ietf95pres] indicate the median as
	suitable summarizing function and the 1st and 99th percentiles as		suitable summarizing function and the 1st and 99th percentiles as
	variation measures for DNS Resolution Performance and PDV. The		variation measures for DNS Resolution Performance and PDV. The
	median and percentile calculation functions SHOULD follow the		median and percentile calculation functions SHOULD follow the
	recommendations of [RFC2330] Section 11.3.		recommendations of [RFC2330] Section 11.3.
	For a fine grained analysis of the frequency distribution of the		For a fine grained analysis of the frequency distribution of the
	data, histograms or cumulative distribution function plots can be		data, histograms or cumulative distribution function plots can be
	employed.		employed.
	13. Security Considerations		13. Security Considerations
	Benchmarking activities as described in this memo are limited to		Benchmarking activities as described in this memo are limited to
	technology characterization using controlled stimuli in a laboratory		technology characterization using controlled stimuli in a laboratory
	environment, with dedicated address space and the constraints		environment, with dedicated address space and the constraints
	specified in the sections above.		specified in the sections above.
	The benchmarking network topology will be an independent test setup		The benchmarking network topology will be an independent test setup
	and MUST NOT be connected to devices that may forward the test		and MUST NOT be connected to devices that may forward the test
	traffic into a production network, or misroute traffic to the test		traffic into a production network, or misroute traffic to the test
	management network.		management network.
	Further, benchmarking is performed on a "black-box" basis, relying		Further, benchmarking is performed on a "black-box" basis, relying
	solely on measurements observable external to the DUT/SUT. Special		solely on measurements observable external to the DUT/SUT. Special
	capabilities SHOULD NOT exist in the DUT/SUT specifically for		capabilities SHOULD NOT exist in the DUT/SUT specifically for
	benchmarking purposes. Any implications for network security arising		benchmarking purposes. Any implications for network security arising
	from the DUT/SUT SHOULD be identical in the lab and in production		from the DUT/SUT SHOULD be identical in the lab and in production
	networks.		networks.
	14. IANA Considerations		14. IANA Considerations
	The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6		The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6
	benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was		benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was
	reserved, as described in [RFC6890]. The two ranges are sufficient		reserved, as described in [RFC6890]. The two ranges are sufficient
	for benchmarking IPv6 transition technologies. Thus, no action is		for benchmarking IPv6 transition technologies. Thus, no action is
	requested.		requested.
	15. References		15. References
	15.1. Normative References
	[RFC1242] Bradner, S., "Benchmarking Terminology for Network		15.1. Normative References
	Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
	July 1991, <http://www.rfc-editor.org/info/rfc1242>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC1242] Bradner, S., "Benchmarking Terminology for Network
	Requirement Levels", BCP 14, RFC 2119, DOI		Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
	10.17487/RFC2119, March 1997, <http://www.rfc-		July 1991, <http://www.rfc-editor.org/info/rfc1242>.
	editor.org/info/rfc2119>.
	[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	"Framework for IP performance metrics", RFC 2330, DOI		Requirement Levels", BCP 14, RFC 2119,
	10.17487/RFC2330, May 1998, <http://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2330>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2544] Bradner, S., and J. McQuaid, "Benchmarking Methodology for		[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
	Network Interconnect Devices", RFC 2544, DOI		"Framework for IP Performance Metrics", RFC 2330,
	10.17487/RFC2544, March 1999, <http://www.rfc-		DOI 10.17487/RFC2330, May 1998,
	editor.org/info/rfc2544>.		<http://www.rfc-editor.org/info/rfc2330>.
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
	Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI		Network Interconnect Devices", RFC 2544,
	10.17487/RFC3393, November 2002, <http://www.rfc-		DOI 10.17487/RFC2544, March 1999,
	editor.org/info/rfc3393>.		<http://www.rfc-editor.org/info/rfc2544>.
	[RFC3511] Hickman, B., Newman, D., Tadjudin, S. and T. Martin,		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	"Benchmarking Methodology for Firewall Performance", RFC		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	3511, DOI 10.17487/RFC3511, April 2003, <http://www.rfc-		DOI 10.17487/RFC3393, November 2002,
	editor.org/info/rfc3511>.		<http://www.rfc-editor.org/info/rfc3393>.
	[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.		[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
	Dugatkin, "IPv6 Benchmarking Methodology for Network		"Benchmarking Methodology for Firewall Performance",
	Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May		RFC 3511, DOI 10.17487/RFC3511, April 2003,
	2008, <http://www.rfc-editor.org/info/rfc5180>.		<http://www.rfc-editor.org/info/rfc3511>.
	[RFC5481] Morton, A., and B. Claise, "Packet Delay Variation		[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
	Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,		Dugatkin, "IPv6 Benchmarking Methodology for Network
	March 2009, <http://www.rfc-editor.org/info/rfc5481>.		Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May
			2008, <http://www.rfc-editor.org/info/rfc5180>.
	[RFC6201] Asati, R., Pignataro, C., Calabria, F. and C. Olvera,		[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
	"Device Reset Characterization ", RFC 6201, DOI		Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
	10.17487/RFC6201, March 2011, <http://www.rfc-		March 2009, <http://www.rfc-editor.org/info/rfc5481>.
	editor.org/info/rfc6201>.
	15.2. Informative References		[RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera,
			"Device Reset Characterization", RFC 6201,
			DOI 10.17487/RFC6201, March 2011,
			<http://www.rfc-editor.org/info/rfc6201>.
	[RFC2663] Srisuresh, P., and M. Holdrege. "IP Network Address		15.2. Informative References
	Translator (NAT) Terminology and Considerations", RFC2663,
	DOI 10.17487/RFC2663, August 1999, <http://www.rfc-
	editor.org/info/rfc2663>.
	[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms		[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
	for IPv6 Hosts and Routers", RFC 4213, DOI		for IPv6 Hosts and Routers", RFC 4213,
	10.17487/RFC4213, October 2005, <http://www.rfc-		DOI 10.17487/RFC4213, October 2005,
	editor.org/info/rfc4213>.		<http://www.rfc-editor.org/info/rfc4213>.
	[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,		[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
	"BGP-MPLS IP Virtual Private Network (VPN) Extension for		"BGP-MPLS IP Virtual Private Network (VPN) Extension for
	IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-		IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
	editor.org/info/4659>.		<http://www.rfc-editor.org/info/rfc4659>.
	[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,		[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
	"Connecting IPv6 Islands over IPv4 MPLS Using IPv6		"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
	Provider Edge Routers (6PE)", RFC 4798, February 2007,		Provider Edge Routers (6PE)", RFC 4798,
	<http://www.rfc-editor.org/info/rfc4798>		DOI 10.17487/RFC4798, February 2007,
			<http://www.rfc-editor.org/info/rfc4798>.
	[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
	Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
	January 2010, <http://www.rfc-editor.org/info/rfc5569>.
	[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
	IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
	April 2011, <http://www.rfc-editor.org/info/rfc6144>.
	[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
	NAT64: Network Address and Protocol Translation from IPv6
	Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
	April 2011, <http://www.rfc-editor.org/info/rfc6146>.
	[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
	Beijnum, "DNS64: DNS Extensions for Network Address
	Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
	DOI 10.17487/RFC6147, April 2011, <http://www.rfc-
	editor.org/info/rfc6147>.
	[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
	China Education and Research Network (CERNET) IVI
	Translation Design and Deployment for the IPv4/IPv6
	Coexistence and Transition", RFC 6219, DOI
	10.17487/RFC6219, May 2011, <http://www.rfc-
	editor.org/info/rfc6219>.
	[RFC6296] Wasserman, M., and F. Baker. "IPv6-to-IPv6 network prefix
	translation." RFC6296, DOI 10.17487/RFC6296, June 2011.
	[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4
	Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
	<http://www.rfc-editor.org/info/rfc6333>.
	[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
	Combination of Stateful and Stateless Translation", RFC
	6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-
	editor.org/info/rfc6877>.
	[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
	"Special-Purpose IP Address Registries", BCP 153, RFC6890,
	DOI 10.17487/RFC6890, April 2013, <http://www.rfc-
	editor.org/info/rfc6890>.
	[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
	Farrer, "Lightweight 4over6: An Extension to the Dual-
	Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
	July 2015, <http://www.rfc-editor.org/info/rfc7596>.
	[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Murakami, T., and T. Taylor, Ed., "Mapping of Address and
	Port with Encapsulation (MAP-E)", RFC 7597, DOI
	10.17487/RFC7597, July 2015, <http://www.rfc-
	editor.org/info/rfc7597>.
	[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,		[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
	and T. Murakami, "Mapping of Address and Port using		Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
	Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July		January 2010, <http://www.rfc-editor.org/info/rfc5569>.
	2015, <http://www.rfc-editor.org/info/rfc7599>.
	[RFC7857] Penno, R., Perreault, S., Boucadair, M., Sivakumar, S.,		[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
	and K. Naito "Updates to Network Address Translation (NAT)		IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
	Behavioral Requirements" RFC 7857, DOI 10.17487/RFC7857,		April 2011, <http://www.rfc-editor.org/info/rfc6144>.
	April 2016, <http://www.rfc-editor.org/info/rfc7857>.
	[RFC7915] LBao, C., Li, X., Baker, F., Anderson, T., and F. Gont,		[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
	"IP/ICMP Translation Algorithm", RFC 7915, DOI		NAT64: Network Address and Protocol Translation from IPv6
	10.17487/RFC7915, June 2016, <http://www.rfc-		Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
	editor.org/info/rfc7915>.		April 2011, <http://www.rfc-editor.org/info/rfc6146>.
	[Dns64perf] Bakai, D., "A C++11 DNS64 performance tester",		[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
	available: https://github.com/bakaid/dns64perfpp		Beijnum, "DNS64: DNS Extensions for Network Address
			Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
			DOI 10.17487/RFC6147, April 2011,
			<http://www.rfc-editor.org/info/rfc6147>.
	[ietf95pres] Georgescu, M., "Benchmarking Methodology for IPv6		[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
	Transition Technologies", IETF 95, Buenos Aires,		China Education and Research Network (CERNET) IVI
	Argentina, April 2016, available:		Translation Design and Deployment for the IPv4/IPv6
	https://www.ietf.org/proceedings/95/slides/slides-95-bmwg-		Coexistence and Transition", RFC 6219,
	2.pdf		DOI 10.17487/RFC6219, May 2011,
			<http://www.rfc-editor.org/info/rfc6219>.
	[Lencse1] Lencse, G., Georgescu, M. and Y. Kadobayashi,		[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	"Benchmarking Methodology for DNS64 Servers", unpublished,		Stack Lite Broadband Deployments Following IPv4
	revised version is available:		Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
	http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M-		<http://www.rfc-editor.org/info/rfc6333>.
	DNS64-revised.pdf
	[Lencse2] Lencse, G., Bakai, D, "Design and Implementation of a Test		[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
	Program for Benchmarking DNS64 Servers", IEICE		Combination of Stateful and Stateless Translation",
	Transactions on Communications, vol. E100-B, no. 6. pp.		RFC 6877, DOI 10.17487/RFC6877, April 2013,
	948-954, (June 2017), freely available from:		<http://www.rfc-editor.org/info/rfc6877>.
	http://doi.org/10.1587/transcom.2016EBN0007
	[Lencse3] http://www.hit.bme.hu/~lencse/dns64perfppc/		[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
			Farrer, "Lightweight 4over6: An Extension to the Dual-
			Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
			July 2015, <http://www.rfc-editor.org/info/rfc7596>.
	[Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the		[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Caching Performance of DNS64 Servers", unpublished, review		Murakami, T., and T. Taylor, Ed., "Mapping of Address and
	version is available:		Port with Encapsulation (MAP-E)", RFC 7597,
	http://www.hit.bme.hu/~lencse/publications/IEICE-2016-		DOI 10.17487/RFC7597, July 2015,
	dns64perfppc-for-review.pdf		<http://www.rfc-editor.org/info/rfc7597>.
	[IEEE802.1AC-2016] IEEE Standard, "802.1AC-2016 - IEEE Standard for		[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
	Local and metropolitan area networks -- Media Access		and T. Murakami, "Mapping of Address and Port using
	Control (MAC) Service Definition", 2016, available:		Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
	https://standards.ieee.org/findstds/standard/802.1AC-		2015, <http://www.rfc-editor.org/info/rfc7599>.
	2016.html
	16. Acknowledgements		[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
			"IP/ICMP Translation Algorithm", RFC 7915,
			DOI 10.17487/RFC7915, June 2016,
			<http://www.rfc-editor.org/info/rfc7915>.
	The authors would like to thank Youki Kadobayashi and Hiroaki		[Lencse3] , <http://www.hit.bme>.
	Hazeyama for their constant feedback and support. The thanks should
	be extended to the NECOMA project members for their continuous
	support. The thank you list should also include Emanuel Popa, Ionut
	Spirlea and the RCS&RDS IP/MPLS Backbone Team for their support and
	insights. We would also like to thank Scott Bradner for the useful
	suggestions. We also note that portions of text from Scott's
	documents were used in this memo (e.g. Latency section). A big thank
	you to Al Morton and Fred Baker for their detailed review of the
	draft and very helpful suggestions. Other helpful comments and
	suggestions were offered by Bhuvaneswaran Vengainathan, Andrew
	McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka
	Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich
	and Stenio Fernandes. A special thank you to the RFC Editor Team for
	their thorough editorial review and helpful suggestions. This
	document was prepared using 2-Word-v2.0.template.dot.
	Appendix A. Theoretical Maximum Frame Rates		Appendix A. Theoretical Maximum Frame Rates
	This appendix describes the recommended calculation formulas for the		This appendix describes the recommended calculation formulas for the
	theoretical maximum frame rates to be employed over Ethernet as		theoretical maximum frame rates to be employed over Ethernet as
	example media. The formula takes into account the frame size		example media. The formula takes into account the frame size
	overhead created by the encapsulation or the translation process.		overhead created by the encapsulation or the translation process.
	For example, the 6in4 encapsulation described in [RFC4213] adds 20		For example, the 6in4 encapsulation described in [RFC4213] adds 20
	bytes of overhead to each frame.		bytes of overhead to each frame.
	Considering X to be the frame size and O to be the frame size		Considering X to be the frame size and O to be the frame size
	overhead created by the encapsulation on translation process, the		overhead created by the encapsulation on translation process, the
	maximum theoretical frame rate for Ethernet can be calculated using		maximum theoretical frame rate for Ethernet can be calculated using
	the following formula:		the following formula:
	Line Rate (bps)		Line Rate (bps)
	------------------------------		------------------------------
	(8bits/byte)*(X+O+20)bytes/frame		(8bits/byte)*(X+O+20)bytes/frame
	The calculation is based on the formula recommended by RFC5180 in		The calculation is based on the formula recommended by RFC5180 in
	Appendix A1. As an example, the frame rate recommended for testing a		Appendix A1. As an example, the frame rate recommended for testing a
	6in4 implementation over 10Mb/s Ethernet with 64 bytes frames is:		6in4 implementation over 10Mb/s Ethernet with 64 bytes frames is:
	10,000,000(bps)		10,000,000(bps)
	------------------------------ = 12,019 fps		------------------------------ = 12,019 fps
	(8bits/byte)*(64+20+20)bytes/frame		(8bits/byte)*(64+20+20)bytes/frame
	The complete list of recommended frame rates for 6in4 encapsulation		The complete list of recommended frame rates for 6in4 encapsulation
	can be found in the following table:		can be found in the following table:
	+------------+---------+----------+-----------+------------+		+------------+------------+------------+-------------+--------------+
	| Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |		| Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
	| (bytes) | (fps) | (fps) | (fps) | (fps) |		| (bytes) | (fps) | (fps) | (fps) | (fps) |
	+------------+---------+----------+-----------+------------+		+------------+------------+------------+-------------+--------------+
	| 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 |		| 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 |
	| 128 | 7,440 | 74,405 | 744,048 | 7,440,476 |		| 128 | 7,440 | 74,405 | 744,048 | 7,440,476 |
	| 256 | 4,223 | 42,230 | 422,297 | 4,222,973 |		| 256 | 4,223 | 42,230 | 422,297 | 4,222,973 |
	| 512 | 2,264 | 22,645 | 226,449 | 2,264,493 |		| 512 | 2,264 | 22,645 | 226,449 | 2,264,493 |
	| 678 | 1,740 | 17,409 | 174,094 | 1,740,947 |		| 678 | 1,740 | 17,409 | 174,094 | 1,740,947 |
	| 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 |		| 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 |
	| 1280 | 947 | 9,470 | 94,697 | 946,970 |		| 1280 | 947 | 9,470 | 94,697 | 946,970 |
	| 1518 | 802 | 8,023 | 80,231 | 802,311 |		| 1518 | 802 | 8,023 | 80,231 | 802,311 |
	| 1522 | 800 | 8,003 | 80,026 | 800,256 |		| 1522 | 800 | 8,003 | 80,026 | 800,256 |
	| 2048 | 599 | 5,987 | 59,866 | 598,659 |		| 2048 | 599 | 5,987 | 59,866 | 598,659 |
	| 4096 | 302 | 3,022 | 30,222 | 302,224 |		| 4096 | 302 | 3,022 | 30,222 | 302,224 |
	| 8192 | 152 | 1,518 | 15,185 | 151,846 |		| 8192 | 152 | 1,518 | 15,185 | 151,846 |
	| 9216 | 135 | 1,350 | 13,505 | 135,048 |		| 9216 | 135 | 1,350 | 13,505 | 135,048 |
	+------------+---------+----------+-----------+------------+		+------------+------------+------------+-------------+--------------+
	Authors' Addresses		Authors' Addresses
	Marius Georgescu		Marius Georgescu
	RCS&RDS		RCS&RDS
	Strada Dr. Nicolae D. Staicovici 71-75		Strada Dr. Nicolae D. Staicovici 71-75
	Bucharest 030167		Bucharest 030167
	Romania		Romania
	Phone: +40 31 005 0979		Phone: +40 31 005 0979
	Email: marius.georgescu@rcs-rds.ro		Email: marius.georgescu@rcs-rds.ro
	Liviu Pislaru		Liviu Pislaru
End of changes. 185 change blocks.
	585 lines changed or deleted		501 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

mirror server hosted at Truenetwork, Russian Federation.