Network Working Group                                         W. Cerveny
Internet-Draft                                            Arbor Networks
Intended status: Informational                                 R. Bonica
Expires: October 7, 2016 March 26, 2017                                        R. Thomas
                                                        Juniper Networks
                                                           April 5,
                                                      September 22, 2016

              Benchmarking IPv6 The Neighbor Cache Behavior
                       draft-ietf-bmwg-ipv6-nd-02 Discovery Protocol
                       draft-ietf-bmwg-ipv6-nd-03

Abstract

   This document is a provides benchmarking instantiation of RFC 6583:
   "Operational procedures for Neighbor Discovery Problems" [RFC6583].
   Protocol (NDP).  It describes a
   general testing procedure and measurements that also proposes metrics by which an NDP
   implementation's scaling capabilities can be performed to
   evaluate how the problems described in RFC 6583 may impact the
   functionality or performance of intermediate nodes. measured.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on October 7, 2016. March 26, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology  Test Setup  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Overview of Relevant NDP and Intermediate Node Behavior   4
     2.1.  Device Under Test (DUT) . . .   3
   4.  Test Setup . . . . . . . . . . . . . .   4
       2.1.1.  Interfaces  . . . . . . . . . . .   4
     4.1.  Testing Interfaces . . . . . . . . . .   4
       2.1.2.  Neighbor Discovery Protocol (NDP) . . . . . . . . .   5
   5.  Modifiers (Variables) .   4
       2.1.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Frequency of NDP Triggering Packets
     2.2.  Tester  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Tests
       2.2.1.  Interfaces  . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Neighbor Discovery Protocol (NDP) . . . . . . . . . .   6
     6.1.  Stale Entry Time Determination
       2.2.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   6
       6.1.1.  General Testing Procedure
       2.2.4.  Test Traffic  . . . . . . . . . . . . . .   6
     6.2.  Neighbor Cache Exhaustion Determination . . . . . .   6
       2.2.5.  Counters  . . .   7
       6.2.1.  General Testing Procedure . . . . . . . . . . . . . .   7
     6.3.  Preference For Previously Discovered Neighbors . . . . .   7
       6.3.1.  General Testing Procedures
   3.  Tests . . . . . . . . . . . . .   7
   7.  Measurements Explicitly Excluded . . . . . . . . . . . . . .   7
     7.1.  DUT CPU Utilization .   8
     3.1.  Baseline Test . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  Malformed Packets
       3.1.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations
       3.1.2.  Results . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . .   9
     3.2.  Scaling Test  . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements . . . . .   9
       3.2.1.  Procedure . . . . . . . . . . . . . . . . .   8
   11. References . . . . .   9
       3.2.2.  Results . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . .  10
   4.  Measurements Explicitly Excluded  . . . . . . . . . . . . . .  11
     4.1.  DUT CPU Utilization .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses .  11
     4.2.  Malformed Packets . . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . .   9

1.  Introduction

   This document is a benchmarking instantiation of RFC 6583:
   "Operational Neighbor Discovery Problems" [RFC6583].  It describes a
   general testing procedure and measurements that can be performed to
   evaluate how the problems described in RFC 6583 may impact the
   functionality or performance of intermediate nodes.

