Benchmarking Neighbor
Discovery ProblemsArbor NetworksThis 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.See Section
1 of RFC 4861An 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.The network from which the scanning
device is connected.The network for which the scanner is
targeting its scans.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.A node on a network
directly connected to the DUT, but this node is not in the target
network nor the scanner network.For purposes of this document, the intermediate node will be
referred to as the device under test (DUT). The DUT may be any
intermediate node which retains a neighbor cache. The tests in this
document could also 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.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.The frequency of NDP triggering events could be as high as the
maximum packet per second rate that the iscanner network will support
(or is rated for). However, it may not be necessary to send packets at
a particularly high rate and in fact a goal of testing could be to
identify if the DUT is able to withstand scans at rates which
otherwise would not impact the performance of the DUT.Optimistically, the scanning rate should be incremented until the
DUT’s performance begins deteriorating. Depending on the
software and system being used to implement the scanning, it may be
challenging to achieve a sufficient rate.The lowest frequency is the lowest rate for which packets could be
expected to have an impact on the DUT — this value is of course,
subjective.The target network's subnet shall be 64-bits in length. It may be
interesting to gauge performance when the subnet length is varied from
64-bits.The duration of the test needs to be evaluatedAlthough packet size shouldn’t have a direct impact, packet
per second (pps) rates will have an impact and smaller packet sizes
should be utilized to facilitate higher packet per second rates.For purposes of this test, the packet type being sent by the
scanning device isn’t important, although most scanning
applications might want to send packets that would elicit responses
from nodes within a subnet. Since it is not intended that responses be
evoked from the target network node, such packets aren’t
necessary.The hop limit for the scanning packets should be set to 2, to
reduce the likelihood that scanning packets would escape the test
network.The destination address for the packet should be an address within
the target network. While each packet sent should have a unique
destination address in the destination network, it isn’t clear
if it matters what the sequence of addresses is. For purposes of
thoroughness, it may be desirable to send each packet with a random
address within the target network’s address space.The source address for the packet may be the same for all scanning
packets. However, it may be interesting to vary the source address
during the scanning activityIt may be desirable to perform some tests in the presence of
mitigating techniques described in RFC
6583[Open Question: Is this an interesting condition, where a device on
the network responds affirmatively to all incoming NDP requests?? Are
there any non-malicious cases where this could happen?]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.This consists of pinging the target network measurement node from a
non-participating measurement node and recording reported round-trip
time. This measurement should be conducted with an address not yet
present in the DUT’s neighbor cache. This measurement is
included because it is perhaps the easiest to conduct and capture.There are three distinct time elements associated with this
measurement:The difference in time for which the DUT receives the packet
which must be forwarded to a node in the target network not yet
listed in the neighbor cache and the time the DUT sends a neighbor
solicitation.The difference in time between when the target network
measurement node receives the neighbor solicitation and the time
the target network measurement node responds with a neighbor
advertisement. This time is outside the control of the DUT and
measurements should account for this time if it is
significant.The difference in time from which the DUT receives the packet
to the time for which the DUT adds the neighbor in its neighbor
cache.The first time element may be measurable via a device which can
observe packets on both the scanner network and the target network.
The second time element may be measured by monitoring the target
network and observing the specific neighbor solicitation for the node
and the node’s solicited[Is this the right term?] neighbor
advertisement.Of the above time elements, the third is perhaps the hardest to
measure for times smaller than a few seconds.A challenge with this measurement is to conduct it where the target
network node has an address that is not in the DUT's neighbor cache in
any state (such as “INCOMPLETE”). As tested with a router,
the router's "clear neighbor cache" command did not always flush the
target network node's neighbor entry. One method of implementing this
may be to configure the target network node with sufficient addresses
for a unique NDP request per test interval.As discussed in RFC 6583, this
measurement would require confirming that a set prioritization is
adhered to. [Insert more text here.]Measured in percent utilization, captured via a non-intrusive query
of the DUT.This measures the impact that the scan may have on the DUT’s
ability to forward packets. The measurement should be documented in
packets per seconds (pps) or (bps). However, if the DUT handles NDP in
the “management plane” and packets are forwarded in a
separate “forwarding plane”, the scanning tests described
in this document may not have any impact on the DUT’s ability to
forward packets.It may be beneficial to conduct two RFC 5180
style throughput tests even if it is assumed that scanning
activity won’t have any bearing on the DUT’s packet
forwarding capabilities:Baseline test without any scanning activity.Test while worse-case scanning activity is occuring.This is the difference in time from when a node on the target
network network sends a neighbor solicitation for the DUT’s MAC
address and when the DUT responds with a neighbor advertisement in
response to the neighbor solicitation. This can be determined by
observing the target network and measuring the difference in time (in
milliseconds) between when the neighbor solicitation leaves the target
network measurement node and when the solicited neighbor advertisement
is returned from the DUT.This measurement would require having a node on a network directly
connected to the DUT, but not on either the scanner network or target
network. Although not itemized, this measurement could consist of any
combination of measurements which are conducted relating to the target
network.This measurement confirms how many entries can effectively reside
in the DUT’s neighbor cache. This measurement would support or
refute any value documented by the DUT manufacturer. [Need to describe
how this is done.]To be determined.At the beginning of each test, the neighbor cache of the DUT should
be initializedThis test can be completed with publicly available scanning software.
The methodology to implement this scan is fairly straightforward and
could be implemented using open-source network scripting tools.The algorithm for such a scanner could be as simple as:Dest_address = <ip prefix>::1000While True:Send(ICMPv6(dst=Dest_address)Dest_address = Dest_address + 1As described in , four instances of a scanner
on a single computer was able to impact the performance of high-end
routers. If multiple scanner instances are used, the starting address
should be in different “regions” of the subnet.Some existing software for completing network scans is discussed in
, although other applications may exist.Although not tested, commercial network testing solutions may be
effectively implemented and may provide dedsired throughput.[Question: Where a large number of addresses are being scanned for,
would there be an impact on intermediate nodes, such as
firewalls?]In this attack, a node in the subnet simulates a condition where it
is sending packets to every address in the subnet and where the
destination MAC address is the DUT[Is this an allowed scenario?]. In
this scenario, it “could” be possible to send neighbor
solicition messages to every link local address via the default
gateway.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.