Network Working Group W.J. Cerveny
Internet-Draft Arbor Networks
Intended status: Informational March 11, 2013
Expires: September 12, 2013
Benchmarking Neighbor Discovery Problems
draft-cerveny-bmwg-ipv6-nd-00
Abstract
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.
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 September 12, 2013.
Copyright Notice
Copyright (c) 2013 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
Cerveny Expires September 12, 2013 [Page 1]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Test Set-up . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Device Under Test (DUT) . . . . . . . . . . . . . . . . . 3
3.2. Test Network . . . . . . . . . . . . . . . . . . . . . . 3
4. Modifiers (variables) . . . . . . . . . . . . . . . . . . . . 4
4.1. Frequency of NDP triggering events . . . . . . . . . . . 4
4.2. Prefix Length . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Duration of Test . . . . . . . . . . . . . . . . . . . . 5
4.4. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Packet Type . . . . . . . . . . . . . . . . . . . . . . . 5
4.6. Packet Addressing . . . . . . . . . . . . . . . . . . . . 5
4.7. Testing of Mitigating Options . . . . . . . . . . . . . . 5
4.8. Attack where node in target network responds to all
neighbor solicitations . . . . . . . . . . . . . . . . . 6
5. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Round-trip time across DUT . . . . . . . . . . . . . . . 6
6.2. Rate DUT adds a valid node in the target network to its
neighbor cache . . . . . . . . . . . . . . . . . . . . . 6
6.3. Adherence to prioritization of NDP activity
prioritization . . . . . . . . . . . . . . . . . . . . . 7
6.4. DUT CPU utilization . . . . . . . . . . . . . . . . . . . 7
6.5. Rate DUT forwards packets . . . . . . . . . . . . . . . . 7
6.6. Rate DUT responds to neighbor solicitations for its own
address . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.7. Impact on unaffected interfaces/subnets . . . . . . . . . 8
6.8. Maximum number of enteries in the DUT's neighbor cache . 8
7. Measurement Interval . . . . . . . . . . . . . . . . . . . . 8
8. DUT initialization . . . . . . . . . . . . . . . . . . . . . 8
9. General Test Procedure . . . . . . . . . . . . . . . . . . . 8
10. Other Potential Testing Scenarios . . . . . . . . . . . . . . 9
10.1. Exhaustion of Address Tables (NCE) in Intermediate Nodes 9
10.2. Link-local network attack . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
14. Normative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
Cerveny Expires September 12, 2013 [Page 2]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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
Neighbor Discovery See Section 1 of RFC 4861 [RFC4861]
NDP Triggering Event 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.
Scanner Network The network from which the scanning device is
connected.
Target Network The network for which the scanner is targeting its
scans.
Scanning Node The node which is conducting the scanning activity.
Target Network Measurement Node A node that resides on the target
network, which is primarily used to measure DUT performance while
the scanning activity is occurring.
Non-participating Measurement Node A node on a network directly
connected to the DUT, but this node is not in the target network
nor the scanner network.
3. Test Set-up
3.1. Device Under Test (DUT)
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.
3.2. Test Network
Cerveny Expires September 12, 2013 [Page 3]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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
node" is illustrated connected via a third network not related to the
scanner or target network.
+---------------+ +-----------+ +--------------+
| | Scanner | | Target | |
| Scanning |-------------| DUT |--------------|Target Network|
| node | Network | | Network | node |
| | | | | |
+---------------+ +-----------+ +--------------+
|
|
+-----------------+
| |
|Non-participating|
| node |
| |
+-----------------+
4. Modifiers (variables)
4.1. Frequency of NDP triggering events
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.
Cerveny Expires September 12, 2013 [Page 4]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
The lowest frequency is the lowest rate for which packets could be
expected to have an impact on the DUT -\u002D this value is of
course, subjective.
4.2. Prefix Length
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.
4.3. Duration of Test
The duration of the test needs to be evaluated
4.4. Packet Size
Although 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.
4.5. Packet Type
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.
4.6. Packet Addressing
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 activity
4.7. Testing of Mitigating Options
It may be desirable to perform some tests in the presence of
mitigating techniques described in RFC 6583 [RFC6583]
Cerveny Expires September 12, 2013 [Page 5]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
4.8. Attack where node in target network responds to all neighbor
solicitations
[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?]
5. Exclusions
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.
6. Measurements
6.1. Round-trip time across DUT
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.
6.2. Rate DUT adds a valid node in the target network to its neighbor
cache
There are three distinct time elements associated with this
measurement:
1. 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.
2. 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.
3. 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
Cerveny Expires September 12, 2013 [Page 6]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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.
6.3. Adherence to prioritization of NDP activity prioritization
As discussed in RFC 6583 [RFC6583], this measurement would require
confirming that a set prioritization is adhered to. [Insert more
text here.]
6.4. DUT CPU utilization
Measured in percent utilization, captured via a non-intrusive query
of the DUT.
6.5. Rate DUT forwards packets
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 [RFC5180] style
throughput tests even if it is assumed that scanning activity won't
have any bearing on the DUT's packet forwarding capabilities:
1. Baseline test without any scanning activity.
2. Test while worse-case scanning activity is occuring.
6.6. Rate DUT responds to neighbor solicitations for its own address
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
Cerveny Expires September 12, 2013 [Page 7]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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.
6.7. Impact on unaffected interfaces/subnets
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.
6.8. Maximum number of enteries in the DUT's neighbor cache
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.]
7. Measurement Interval
To be determined.
8. DUT initialization
At the beginning of each test, the neighbor cache of the DUT should
be initialized
9. General Test Procedure
This 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>::1000
While True:
Send(ICMPv6(dst=Dest_address)
Dest_address = Dest_address + 1
Cerveny Expires September 12, 2013 [Page 8]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
As described in [RFC6583], 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
[RFC6583], although other applications may exist.
Although not tested, commercial network testing solutions may be
effectively implemented and may provide dedsired throughput.
10. Other Potential Testing Scenarios
10.1. Exhaustion of Address Tables (NCE) in Intermediate Nodes
[Question: Where a large number of addresses are being scanned for,
would there be an impact on intermediate nodes, such as firewalls?]
10.2. Link-local network attack
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.
11. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
12. 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.
Cerveny Expires September 12, 2013 [Page 9]
Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 March 2013
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.
13. Acknowledgements
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, May 2008.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
Author's Address
Bill Cerveny
Arbor Networks
Cerveny Expires September 12, 2013 [Page 10]