2.  Terminology

   Intermediate Node  A router, switch, firewall or any other device
      which separates end-nodes.  The tests in this document can be
      completed with any intermediate node which maintains a neighbor
      cache, although not all measurements and performance
      characteristics may apply.

   Neighbor Cache  See RFC 4861 [RFC4861]

   Neighbor Discovery  See Section of RFC 4861

   Scanner Network  The network from which the scanning tester is
      connected.

   Scanning Interface  The interface from which the scanning activity is
      initiated.

   Stale Entry Time  See RFC 4861

   Target Network . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   When an IPv6 node forwards a packet, it executes the following
   procedure:

   o  Identify the IPv6 next-hop (i.e., the next IPv6 node that the
      packet traverses on route to its ultimate destination)

   o  Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's
      link-layer address

   o  Encapsulate the packet in a link-layer header.  The network link-layer
      header includes the IPv6 next-hop's link-layer address

   o  Forward the packet to the IPv6 next-hop

   IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to
   maintain the NC.  Operational experience [RFC6583] shows that when an
   implementation cannot maintain a sufficiently complete NC, its
   ability to forward packets is impaired.

   NDP, like any other protocol, consumes processing, memory, and
   bandwidth resources.  Its ability to maintain a sufficiently complete
   NC depends upon the availability of the above-mentioned resources.

   This document provides benchmarking procedures for NDP.  Benchmarking
   procedures include a Baseline Test and an NDP Scaling Test.  In both
   tests, the Device Under Test (DUT) is an IPv6 router.  Two physical
   links (A and B) connect the DUT to a Tester.  The Tester sends
   traffic through Link A to the DUT.  The DUT forwards that traffic,
   through Link B, back to the Tester.

   The above-mentioned traffic stream contains one or more interleaved
   flows.  An IPv6 Destination Address uniquely identifies each flow.
   Or, said another way, every packet within a flow has the same IPv6
   Destination Address.

   In the Baseline Test, the traffic stream contains exactly one flow.
   Because every packet in the stream has the same IPv6 Destination
   Address, the DUT can forward the entire stream using exactly one NC
   entry.  NDP is exercised minimally and no packet loss should be
   observed.

   The NDP Scaling Test is identical to the Baseline Test, except that
   the traffic stream contains many flows.  In order to forward the
   stream without loss, the DUT must maintain one NC entry for each
   flow.  If the DUT cannot maintain one NC entry for each flow, packet
   loss will be observed and attributed to NDP scaling limitations.

   This document proposes an NDP scaling metric, called NDP-MAX-
   NEIGHBORS.  NDP-MAX-NEIGHBORS is the maximum number of neighbors to
   which an IPv6 node can send traffic during periods of high NDP
   activity.

   The procedures described herein reveal how many IPv6 neighbors an NDP
   implementation can discover.  They also provide a rough estimate of
   the time required to discover those neighbors.  However, that
   estimate does not reflect the maximum rate at which the scanning tests
   implementation can discover neighbors.  Maximum rate discovery is targeted.

   Target Network Destination Interface a
   topic for further exploration.

   The interface test procedures described herein assume that resides on the target network, which DUT, NDP does
   not compete for resources with other applications.  When NDP
   completes for resources, its scaling characteristics may not be
   commensurate with those reported by the benchmarks described herein.

2.  Test Setup

                +---------------+             +-----------+
                |               |             |           |
                |               |   Link A    |   Device  |
                |               |------------>|   Under   |
                |    Tester     |             |   Test    |
                |               |<------------|   (DUT)   |
                |               |   Link B    |           |
                +---------------+             +-----------+

                           Figure 1: Test Setup

   The DUT is primarily used to measure an IPv6 router.  The DUT
      performance while the scanning activity is occurring.

3.  Overview of Relevant NDP connected to a Tester by two
   links (A and Intermediate Node Behavior

   Network elements map IP addresses B).  Link A capabilities must be identical to link-layer addresses.  ARP
   [RFC0826] manages Link B
   capabilities.  For example, if the mapping process for IPv4, while interface to Link A is a 10
   Gigabit Ethernet port, the interface to Link B must also be a 10
   Gigabit Ethernet port.  Furthermore, Link A and Link B must be
   lossless.

2.1.  Device Under Test (DUT)

2.1.1.  Interfaces

   DUT interfaces are numbered as follows:

   o  Link A - 2001:2:0:0::2/64

   o  Link B- 2001:2:0:1::1/64

   Both DUT interfaces should be configured with a 1500-byte MTU.
   However, if they cannot support a 1500-byte MTU, they may be
   configured with a 1280-byte MTU.

