Network Working Group W. Cerveny Internet-Draft Arbor Networks Intended status: Informational September 10, 2013 Expires: March 14, 2014 Benchmarking Neighbor Discovery Problems draft-cerveny-bmwg-ipv6-nd-01 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 March 14, 2014. 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 March 14, 2014 [Page 1] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Maximum number of hosts . . . . . . . . . . . . . . . . . 4 4.2. Stable-state time . . . . . . . . . . . . . . . . . . . . 4 4.3. NDP Prioritization . . . . . . . . . . . . . . . . . . . 5 5. Measurements Explicitly Excluded . . . . . . . . . . . . . . 5 5.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 5 5.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 5 6. DUT initialization . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 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. Neighbor Discovery See Section 1 of RFC 4861 [RFC4861] Cerveny Expires March 14, 2014 [Page 2] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 2013 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. A concern with using ICMPv6 echo requests as triggering events is that some immediate nodes deprioritize functions involving ICMPv6 echo requests. Scanner Network The network from which the scanning device is connected. Target Network The network for which the scanning tests is targeted. Scanning Interface The node which is conducting the scanning activity. Target Network Measurement Interface A node that resides on the target network, which is primarily used to measure DUT performance while the scanning activity is occurring. Non-participating Network Network connected to DUT, for which nodes are neither activie participants nor being directly impacted by the test traffic. 3. Test Setup 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. Cerveny Expires March 14, 2014 [Page 3] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 2013 +---------------+ +-----------+ +--------------+ | | Scanner | | Target | | | Scanning |-------------| DUT |--------------|Target Network| | interface | Network | | Network | interface | | | | | | | +---------------+ +-----------+ +--------------+ | | +-----------------+ | | |Non-participating| | network | | | +-----------------+ 4. Measurements Throughout measurements, two testing interfaces are defined: tester#1-new: Sets up new addresses tester#2-renew: Discovers addresses previously discovered 4.1. Maximum number of hosts 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 4.2. Stable-state time 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. o Lowest timer value and still have connectivity between all endpoints. o Make sure tester can keep up Cerveny Expires March 14, 2014 [Page 4] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 2013 o 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 4.3. NDP Prioritization 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. 5. Measurements Explicitly Excluded These are measurements which while possible, aren't being made because of the itemized reasons below: 5.1. DUT CPU Utilization This measurement relies on the DUT to provide utilization information, which is subjective. 5.2. Malformed Packets 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. DUT initialization At the beginning of each test, the neighbor cache of the DUT should be initialized Cerveny Expires March 14, 2014 [Page 5] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 2013 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. 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. 9. Acknowledgements 10. 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. Cerveny Expires March 14, 2014 [Page 6] Internet-Draft draft-cerveny-bmwg-ipv6-nd-00 September 2013 Author's Address Bill Cerveny Arbor Networks Cerveny Expires March 14, 2014 [Page 7]