tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8219

 
 
 

Benchmarking Methodology for IPv6 Transition Technologies

Part 2 of 2, p. 11 to 30
Prev Section

 


prevText      Top      ToC       Page 11 
7.  Benchmarking Tests

   The following sub-sections describe all recommended benchmarking
   tests.

7.1.  Throughput

   Use Section 26.1 of [RFC2544] unmodified.

7.2.  Latency

   Objective: To determine the latency.  Typical latency is based on the
   definitions of latency from [RFC1242].  However, this memo provides a
   new measurement procedure.

   Procedure: Similar to [RFC2544], the throughput for DUT at each of
   the listed frame sizes SHOULD be determined.  Send a stream of frames
   at a particular frame size through the DUT at the determined
   throughput rate to a specific destination.  The stream SHOULD be at
   least 120 seconds in duration.

Top      Up      ToC       Page 12 
   Identifying tags SHOULD be included in at least 500 frames after 60
   seconds.  For each tagged frame, 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
   minus timestamp A as per the relevant definition from RFC 1242,
   namely, latency as defined for store and forward devices or latency
   as defined for bit forwarding devices.

   We recommend encoding the identifying tag in the payload of the
   frame.  To be more exact, the identifier SHOULD be inserted after the
   UDP header.

   From the resulted (at least 500) latencies, two quantities SHOULD be
   calculated.  One is the typical latency, which SHOULD be calculated
   with the following formula:

   TL = Median(Li)

   Where:

   o  TL = the reported typical latency of the stream

   o  Li = the latency for tagged frame i

   The other measure is the worst-case latency, which SHOULD be
   calculated with the following formula:

   WCL = L99.9thPercentile

   Where:

   o  WCL = the reported worst-case latency

   o  L99.9thPercentile = the 99.9th percentile of the stream-measured
      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
   (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, the media types tested, and the resultant typical latency, and
   the worst-case latency values for each type of data stream tested.
   To account for the variation, the 1st and 99th percentiles of the 20

Top      Up      ToC       Page 13 
   iterations MAY be reported in two separated columns.  For a fine-
   grained analysis, the histogram (as exemplified in Section 4.4 of
   [RFC5481]) of one of the iterations MAY be displayed.

7.3.  Packet Delay Variation

   [RFC5481] presents two metrics: Packet Delay Variation (PDV) and
   Inter Packet Delay Variation (IPDV).  Measuring PDV is RECOMMENDED;
   for a fine-grained analysis of delay variation, IPDV measurements MAY
   be performed.

7.3.1.  PDV

   Objective: To determine the Packet Delay Variation as defined in
   [RFC5481].

   Procedure: As described by [RFC2544], first determine the throughput
   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
   throughput rate to a specific destination.  The stream SHOULD be at
   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
   stream using the formula:

   PDV = D99.9thPercentile - Dmin

   Where:

   o  D99.9thPercentile = the 99.9th percentile (as described in
      [RFC5481]) of the one-way delay for the stream

   o  Dmin = the minimum one-way delay in the stream

   As recommended in [RFC2544], the test MUST be repeated at least 20
   times with the reported value being the median of the recorded
   values.  Moreover, the 1st and 99th percentiles SHOULD be calculated
   to account for the variation of the dataset.

   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
   size and the applied frame rate for the tested media types.  Two
   columns for the 1st and 99th percentile values MAY be displayed.
   Following the recommendations of [RFC5481], the RECOMMENDED units of
   measurement are milliseconds.

Top      Up      ToC       Page 14 
7.3.2.  IPDV

   Objective: To determine the Inter Packet Delay Variation as defined
   in [RFC5481].

   Procedure: As described by [RFC2544], first determine the throughput
   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
   throughput rate to a specific destination.  The stream SHOULD be at
   least 60 seconds in duration.  Measure the one-way delay as described
   by [RFC3393] for all frames in the stream.  Calculate the IPDV for
   each of the frames using the formula:

   IPDV(i) = D(i) - D(i-1)

   Where:

   o  D(i) = the one-way delay of the i-th frame in the stream

   o  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
   over-summarization.  In this context, the report for each measurement
   SHOULD include three values: Dmin, Dmed, and Dmax.

   Where:

   o  Dmin = the minimum IPDV in the stream

   o  Dmed = the median IPDV of the stream

   o  Dmax = the maximum IPDV in the stream

   The test MUST be repeated at least 20 times.  To summarize the 20
   repetitions, for each of the three (Dmin, Dmed, and Dmax), the median
   value SHOULD be reported.

   Reporting format: The median for the three proposed values SHOULD be
   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
   frame size and associated frame rate for the tested media types and
   sub-columns for the three proposed reported values.  Following the
   recommendations of [RFC5481], the RECOMMENDED units of measurement
   are milliseconds.

Top      Up      ToC       Page 15 
7.4.  Frame Loss Rate

   Use Section 26.3 of [RFC2544] unmodified.

7.5.  Back-to-Back Frames

   Use Section 26.4 of [RFC2544] unmodified.

7.6.  System Recovery

   Use Section 26.5 of [RFC2544] unmodified.

7.7.  Reset

   Use Section 4 of [RFC6201] unmodified.

8.  Additional Benchmarking Tests for Stateful IPv6 Transition
    Technologies

   This section describes additional tests dedicated to stateful IPv6
   transition technologies.  For the tests described in this section,
   the DUT devices SHOULD follow the test setup and test parameters
   recommendations presented in Sections 5.2 and 5.3 of [RFC3511].

   The following additional tests SHOULD be performed.

8.1.  Concurrent TCP Connection Capacity

   Use Section 5.2 of [RFC3511] unmodified.

8.2.  Maximum TCP Connection Establishment Rate

   Use Section 5.3 of [RFC3511] unmodified.

9.  DNS Resolution Performance

   This section describes benchmarking tests dedicated to DNS64 (see
   [RFC6147]), used as DNS support for single-translation technologies
   such as NAT64.

Top      Up      ToC       Page 16 
9.1.  Test and Traffic Setup

   The test setup in Figure 3 follows the setup proposed for single-
   translation IPv6 transition technologies in Figure 1.

      1:AAAA query    +--------------------+
         +------------|                    |<-------------+
         |            |IPv6   Tester   IPv4|              |
         |  +-------->|                    |----------+   |
         |  |         +--------------------+ 3:empty  |   |
         |  | 6:synt'd                         AAAA,  |   |
         |  |   AAAA  +--------------------+ 5:valid A|   |
         |  +---------|                    |<---------+   |
         |            |IPv6     DUT    IPv4|              |
         +----------->|       (DNS64)      |--------------+
                      +--------------------+ 2:AAAA query, 4:A query

                   Figure 3: Test Setup 3 (DNS64)

   The test traffic SHOULD be composed of the following messages.

   1.  Query for the AAAA record of a domain name (from client to DNS64
       server)

   2.  Query for the AAAA record of the same domain name (from DNS64
       server to authoritative DNS server)

   3.  Empty AAAA record answer (from authoritative DNS server to DNS64
       server)

   4.  Query for the A record of the same domain name (from DNS64 server
       to authoritative DNS server)

   5.  Valid A record answer (from authoritative DNS server to DNS64
       server)

   6.  Synthesized AAAA record answer (from DNS64 server to client)

   The Tester plays the role of DNS client as well as authoritative DNS
   server.  It MAY be realized as a single physical device, or
   alternatively, two physical devices MAY be used.

   Please note that:

   o  If the DNS64 server implements caching and there is a cache hit,
      then step 1 is followed by step 6 (and steps 2 through 5 are
      omitted).

Top      Up      ToC       Page 17 
   o  If the domain name has a AAAA record, then it is returned in step
      3 by the authoritative DNS server, steps 4 and 5 are omitted, and
      the DNS64 server does not synthesize a AAAA record but returns the
      received AAAA record to the client.

   o  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.

9.2.  Benchmarking DNS Resolution Performance

   Objective: To determine DNS64 performance by means of the maximum
   number of successfully processed DNS requests per second.

   Procedure: Send a specific number of DNS queries at a specific rate
   to the DUT, and then count the replies from the DUT that are received
   in time (within a predefined timeout period from the sending time of
   the corresponding query, having the default value 1 second) and that
   are valid (contain a AAAA record).  If the count of sent queries is
   equal to the count of received replies, the rate of the queries is
   raised, and the test is rerun.  If fewer replies are received than
   queries were sent, 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 reduce the potential gain of a DNS64 server, which is able
   to exhibit higher performance by storing the requests and thus also
   utilizing the timeout time for answering them.  For the same reason,
   no higher timeout time than 1 second SHOULD be used.  For further
   considerations, see [Lencse1].

   The maximum number of processed DNS queries per second is the fastest
   rate at which the count of DNS replies sent by the DUT is equal to
   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/99th percentiles of the number of processed DNS queries per
   second SHOULD be calculated.

   Details and parameters:

   1.  Caching

       First, all the DNS queries MUST contain different domain names
       (or domain names MUST NOT be repeated before the cache of the DUT
       is exhausted).  Then, new tests MAY be executed when domain names
       are 20%, 40%, 60%, 80%, and 100% cached.  Ensuring that a record

Top      Up      ToC       Page 18 
       is cached requires repeating a domain name both "late enough"
       after the first query to be already resolved and be present in
       the cache and "early enough" to be still present in the cache.

   2.  Existence of a AAAA record

       First, all the DNS queries MUST contain domain names that do not
       have a AAAA record and have exactly one A record.  Then, new
       tests MAY be executed when 20%, 40%, 60%, 80%, and 100% of domain
       names have a AAAA record.

   Please note that the two conditions above are orthogonal; thus, all
   their combinations are possible and MAY be tested.  The testing with
   0% cached domain names and with 0% existing AAAA records is REQUIRED,
   and the other combinations are OPTIONAL.  (When all the domain names
   are cached, then the results do not depend on what percentage of the
   domain names have AAAA records; thus, these combinations are not
   worth testing one by one.)

   Reporting format: The primary result of the DNS64 test is the median
   of the number of processed DNS queries per second measured with the
   above mentioned "0% + 0% combination".  The median SHOULD be
   complemented with the 1st and 99th percentiles to show the stability
   of the result.  If optional tests are done, the median and the 1st
   and 99th percentiles MAY be presented in a two-dimensional table
   where the dimensions are the proportion of the repeated domain names
   and the proportion of the DNS names having AAAA records.  The two
   table headings SHOULD contain these percentage values.
   Alternatively, the results MAY be presented as a corresponding two-
   dimensional graph.  In this case, the graph SHOULD show the median
   values with the percentiles as error bars.  From both the table and
   the graph, one-dimensional excerpts MAY be made at any given fixed-
   percentage value of the other dimension.  In this case, the fixed
   value MUST be given together with a one-dimensional table or graph.

9.2.1.  Requirements for the Tester

   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
   to exclude the possibility that the poor performance of the Tester
   itself influences the results.  To perform a self-test, the Tester is
   looped back (leaving out DUT), and its authoritative DNS server
   subsystem is configured to be able to answer all the AAAA record
   queries.  To pass the self-test, the Tester SHOULD be able to answer
   AAAA record queries at rate of 2*(r+delta) within a 0.25*t timeout,
   where the value of delta is at least 0.1.

Top      Up      ToC       Page 19 
   Explanation: When performing DNS64 testing, each AAAA record query
   may result in at most two queries sent by the DUT: the first for a
   AAAA record and the second for an A record (they are both sent when
   there is no cache hit and also no AAAA record exists).  The
   parameters above guarantee that the authoritative DNS server
   subsystem of the DUT is able to answer the queries at the required
   frequency using up not more than half of the timeout time.

   Note: A sample open-source test program, dns64perf++, is available
   from [Dns64perf] and is documented in [Lencse2].  It implements only
   the client part of the Tester and should be used together with an
   authoritative DNS server implementation, e.g., BIND, NSD, or YADIFA.
   Its experimental extension for testing caching is available from
   [Lencse3] and is documented in [Lencse4].

10.  Overload Scalability

   Scalability has been often discussed; however, in the context of
   network devices, a formal definition or a measurement method has not
   yet been proposed.  In this context, we can define overload
   scalability as the ability of each transition technology to
   accommodate network growth.  Poor scalability usually leads to poor
   performance.  Considering this, overload scalability can be measured
   by quantifying the network performance degradation associated with an
   increased number of network flows.

   The following subsections describe how the test setups can be
   modified to create network growth and how the associated performance
   degradation can be quantified.

10.1.  Test Setup

   The test setups defined in Section 4 have to be modified to create
   network growth.

10.1.1.  Single-Translation Transition Technologies

   In the case of single-translation transition technologies, the
   network growth can be generated by increasing the number of network
   flows (NFs) generated by the Tester machine (see Figure 4).

Top      Up      ToC       Page 20 
                        +-------------------------+
           +------------|NF1                   NF1|<-------------+
           |  +---------|NF2      Tester       NF2|<----------+  |
           |  |      ...|                         |           |  |
           |  |   +-----|NFn                   NFn|<------+   |  |
           |  |   |     +-------------------------+       |   |  |
           |  |   |                                       |   |  |
           |  |   |     +-------------------------+       |   |  |
           |  |   +---->|NFn                   NFn|-------+   |  |
           |  |      ...|           DUT           |           |  |
           |  +-------->|NF2    (translator)   NF2|-----------+  |
           +----------->|NF1                   NF1|--------------+
                        +-------------------------+

                 Figure 4: Test Setup 4 (Single DUT with Increased
                              Network Flows)

10.1.2.  Encapsulation and Double-Translation Transition Technologies

   Similarly, for the encapsulation and double-translation transition
   technologies, a multi-flow setup is recommended.  Considering a
   multipoint-to-point scenario, for most transition technologies, one
   of the edge nodes is designed to support more than one connecting
   device.  Hence, the recommended test setup is an n:1 design, where n
   is the number of client DUTs connected to the same server DUT (see
   Figure 5).

                          +-------------------------+
     +--------------------|NF1                   NF1|<--------------+
     |  +-----------------|NF2      Tester       NF2|<-----------+  |
     |  |              ...|                         |            |  |
     |  |   +-------------|NFn                   NFn|<-------+   |  |
     |  |   |             +-------------------------+        |   |  |
     |  |   |                                                |   |  |
     |  |   |    +-----------------+    +---------------+    |   |  |
     |  |   +--->| NFn  DUT n  NFn |--->|NFn         NFn| ---+   |  |
     |  |        +-----------------+    |               |        |  |
     |  |     ...                       |               |        |  |
     |  |        +-----------------+    |     DUT n+1   |        |  |
     |  +------->| NF2  DUT 2  NF2 |--->|NF2         NF2|--------+  |
     |           +-----------------+    |               |           |
     |           +-----------------+    |               |           |
     +---------->| NF1  DUT 1  NF1 |--->|NF1         NF1|-----------+
                 +-----------------+    +---------------+

                Figure 5: Test Setup 5 (DUAL DUT with Increased
                             Network Flows)

Top      Up      ToC       Page 21 
   This test setup can help to quantify the scalability of the server
   device.  However, for testing the overload scalability of the client
   DUTs, additional recommendations are needed.

   For encapsulation transition technologies, an m:n setup can be
   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
   server device.

   For translation-based transition technologies, the client devices can
   be separately tested with n network flows using the test setup
   presented in Figure 4.

10.2.  Benchmarking Performance Degradation

10.2.1.  Network Performance Degradation with Simultaneous Load

   Objective: To quantify the performance degradation introduced by n
   parallel and simultaneous network flows.

   Procedure: First, the benchmarking tests presented in Section 7 have
   to be performed for one network flow.

   The same tests have to be repeated for n network flows, where the
   network flows are started simultaneously.  The performance
   degradation of the X benchmarking dimension SHOULD be calculated as
   relative performance change between the 1-flow (single flow) results
   and the n-flow results, using the following formula:

               Xn - X1
       Xpd = ----------- * 100, where: X1 = result for 1-flow
                  X1                   Xn = result for n-flows

   This formula SHOULD be applied only for "lower is better" benchmarks
   (e.g., latency).  For "higher is better" benchmarks (e.g.,
   throughput), the following formula is RECOMMENDED:

               X1 - Xn
       Xpd = ----------- * 100, where: X1 = result for 1-flow
                  X1                   Xn = result for n-flows

   As a guideline for the maximum number of flows n, the value can be
   deduced by measuring the Concurrent TCP Connection Capacity as
   described by [RFC3511], following the test setups specified by
   Section 4.

Top      Up      ToC       Page 22 
   Reporting Format: The performance degradation SHOULD be expressed as
   a percentage.  The number of tested parallel flows n MUST be clearly
   specified.  For each of the performed benchmarking tests, there
   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
   for which more than one value is reported (e.g., IPDV, discussed in
   Section 7.3.2), a column for each of the values SHOULD be included.

10.2.2.  Network Performance Degradation with Incremental Load

   Objective: To quantify the performance degradation introduced by n
   parallel and incrementally started network flows.

   Procedure: First, the benchmarking tests presented in Section 7 have
   to be performed for one network flow.

   The same tests have to be repeated for n network flows, where the
   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
   will be started at time x+t.  Considering the time t, the time
   duration of each iteration must be extended with the time necessary
   to start all the flows, namely, (n-1)xt.  The measurement for the
   first flow SHOULD be at least 60 seconds in duration.

   The performance degradation of the x benchmarking dimension SHOULD be
   calculated as relative performance change between the 1-flow results
   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 3/4*n MAY also be performed.

   Reporting Format: The performance degradation SHOULD be expressed as
   a percentage.  The number of tested parallel flows n MUST be clearly
   specified.  For each of the performed benchmarking tests, there
   SHOULD be a table containing a column for each frame size.  The table
   SHOULD also state the applied frame rate and time duration T, which
   is used as an incremental step between the network flows.  The units
   of measurement for T SHOULD be seconds.  A column for the
   intermediary degradation points MAY also be displayed.  In the case
   of benchmarks for which more than one value is reported (e.g., IPDV,
   discussed in Section 7.3.2), a column for each of the values SHOULD
   be included.

11.  NAT44 and NAT66

   Although these technologies are not the primary scope of this
   document, the benchmarking methodology associated with single-
   translation technologies as defined in Section 4.1 can be employed to

Top      Up      ToC       Page 23 
   benchmark implementations that use NAT44 (as defined by [RFC2663]
   with the behavior described by [RFC7857]) and implementations that
   use NAT66 (as defined by [RFC6296]).

12.  Summarizing Function and Variation

   To ensure the stability of the benchmarking scores obtained using the
   tests presented in Sections 7 through 9, multiple test iterations are
   RECOMMENDED.  Using a summarizing function (or measure of central
   tendency) can be a simple and effective way to compare the results
   obtained across different iterations.  However, over-summarization is
   an unwanted effect of reporting a single number.

   Measuring the variation (dispersion index) can be used to counter the
   over-summarization effect.  Empirical data obtained following the
   proposed methodology can also offer insights on which summarizing
   function would fit better.

   To that end, data presented in [ietf95pres] indicate the median as a
   suitable summarizing function and the 1st and 99th percentiles as
   variation measures for DNS Resolution Performance and PDV.  The
   median and percentile calculation functions SHOULD follow the
   recommendations of Section 11.3 of [RFC2330].

   For a fine-grained analysis of the frequency distribution of the
   data, histograms or cumulative distribution function plots can be
   employed.

13.  Security Considerations

   Benchmarking activities as described in this memo are limited to
   technology characterization using controlled stimuli in a laboratory
   environment, with dedicated address space and the constraints
   specified in the sections above.

   The benchmarking network topology will be an independent test setup
   and MUST NOT be connected to devices that may forward the test
   traffic into a production network or misroute traffic to the test
   management network.

   Further, benchmarking is performed on a "black-box" basis, relying
   solely on measurements observable external to the DUT or System Under
   Test (SUT).  Special capabilities SHOULD NOT exist in the DUT/SUT
   specifically for benchmarking purposes.  Any implications for network
   security arising from the DUT/SUT SHOULD be identical in the lab and
   in production networks.

Top      Up      ToC       Page 24 
14.  IANA Considerations

   The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6
   benchmarking.  For IPv4 benchmarking, the 198.18.0.0/15 prefix was
   reserved, as described in [RFC6890].  The two ranges are sufficient
   for benchmarking IPv6 transition technologies.  Thus, no action is
   requested.

15.  References

15.1.  Normative References

   [RFC1242]  Bradner, S., "Benchmarking Terminology for Network
              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
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              DOI 10.17487/RFC2330, May 1998,
              <http://www.rfc-editor.org/info/rfc2330>.

   [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
              Network Interconnect Devices", RFC 2544,
              DOI 10.17487/RFC2544, March 1999,
              <http://www.rfc-editor.org/info/rfc2544>.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              DOI 10.17487/RFC3393, November 2002,
              <http://www.rfc-editor.org/info/rfc3393>.

   [RFC3511]  Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
              "Benchmarking Methodology for Firewall Performance",
              RFC 3511, DOI 10.17487/RFC3511, April 2003,
              <http://www.rfc-editor.org/info/rfc3511>.

   [RFC5180]  Popoviciu, C., Hamza, A., Van de Velde, G., and D.
              Dugatkin, "IPv6 Benchmarking Methodology for Network
              Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180,
              May 2008, <http://www.rfc-editor.org/info/rfc5180>.

Top      Up      ToC       Page 25 
   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
              March 2009, <http://www.rfc-editor.org/info/rfc5481>.

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <http://www.rfc-editor.org/info/rfc8174>.

15.2.  Informative References

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,
              <http://www.rfc-editor.org/info/rfc2663>.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213,
              DOI 10.17487/RFC4213, October 2005,
              <http://www.rfc-editor.org/info/rfc4213>.

   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
              <http://www.rfc-editor.org/info/rfc4659>.

   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
              Provider Edge Routers (6PE)", RFC 4798,
              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>.

Top      Up      ToC       Page 26 
   [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", RFC 6296, DOI 10.17487/RFC6296, June 2011,
              <http://www.rfc-editor.org/info/rfc6296>.

   [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., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, 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.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <http://www.rfc-editor.org/info/rfc7599>.

Top      Up      ToC       Page 27 
   [RFC7857]  Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
              S., and K. Naito, "Updates to Network Address Translation
              (NAT) Behavioral Requirements", BCP 127, RFC 7857,
              DOI 10.17487/RFC7857, April 2016,
              <http://www.rfc-editor.org/info/rfc7857>.

   [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>.

   [Dns64perf]
              Bakai, D., "A C++11 DNS64 performance tester",
              <https://github.com/bakaid/dns64perfpp>.

   [ietf95pres]
              Georgescu, M., "Benchmarking Methodology for IPv6
              Transition Technologies", IETF 95 Proceedings, Buenos
              Aires, Argentina, April 2016,
              <https://www.ietf.org/proceedings/95/slides/
              slides-95-bmwg-2.pdf>.

   [Lencse1]  Lencse, G., Georgescu, M., and Y. Kadobayashi,
              "Benchmarking Methodology for DNS64 Servers", Computer
              Communications, vol. 109, no. 1, pp. 162-175,
              DOI 10.1016/j.comcom.2017.06.004, September 2017,
              <http://www.sciencedirect.com/science/article/pii/
              S0140366416305904?via%3Dihub>

   [Lencse2]  Lencse, G. and D. Bakai, "Design and Implementation of a
              Test Program for Benchmarking DNS64 Servers", IEICE
              Transactions on Communications, Vol. E100-B, No. 6,
              pp. 948-954, DOI 10.1587/transcom.2016EBN0007, June 2017,
              <https://www.jstage.jst.go.jp/article/transcom/E100.B/
              6/E100.B_2016EBN0007/_article>.

   [Lencse3]  dns64perfppc,
              <http://www.hit.bme.hu/~lencse/dns64perfppc/>.

   [Lencse4]  Lencse, G., "Enabling Dns64perf++ for Benchmarking the
              Caching Performance of DNS64 Servers", unpublished, review
              version, <http://www.hit.bme.hu/~lencse/publications/
              IEICE-2016-dns64perfppc-for-review.pdf>.

Top      Up      ToC       Page 28 
   [IEEE802.1AC]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Media Access Control (MAC) Service
              Definition", IEEE 802.1AC.

   [IEEE802.1Q]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Bridges and Bridged Networks", IEEE Std
              802.1Q.

Top      Up      ToC       Page 29 
Appendix A.  Theoretical Maximum Frame Rates

   This appendix describes the recommended calculation formulas for the
   theoretical maximum frame rates to be employed over Ethernet as
   example media.  The formula takes into account the frame size
   overhead created by the encapsulation or translation process.  For
   example, the 6in4 encapsulation described in [RFC4213] adds 20 bytes
   of overhead to each frame.

   Considering X to be the frame size and O to be the frame size
   overhead created by the encapsulation or translation process, the
   maximum theoretical frame rate for Ethernet can be calculated using
   the following formula:

                Line Rate (bps)
         ------------------------------------
         (8 bits/byte) * (X+O+20) bytes/frame

   The calculation is based on the formula recommended by [RFC5180] in
   Appendix A.1.  As an example, the frame rate recommended for testing
   a 6in4 implementation over 10 Mb/s Ethernet with 64 bytes frames is:

                10,000,000 (bps)
         --------------------------------------  = 12,019 fps
         (8 bits/byte) * (64+20+20) bytes/frame

   The complete list of recommended frame rates for 6in4 encapsulation
   can be found in the following table:

   +------------+---------+----------+-----------+------------+
   | Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
   | (bytes)    | (fps)   | (fps)    | (fps)     | (fps)      |
   +------------+---------+----------+-----------+------------+
   | 64         | 12,019  | 120,192  | 1,201,923 | 12,019,231 |
   | 128        | 7,440   | 74,405   | 744,048   | 7,440,476  |
   | 256        | 4,223   | 42,230   | 422,297   | 4,222,973  |
   | 512        | 2,264   | 22,645   | 226,449   | 2,264,493  |
   | 678        | 1,740   | 17,409   | 174,094   | 1,740,947  |
   | 1024       | 1,175   | 11,748   | 117,481   | 1,174,812  |
   | 1280       | 947     | 9,470    | 94,697    | 946,970    |
   | 1518       | 802     | 8,023    | 80,231    | 802,311    |
   | 1522       | 800     | 8,003    | 80,026    | 800,256    |
   | 2048       | 599     | 5,987    | 59,866    | 598,659    |
   | 4096       | 302     | 3,022    | 30,222    | 302,224    |
   | 8192       | 152     | 1,518    | 15,185    | 151,846    |
   | 9216       | 135     | 1,350    | 13,505    | 135,048    |
   +------------+---------+----------+-----------+------------+

Top      Up      ToC       Page 30 
Acknowledgements

   The authors thank Youki Kadobayashi and Hiroaki Hazeyama for their
   constant feedback and support.  The thanks should be extended to the
   NECOMA project members for their continuous support.  We thank
   Emanuel Popa, Ionut Spirlea, and the RCS&RDS IP/MPLS Backbone Team
   for their support and insights.  We thank Scott Bradner for the
   useful suggestions and note that portions of text from Scott's
   documents were used in this memo (e.g., the "Latency" section).  A
   big thank you to Al Morton and Fred Baker for their detailed review
   of the document 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.

Authors' Addresses

   Marius Georgescu
   RCS&RDS
   Strada Dr. Nicolae D. Staicovici 71-75
   Bucharest 030167
   Romania

   Phone: +40 31 005 0979
   Email: marius.georgescu@rcs-rds.ro


   Liviu Pislaru
   RCS&RDS
   Strada Dr. Nicolae D. Staicovici 71-75
   Bucharest 030167
   Romania

   Phone: +40 31 005 0979
   Email: liviu.pislaru@rcs-rds.ro


   Gabor Lencse
   Szechenyi Istvan University
   Egyetem ter 1.
   Gyor
   Hungary

   Phone: +36 20 775 8267
   Email: lencse@sze.hu