2.1.2.  Neighbor Discovery Protocol [RFC4861] manages mapping for IPv6.  With IPv6,
   when a node forwards a packet:

   1. (NDP)

   NDP is enabled on both DUT interfaces.  Therefore, the DUT emits both
   solicited and unsolicited Router Advertisement (RA) messages.  The node determines if
   DUT emits an RA message at least once every 600 seconds and no more
   frequently than once every 200 seconds.

   When the destination IPv6 DUT sends an RA message, it includes the following
   information:

   o  Router Lifetime - 1800 seconds

   o  Reachable Time - 0 seconds

   o  Retrans Time - 0 seconds

   o  Source Link Layer Address - Link layer address is present in
       its neighbor cache.

   2.  If of DUT interface

   The above-mentioned values are chosen because they are the address is present default
   values specified in RFC 4861.

   NDP also manages the NC.  Each NC entry represents an on-link
   neighbor cache, the node
       forwards the packet to and is identified by the destination node using neighbor's on-link unicast IP
   address.  NC entries contain the appropriate neighbor's link-layer address.

   3.  If address, a
   state variable, and several timers that are used by the destination IPv6 address is not in Neighbor
   Unreachability Detection (NUD) algorithm.  Section 7.3 of RFC 4861
   provides NUD details.  On the DUT, NUD uses the intermediate node's
       neighbor cache:

       1.  An protocol constants
   defined in Section 10 of RFC 4861.  As per these specifications, each
   NC entry for the IPv6 address is added needs to the neighbor cache
           and the entry is marked "INCOMPLETE".

       2.  The intermediate node sends an ICMP be refreshed at least every 60 seconds.  NDP
   refreshes NC entries by exchanging Neighbor Solicitation (NS) packet.

       3.  If an ICMP and
   Neighbor Advertisement (NA) for the IPv6 address
           is received by the node, messages.

   No static NC entries are configured on the neighbor cache entry is marked
           "REACHABLE" and remains in this state for 15 DUT.

2.1.3.  Routing

   The DUT maintains a direct route to 45 seconds.

       4.  If 2001:2:0:0/64 through Link A.  It
   also maintains a neighbor advertisement is not received, the intermediate
           node will continue sending NS packets every second until
           either an NA is received direct route to 2001:2:0:1/64 through Link B.  No
   static routes or dynamic routing protocols are configured on the maximum DUT.

2.2.  Tester

2.2.1.  Interfaces

   Interfaces are numbered as follows:

   o  Link A - 2001:2:0:0::1/64

   o  Link B - Multiple addresses are configured on Link B.  These
      addresses are drawn sequentially from the 2001:2:0:1::/64 address
      block.  The first address is 2001:2:0:1::2/64.  Subsequent
      addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64,
      2001:2:0:1::5/64, et cetera.  The number of
           solicitations has been sent.  If an NA is not received in
           this period, configured addresses
      should be the entry can expected value of NDP-MAX-NEIGHBORS times 1.1.

   Both Tester interfaces should be configured with a 1500-byte MTU.
   However, if they cannot support a 1500-byte MTU, they may be discarded.

   There
   configured with a 1280-byte MTU.

2.2.2.  Neighbor Discovery Protocol (NDP)

   NDP is enabled on both Tester interfaces.  Therefore, upon
   initiation, the Tester sends Router Solicitation (RS) messages and
   waits for Router Advertisement (RA) messages.  The Tester also
   exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
   messages with the DUT.

   No static NC entries are two scenarios where configured on the Tester.

2.2.3.  Routing

   The Tester maintains a neighbor cache can grow direct route to 2001:2:0:0/64 through Link A.
   It also maintains a very
   large size:

   1.  There direct route to 2001:2:0:1/64 through Link B.  No
   static routes or dynamic routing protocols are configured on the
   Tester.

2.2.4.  Test Traffic

   The Tester sends a large number of real nodes connected via stream test traffic through Link A to the DUT.
   The test traffic stream contains one or more interleaved flows.
   Flows are numbered 1 through N, sequentially.

   Within each flow, each packet contains an interface IPv6 header and a large number each IPv6
   header contains the following information:

   o  Version - 6

   o  Traffic Class - 0

   o  Flow Label - 0

   o  Payload Length - 0

   o  Next Header - IPv6-NoNxt (59)

   o  Hop Limit - 255

   o  Source Address - 2001:2:0:0::1

   o  Destination Address - The first 64 bits of these nodes the Destination Address
      are sending and receiving
       traffic simultaneously.

   2.  There 2001:2:0:1::. The next 64 are a large number of addresses for which a scanning
       activity is occurring and no real node will respond to uniquely associated with the
       neighbor solicitation.  This scanning activity can be
       unintentional or malicious.  In addition to maintaining
      flow.  Every packet in the
       "INCOMPLETE" neighbor cache entry, first flow carries the intermediate node must
       send a NS packet every second for Destination
      address 2001:2:0:1::2.  Every subsequent flow has an IP address
      one greater than the maximum number of
       solicitations.

   A node's neighbor cache last (i.e., 2001:2:0:1::3, 2001:2:0:1::4,
      etc.)

   In order to avoid link congestion, test traffic is of a finite size and can only accommodate offered at a specific number rate
   not to exceed 50% of entries, which can be limited by available
   memory or a preset operating system limit.  If the maximum number of
   entries link bandwidth.  In order to avoid
   burstiness and buffer occupancy, every packet in a neighbor cache the stream is reached,
   exactly 40 bytes long (i.e., the intermediate node must
   either drop length of an existing entry to make space for IPv6 header with no
   IPv6 payload).  Furthermore, the new entry or deny gap between packets is identical.

   During the new IP address to MAC address/ interface mapping with an entry in course of a test procedure, the neighbor cache.  In an extreme case, number of flows that the intermediate node's
   memory
   test stream contains may become exhausted, causing increase.  When this occurs, the intermediate node to crash
   or page memory.

   RFC 6583 [RFC6583] describes a how rate at
   which test traffic is offered remains constant.  For example, assume
   that a port scan can cause neighbor
   cache exhaustion.

   Section 7.1 of RFC 6583 describes how nodes should behave when the
   neighbor cache test stream is exhausted.  Section 6 of RFC 6583 [RFC6583]
   recommends how damage from an IPv6 address scan may be mitigated.
   Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning.

