Our siitperf is the world’s first RFC 8219 compliant free software SIIT (Stateless IP/ICMP Translation, also called stateless NAT64) benchmarking tool. It was written in C++ using DPDK (Intel Data ...Plane Development Kit). Our current effort aims to design and implement a test program for stateful NATxy gateways, including both stateful NAT64 and stateful NAT44 (also called NAPT: Network Address and Port Translation). Due to the object-oriented design of siitperf, it is feasible to extend it for stateful tests, while keeping its original design and features. In this paper, we introduce the problem of benchmarking stateful NATxy gateways and propose various solutions. We disclose the design and the most important implementation decisions of the stateful extension of siitperf. We prove the viability of our design and implementation by a functional NAT64 test and performing the maximum connection establishment rate, throughput, and frame loss rate measurements of the Jool stateful NAT64 implementation. We also carry out an initial performance estimation of the stateful extension of siitperf. Our tester is distributed as free software under the GPLv3 license for the benefit of the research, benchmarking and networking communities.
Display omitted
•The problem of benchmarking stateful NATxy (x, y ∈ {4, 6}) gateways is analyzed.•A solution using port range limiting, preliminary phase, and state table is proposed.•Pseudorandom enumeration of all possible port number combinations is used.•The design of an RFC 8219 and RFC 4814 compliant stateful NATxy Tester is disclosed.•The method is validated with sample benchmarking of a Jool stateful NAT64 gateway.
DNS64 and NAT64 are IPv6 transition technologies enabling IPv6 only clients to communicate with IPv4 only servers. Mtd64-ng is a novel DNS64 implementation, being a successor of MTD64. In this paper, ...the performance of mtd64-ng is compared with that of MTD64 and BIND. The details of the measurements are fully disclosed. It is found that under heavy load conditions mtd64-ng can answer six times as many “AAAA” record requests per second than BIND. Mtd64-ng fixed two issues of MTD64 and also outperformed its predecessor by answering 46% more “AAAA” record requests per second under heavy load conditions.
In the current stage of IPv6 deployment, the combination of DNS64 and NAT64 is an important IPv6 transition technology, which can be used to enable IPv6 only clients to communicate with IPv4 only ...servers. In addition to the existing free software DNS64 implementations, we proposed a tiny multithreaded one, MTD64.In this paper, the performance of MTD64 is measured and compared to that of the industry standard BIND in order to check the correctness of the design concepts of MTD64, especially of the one that we use a new thread for each request. For the performance measurements, our earlier proposed dns64perf program is enhanced as dns64perf2, which one is also documented in this paper. We found that MTD64 seriously outperformed BIND and hence our design principles may be useful for the design of a high performance production class DNS64 server. As an additional test, we have also examined the effect of dynamic CPU frequency scaling to the performance of the implementations.
In our earlier research papers, bash shell scripts using the host Linux command were applied for testing the performance and stability of different DNS64 server implementations. Because of their ...inefficiency, a small multi-threaded C/C++ program (named dns64perf) was written which can directly send DNS AAAA record queries. After the introduction to the essential theoretical background about the structure of DNS messages and TCP/IP socket interface programming, the design decisions and implementation details of our DNS64 performance test program are disclosed. The efficiency of dns64perf is compared to that of the old method using bash shell scripts. The result is convincing: dns64perf can send at least 95 times more DNS AAAA record queries per second. The source code of dns64perf is published under the GNU GPLv3 license to support the work of other researchers in the field of testing the performance of DNS64 servers.
Nowadays we use Internet Protocol (IP) versions 4 (IPv4) and 6 (IPv6) at the same time. It is very difficult to determine the rate of IPv6 and the state of its deployment exactly. In our survey, ...paper we present some tools and methods that can be used to estimate the proportion of IPv6. First, we will show some server side methods that mostly use provider-measurable data, so they may not be available to everyone. Next, we introduce various client-side tools that can be used in a much broader context, and then present the use of survey methods. Then we are reviewing some researches, which provide more comprehensive insight into the transition to IPv6 using complex measurement methods. Finally, we compare and categorize the presented metrics based on the availability of data sources and the extent of the measurement duration. We know that there is clearly no best among the various methods. Choosing the right technique depends greatly on the data and tools available to the researcher.
In this paper, the viability of the throughput and frame loss rate benchmarking procedures of RFC 8219 is tested by executing them to examine the performance of three free software SIIT (also called ...stateless NAT64) implementations: Jool, TAYGA, and map646. An important methodological problem of the two tested benchmarking procedures is pointed out: they use improper timeout setting. A solution of individually checking the timeout for each frame is proposed to get more reasonable results, and its feasibility is demonstrated. The unreliability of the results caused by the lack of requirement for repeated tests is also pointed out, and the need for relevant number of tests is demonstrated. The possibility of an optional non-zero frame loss acceptance criterion for throughput measurement is also discussed. The benchmarking measurements are performed using two different computer hardware, and all relevant results are disclosed and compared. The performance of the kernel based Jool was found to scale up well with the number of active CPU cores and Jool also significantly outperformed the two other SIIT implementations, which work in the user space.
Display omitted
•The Jool, TAYGA and map646 SIIT (stateless NAT64) implementations are benchmarked.•Throughput and frame loss rate are measured complying RFC 8219 (based on RFC 2544).•Possible methodological problems are pointed out in the RFC 2544 measurements.•Three possible improvements of the benchmarking procedures are proposed.•A comprehensive performance comparison of the SIIT implementations is also provided.
Abstract In this paper, we focus on one of the most prominent IPv6 transition technologies, namely Mapping of Address and Port using Translation (MAP-T), and we give attention to Mapping of Address ...and Port with Encapsulation (MAP-E) as well. We emphasize the uniqueness of MAP-T and MAP-E, and we discuss the differences between those two technologies, including their topology, functionality, and security vulnerabilities. We apply a threat modeling technique, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE), to assess potential vulnerabilities in the MAP-T infrastructure. Furthermore, we build a testbed for MAP-T using the open-source software, Jool, and we conduct testing on the translation process capabilities of Jool and its port allocation per subscriber. Finally, we present various attacking scenarios against the main routers of MAP-T, such as IP address spoofing, information disclosure, and source port exhaustion, and we propose mitigation methods for several attacks.
In this paper, we examine the performance of four authoritative DNS server implementations (BIND, NSD, Knot DNS, and YADIFA). In our tests, we apply the measurement procedure defined in Section 9 of ...RFC 8219. Our aim is threefold: to provide DNS operators with ready to use measurement results to support their selection of the best fitting authoritative DNS server implementation for their needs, to assist researchers and DNS64 server developers in finding a suitable authoritative DNS server implementation for their DNS64 benchmarking measurements, and to advance the theory and practice of benchmarking DNS servers. We examine how the different conditions such as the number of active CPU cores, the size of the zone file, the applied timeout, and the type of the processor influence the performance of the tested authoritative DNS server implementations. The performance of all four tested DNS servers scales up more or less well with the number of CPU cores, except for YADIFA. The increase of the size of the zone file causes significant degradation only in the performance of BIND, which shows different anomalies described in the paper. The change of the timeout from 250ms (required by RFC 8219) to 100ms usually causes only a small performance degradation. We point out that NSD and Knot DNS can achieve an order of magnitude higher performance than BIND and YADIFA.
•A methodology is proposed for the threat analysis of IPv6 transition technologies.•Our methodology amends a previous one based on the STRIDE approach.•The previous method was complemented with two ...levels.•The viability of our method is proven on the comprehensive threat analysis of DNS64.•Its effectiveness is proven by the systematic uncovering of all the known threats.
Display omitted
We are faced with the transition from IPv4 to IPv6, which will last for several years or possibly decades. There are different IPv6 transition technologies, which enable the communication between hosts using the two incompatible versions of the Internet Protocol in various scenarios, but they also involve additional security issues. In this paper, we develop a methodology for the identification of potential security issues of different IPv6 transition technologies and their implementations based on the STRIDE approach and its application to IPv6 transition technologies. Our methodology includes the application of the STRIDE approach at two levels: the level of the individual IPv6 transition technologies and the level of their selected implementations. We demonstrate the operation and viability of our methodology by the detailed threat analysis of the DNS64 technology, and we prove the necessity of the implementation level analysis with several examples. We also include the most interesting highlights of the security analysis of the stateful NAT64 IPv6 transition technology. We also make a survey of the published vulnerabilities of DNS64 and NAT64 in different research papers and show the effectiveness of our systematic method by uncovering the threats of DNS64 and NAT64. Finally, we point out the need for the in-depth security analysis of the DNS64 technology and its most important implementations.
PDF
