Arbor Networks This document is a benchmarking instantiation of RFC 6583: “Operational Neighbor Discovery Problems”. 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. 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.

This document is a benchmarking instantiation of RFC 6583: “Operational Neighbor Discovery Problems”. 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.

An intermediate node can be 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 list of addresses that traverse the intermediate node, although not all measurements and performance characteristics may apply. While it is likely that the intermediate node which will be the DUT will be at the edge of a network directly adjacent to an end-node, there may be reasons to test intermediate nodes closer to the center of the network path. See Section 1 of RFC 4861 An event which forces the DUT (Device Under Test) to perform a neighbor solicitation. A triggering event could be an ICMPv6 echo request, but could also be any other packets which require discovering the MAC address of existing and non-existing nodes on an IPv6 subnet. A concern with using ICMPv6 echo requests as triggering events is that some immediate nodes deprioritize functions involving ICMPv6 echo requests. The network from which the scanning device is connected. The network for which the scanning tests is targeted. The node which is conducting the scanning activity. A node that resides on the target network, which is primarily used to measure DUT performance while the scanning activity is occurring. Network connected to DUT, for which nodes are neither activie participants nor being directly impacted by the test traffic.

The test network design is fairly simple. The network needs to minimally have two subnets: one from which the scanner(s) source their scanning activity and the other which is the target network of the address scans. It is assumed that the latency for all network segments is neglible. At least one node should reside on the target network to confirm some of the performance characteristics.

Basic format of test network. Note that optional "non-participating network" is a third network not related to the scanner or target network. +---------------+ +-----------+ +--------------+ | | Scanner | | Target | | | Scanning |-------------| DUT |--------------|Target Network| | interface | Network | | Network | interface | | | | | | | +---------------+ +-----------+ +--------------+ | | +-----------------+ | | |Non-participating| | network | | | +-----------------+

Throughout measurements, two testing interfaces are defined: tester#1-new: Sets up new addresses tester#2-renew: Discovers addresses previously discovered

This test evaluates how many hosts can be on a network and still have connectivity between all endpoints. Perform "scan" with addresses in ascending order. tester#1-new sets up new addresses tester#2-renew is pinging existing addresses, where granularity is somewhere between a millisecond and a second. tester#1-new and tester#2-renew should get responses to every packet

Given that there are as many hosts as determined in "maximum number of hosts" test, determine how long it takes for the neighbor cache get into a reasonable state. Lowest timer value and still have connectivity between all endpoints. Make sure tester can keep up Keep getting smaller intervals reduce timer on tester#1-new tester#1-new should not always get responses tester#2-renew should get responses to every packet

How do we behave when we’re being scanned. Priority should be given to hosts that have been seen before. Slow down tester#2-renew until one gets into refreshing every 6 seconds. If an address is in the "stale" state, it should get priority over new request. increase timer on tester#2-renew. tester#2-renew should always get responses tester#1-new should not always get responses.

These are measurements which while possible, aren't being made because of the itemized reasons below:

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

This benchmarking test is not intended to test DUT behavior in the presence of malformed packets, such as packets which do not confirm to designs consistent with IETF standards.

At the beginning of each test, the neighbor cache of the DUT should be initialized

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

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.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community. In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.</t><t> This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK] Harvard University

1350 Mass. Ave Room 813 Cambridge MA 02138 US +1 617 495 3864 +1 617 496 8500 sob@harvard.edu

NetScout Systems

4 Westford Tech Park Drive Westford MA 01886 US +1 978 614 4116 +1 978 614 4004 mcquaidj@netscout.com

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]