4.  Test Setup

   The network has offered at a rate of 1,000 packets per second.
   This stream contains two subnets.  These connect the DUT flows, each contributing 500 packets per
   second to the scanning
   and target networks.

   It 1,000 packet per second aggregate.  When a third stream
   is assumed that added to the latency for flow, all network segments is
   negligible.  By default, the target network's subnet shall be 64-bits
   in length, although some tests may involve increasing the prefix
   length.

   Although packet size shouldn't have a direct impact, packet three streams must contribute 333 packets
   per second (pps) rates will have an impact.  Smaller packet sizes should
   be utilized in order to facilitate higher maintain the 1,000 packet per second rates.

   For purposes of limit.
   (As in this test, the example, rounding error is acceptable.)

   The DUT attempts to forward every packet type being sent by in the scanning
   device isn't important, although most scanning applications might
   want test stream through
   Link B to send packets that would elicit responses the Tester.  It does this because:

   o  Every packet in the test stream has a destination address drawn
      from nodes within the 2001:2:0:1::/64 address block

   o  The DUT has a
   subnet (such as direct route to 2001:2:0:1/64 through Link B

2.2.5.  Counters

   For each address configured on the Tester interface to Link B, two
   counters are configured.  One counter, configured on the Tester
   interface to Link A, increments when the Tester detects an ICMPv6 echo request).  Since it is not intended
   that responses be evoked outgoing
   packet from the target network node, such packets
   aren't necessary.

   At associated flow.  The other counter, configured on
   the beginning of each test Tester interface to Link B, increments when the intermediate node should Tester detects an
   incoming packet from the associated flow.  In order for a packet to
   be
   initialized.  Minimally, associated with a flow, the neighbor cache should following conditions must all be true:

   o  The IPv6 Destination Address must be cleared.

   Basic format that of test network.

+---------------+             +-----------+             +--------------+
|               |   Scanner   |           |   Target    |              |
|   Scanning    |-------------|    DUT    |-------------|Target Network|
| src interface |   Network   |           |   Network   |dst interface |
|               |             |           |             |              |
+---------------+             +-----------+             +--------------+

4.1.  Testing Interfaces

   Two tester interfaces the flow

   o  The IPv6 Next Header must be IPv6-NoNxt (59)

   The following counters also are configured for most tests: on both Tester Interfaces:

   o  RS packets sent

   o  RS packets received

   o  RA packets sent
   o  RA packets received

   o  NS packets sent

   o  NS packets received

   o  NA packets sent

   o  NA packets received

   o  Total packets sent

   o  Total packets received

3.  Tests

3.1.  Baseline Test

   The purpose of the Baseline Test is to ensure that the DUT can
   forward every packet in the test stream, wThithout loss, when NDP is
   minimally exercised and not operating near its scaling limit.

3.1.1.  Procedure

   o  Reset all counters on the Tester

   o  Scanning source (src) interface: This is  Clear the interface from which
      test packets are sourced.  This interface sources traffic to
      destination IPv6 addresses NC on the target network from DUT

   o  Set a single
      link-local address, similar timer to how an adjacent intermediate node
      would transit traffic through expire in 60 seconds

   o  Start the intermediate node. test stream with exactly one flow (i.e., IPv6
      Destination Address equals 2001:2:0:1::2)

   o  Target network destination (dst) interface: This interface
      responds  Wait for either the timer to neighbor solicitations as appropriate expire or the packets-received
      counter associated with the flow to increment

   o  If the timer expires, stop the test stream and confirms
      when end the test

   o  If the packets-received counter increments, pause the traffic
      stream, clear the timer, log the counters associated with the
      flow, clear the counters associated with the flow, reset the timer
      to expire in 1800 seconds and restart the traffic stream

   o  When the timer expires, stop the test stream, log all counters and
      end the test

3.1.2.  Results

   The two counters associated with the flow (packets-sent and packets-
   received) must have equal values.  If they do not, an intermediate node error has forwarded a packet
   occurred.  Because this error is likely to affect Scaling Test
   results, the interface
      for consumption.  Where appropriate, error must be corrected before the target network
      destination interface will respond to neighbor solicitations with
      a unique link-layer address per IPv6 address solicited.

5.  Modifiers (Variables)

5.1.  Frequency of NDP Triggering Packets Scaling Test is
   executed.

   The frequency log contains two counters (packets-sent and packets-received) for
   the flow.  If these values are identical, none of NDP triggering packets can be as high as the maximum
   packet per second rate that initial packets
   belonging to the scanner network will support (or is
   rated for). flow were lost.  However, it may not be necessary to send if packets-sent is greater
   than packets at a
   particularly high rate.  In fact, a non-benchmarking goal received, initial packets were lost.  This loss of
   initial packets is acceptable.

3.2.  Scaling Test

   The purpose of testing
   could be to identify if the DUT Scaling Test is able to withstand scans at rates
   which otherwise would not impact discover the performance number of
   neighbors to which an IPv6 node can send traffic during periods of
   high NDP activity.  We call this number NDP-MAX-NEIGHBORS.

3.2.1.  Procedure

   Execute the DUT.

   Optimistically, following procedure:

   o  Clear all counters on the scanning rate should be incremented until Tester

   o  Clear the
   DUT's performance begins deteriorating.  Depending NC on the software
   and system being used DUT

   o  Set a timer to expire in 60 seconds

   o  Start the test stream with exactly one flow (i.e., IPv6
      Destination Address equals 2001:2:0:1::2)

   o  Wait for either the timer to expire or the packets-received
      counter associated with the flow to implement increment

   o  If the timer expires, stop the scanning, it may be
   challenging to achieve a sufficient rate.  Where this maximum
   threshold cannot be determined, test stream and end the test results should note

   o  If the
   highest rate tested packets-received counter increments, proceed as described
      below:

   Execute the following procedure N times, starting at 2 and that DUT performance deterioration was not
   noticed ending at this rate.

   The lowest rate tested should be
   the rate for which packets can be number of expected to have an impact on the DUT -- this value is of course,
   subjective.

6.  Tests

6.1.  Stale Entry Time Determination

   This NDP-MAX-NEIGHBORS time 1.1.

   o  Pause the test determines stream

   o  Clear the time interval when timer
   o  Log the time, the intermediate node
   (DUT) identifies an address as stale.

   RFC 4861, section 6.3.2 [RFC4861] states that an address can be
   marked "stale" at a random value between 15 of N minus one, and 45 seconds (as
   defined via constants in the RFC).  This test confirms what value is
   being used by packets-sent and
      packets-received counters associated with the intermediate node.  Note that RFC 4861 states that
   this random time can be changed "at least every few hours."

6.1.1.  General Testing Procedure

   1.  Send a packet from previous flow (i.e.,
      N minus one)

   o  Clear the scanning source interface packets-sent and packets-received counters associated
      with the previous flow (i.e., N minus one)

   o  Reset the timer to an address expire in
       target network.  Observe that 60 seconds

   o  Add the intermediate node sends a NS next flow to the solicited-node multicast address on test stream (i.e.,IPv6 Destination
      Address is a function of N)

   o  Restart the target network, for
       which tester destination interface should respond with an NA.
       The intermediate node should create an entry in neighbor cache test stream

   o  Wait for either the address, marking timer to expire or the address as "reachable".  As this
       point, packets-received
      counter associated with the packet should be forwarded new flow to the tester destination
       interface.

   2. increment

   After the neighbor advertisement from the destination tester
       interface in step one, the tester will send no more NA messages

   3.  Continue sending packets from above described procedure had been executed N times, clear
   the scanning source interface timer and reset it to
       the same address expire in 1800 seconds.  When the target network.

   4.  Note timer
   expires, stop the time at which stream, log all counters and end the DUT no longer forwards packets. test.

3.2.2.  Results

   The
       stale timer value will be test report includes the period following:

   o  A description of time between when the DUT
       received the first neighbor advertisement above and the point (make, model, processor, memory,
      interfaces)

   o  Rate at which the DUT no longer forwards packets for this flow Tester offers test traffic to the
       tester destination interface.

6.2.  Neighbor Cache Exhaustion Determination

   Discover DUT (measured
      in packets per second)

   o  A log that records the point time at which each flow was introduced to
      the neighbor cache is exhausted and
   evaluate intermediate node behavior when this threshold test stream

   o  All counter values

   NDP-MAX-NEIGHBORS is reached.
   If equal to the stale timer number of counter pairs where
   packets-sent is configurable, it should be set equal to its maximum
   value.. A side-effect packets-recieved.  Two counters are members
   of this test a pair if they are both associated with the same IPv6 address.  If
   packets-sent is greater than zero and equal to confirm that intermediate
   node behaves correctly; in particular, it shouldn't crash.

   Note that some intermediate nodes may restrict packets-recieved for
   every counter pair, the frequency of
   allowed neighbor discovery packets transmitted.  The maximum allowed
   packets per second must either test should be set to repeated with a larger
   expected value which doesn't impact
   the outcome of NDP-MAX-NEIGHBORS.

   If an implementation abides by the test must allow recommendation of RFC 6583, for this restriction.

6.2.1.  General Testing Procedure

   1.  At a very fast rate, send packets incrementally
   any given counter pair, packets-received will either be equal to valid unique
       addresses in zero
   or packets-received.

   The log documents the target network, within stale entry time period.
       Simultaneously, send packets for addresses previously added at which each flow was introduced to the neighbor cache.  The neighbor cache has been exhausted when
       previously added addresses must be re-discovered with a neighbor
       solicitation (within the stale entry time period).

   2.  Observe what happens when one address greater than
   test stream.  This log reveals the maximum
       neighbor cache effect of NC size ("n") is reached.  When "n+1" is reached, if
       either to the first or most recent cache entry time
   required to discover a new IPv6 neighbor.

   The log contains two counters (packets-sent and packets-received) for
   each flow.  If these values are dropped, this may
       be acceptable.

   3.  Confirm intermediate node doesn't crash when "n+1" is reached.

6.3.  Preference For Previously Discovered Neighbors

   Determine whether identical, none of the DUT prefers previously discovered neighbors.

6.3.1.  General Testing Procedures

   Repeat initial
   packets belonging to the test describe . flow were lost.  However, in this test, the test device
   withholds the NA message for odd numbered IP addresses.  At the end if packets-sent is
   greater than packets received, initial packets were lost.  This loss
   of the test, only even numbered IP addresses should appear in the
   neighbor cache.

7. initial packets is acceptable.

4.  Measurements Explicitly Excluded

   These are measurements which aren't recommended because of the
   itemized reasons below:

7.1.

4.1.  DUT CPU Utilization

   This measurement relies on the DUT to provide utilization
   information, which is subjective.

7.2.

4.2.  Malformed Packets

   This benchmarking test is not intended to test DUT behavior in the
   presence of malformed packets.

8.

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

9.

6.  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/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.

10.

7.  Acknowledgements

   Helpful comments and suggestions were offered by Al Morton, Joel
   Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, and Marius
   Georgescu on the BMWG
   e-mail list and at BMWG meetings.  Precise grammatical corrections
   and suggestions were offered by Ann Cerveny.

11.  References

11.1.

8.  Normative References

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <http://www.rfc-editor.org/info/rfc826>.

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

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

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

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,
              <http://www.rfc-editor.org/info/rfc6583>.

11.2.  Informative References

   [RFC7048]  Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
              Detection Is Too Impatient", RFC 7048,
              DOI 10.17487/RFC7048, January 2014,
              <http://www.rfc-editor.org/info/rfc7048>.

Authors' Addresses

   Bill Cerveny
   Arbor Networks
   2727 South State Street
   Ann Arbor, MI  48104
   USA

   Email: wcerveny@arbor.net

   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20170
   USA

   Email: rbonica@juniper.net
   Reji Thomas
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, KA  560103
   India

   Email: rejithomas@juniper.net