idnits 2.17.1 draft-ietf-bmwg-ipv6-nd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6583]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2016) is 2914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2544' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC5180' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC7048' is defined on line 419, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cerveny 3 Internet-Draft Arbor Networks 4 Intended status: Informational R. Bonica 5 Expires: October 7, 2016 Juniper Networks 6 April 5, 2016 8 Benchmarking IPv6 Neighbor Cache Behavior 9 draft-ietf-bmwg-ipv6-nd-02 11 Abstract 13 This document is a benchmarking instantiation of RFC 6583: 14 "Operational Neighbor Discovery Problems" [RFC6583]. It describes a 15 general testing procedure and measurements that can be performed to 16 evaluate how the problems described in RFC 6583 may impact the 17 functionality or performance of intermediate nodes. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 7, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Overview of Relevant NDP and Intermediate Node Behavior . . . 3 62 4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Testing Interfaces . . . . . . . . . . . . . . . . . . . 5 64 5. Modifiers (Variables) . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Frequency of NDP Triggering Packets . . . . . . . . . . . 5 66 6. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Stale Entry Time Determination . . . . . . . . . . . . . 6 68 6.1.1. General Testing Procedure . . . . . . . . . . . . . . 6 69 6.2. Neighbor Cache Exhaustion Determination . . . . . . . . . 7 70 6.2.1. General Testing Procedure . . . . . . . . . . . . . . 7 71 6.3. Preference For Previously Discovered Neighbors . . . . . 7 72 6.3.1. General Testing Procedures . . . . . . . . . . . . . 7 73 7. Measurements Explicitly Excluded . . . . . . . . . . . . . . 7 74 7.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 8 75 7.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 11.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 This document is a benchmarking instantiation of RFC 6583: 87 "Operational Neighbor Discovery Problems" [RFC6583]. It describes a 88 general testing procedure and measurements that can be performed to 89 evaluate how the problems described in RFC 6583 may impact the 90 functionality or performance of intermediate nodes. 92 2. Terminology 94 Intermediate Node A router, switch, firewall or any other device 95 which separates end-nodes. The tests in this document can be 96 completed with any intermediate node which maintains a neighbor 97 cache, although not all measurements and performance 98 characteristics may apply. 100 Neighbor Cache See RFC 4861 [RFC4861] 102 Neighbor Discovery See Section of RFC 4861 104 Scanner Network The network from which the scanning tester is 105 connected. 107 Scanning Interface The interface from which the scanning activity is 108 initiated. 110 Stale Entry Time See RFC 4861 112 Target Network The network for which the scanning tests is targeted. 114 Target Network Destination Interface The interface that resides on 115 the target network, which is primarily used to measure DUT 116 performance while the scanning activity is occurring. 118 3. Overview of Relevant NDP and Intermediate Node Behavior 120 Network elements map IP addresses to link-layer addresses. ARP 121 [RFC0826] manages the mapping process for IPv4, while the Neighbor 122 Discovery Protocol [RFC4861] manages mapping for IPv6. With IPv6, 123 when a node forwards a packet: 125 1. The node determines if the destination IPv6 address is present in 126 its neighbor cache. 128 2. If the address is present in the neighbor cache, the node 129 forwards the packet to the destination node using the appropriate 130 link-layer address. 132 3. If the destination IPv6 address is not in the intermediate node's 133 neighbor cache: 135 1. An entry for the IPv6 address is added to the neighbor cache 136 and the entry is marked "INCOMPLETE". 138 2. The intermediate node sends an ICMP Neighbor Solicitation 139 (NS) packet. 141 3. If an ICMP Neighbor Advertisement (NA) for the IPv6 address 142 is received by the node, the neighbor cache entry is marked 143 "REACHABLE" and remains in this state for 15 to 45 seconds. 145 4. If a neighbor advertisement is not received, the intermediate 146 node will continue sending NS packets every second until 147 either an NA is received or the maximum number of 148 solicitations has been sent. If an NA is not received in 149 this period, the entry can be discarded. 151 There are two scenarios where a neighbor cache can grow to a very 152 large size: 154 1. There are a large number of real nodes connected via an interface 155 and a large number of these nodes are sending and receiving 156 traffic simultaneously. 158 2. There are a large number of addresses for which a scanning 159 activity is occurring and no real node will respond to the 160 neighbor solicitation. This scanning activity can be 161 unintentional or malicious. In addition to maintaining the 162 "INCOMPLETE" neighbor cache entry, the intermediate node must 163 send a NS packet every second for the maximum number of 164 solicitations. 166 A node's neighbor cache is of a finite size and can only accommodate 167 a specific number of entries, which can be limited by available 168 memory or a preset operating system limit. If the maximum number of 169 entries in a neighbor cache is reached, the intermediate node must 170 either drop an existing entry to make space for the new entry or deny 171 the new IP address to MAC address/ interface mapping with an entry in 172 the neighbor cache. In an extreme case, the intermediate node's 173 memory may become exhausted, causing the intermediate node to crash 174 or page memory. 176 RFC 6583 [RFC6583] describes a how a port scan can cause neighbor 177 cache exhaustion. 179 Section 7.1 of RFC 6583 describes how nodes should behave when the 180 neighbor cache is exhausted. Section 6 of RFC 6583 [RFC6583] 181 recommends how damage from an IPv6 address scan may be mitigated. 182 Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning. 184 4. Test Setup 186 The network has two subnets. These connect the DUT to the scanning 187 and target networks. 189 It is assumed that the latency for all network segments is 190 negligible. By default, the target network's subnet shall be 64-bits 191 in length, although some tests may involve increasing the prefix 192 length. 194 Although packet size shouldn't have a direct impact, packet per 195 second (pps) rates will have an impact. Smaller packet sizes should 196 be utilized to facilitate higher packet per second rates. 198 For purposes of this test, the packet type being sent by the scanning 199 device isn't important, although most scanning applications might 200 want to send packets that would elicit responses from nodes within a 201 subnet (such as an ICMPv6 echo request). Since it is not intended 202 that responses be evoked from the target network node, such packets 203 aren't necessary. 205 At the beginning of each test the intermediate node should be 206 initialized. Minimally, the neighbor cache should be cleared. 208 Basic format of test network. 210 +---------------+ +-----------+ +--------------+ 211 | | Scanner | | Target | | 212 | Scanning |-------------| DUT |-------------|Target Network| 213 | src interface | Network | | Network |dst interface | 214 | | | | | | 215 +---------------+ +-----------+ +--------------+ 217 4.1. Testing Interfaces 219 Two tester interfaces are configured for most tests: 221 o Scanning source (src) interface: This is the interface from which 222 test packets are sourced. This interface sources traffic to 223 destination IPv6 addresses on the target network from a single 224 link-local address, similar to how an adjacent intermediate node 225 would transit traffic through the intermediate node. 227 o Target network destination (dst) interface: This interface 228 responds to neighbor solicitations as appropriate and confirms 229 when an intermediate node has forwarded a packet to the interface 230 for consumption. Where appropriate, the target network 231 destination interface will respond to neighbor solicitations with 232 a unique link-layer address per IPv6 address solicited. 234 5. Modifiers (Variables) 236 5.1. Frequency of NDP Triggering Packets 238 The frequency of NDP triggering packets can be as high as the maximum 239 packet per second rate that the scanner network will support (or is 240 rated for). However, it may not be necessary to send packets at a 241 particularly high rate. In fact, a non-benchmarking goal of testing 242 could be to identify if the DUT is able to withstand scans at rates 243 which otherwise would not impact the performance of the DUT. 245 Optimistically, the scanning rate should be incremented until the 246 DUT's performance begins deteriorating. Depending on the software 247 and system being used to implement the scanning, it may be 248 challenging to achieve a sufficient rate. Where this maximum 249 threshold cannot be determined, the test results should note the 250 highest rate tested and that DUT performance deterioration was not 251 noticed at this rate. 253 The lowest rate tested should be the rate for which packets can be 254 expected to have an impact on the DUT -- this value is of course, 255 subjective. 257 6. Tests 259 6.1. Stale Entry Time Determination 261 This test determines the time interval when the intermediate node 262 (DUT) identifies an address as stale. 264 RFC 4861, section 6.3.2 [RFC4861] states that an address can be 265 marked "stale" at a random value between 15 and 45 seconds (as 266 defined via constants in the RFC). This test confirms what value is 267 being used by the intermediate node. Note that RFC 4861 states that 268 this random time can be changed "at least every few hours." 270 6.1.1. General Testing Procedure 272 1. Send a packet from the scanning source interface to an address in 273 target network. Observe that the intermediate node sends a NS to 274 the solicited-node multicast address on the target network, for 275 which tester destination interface should respond with an NA. 276 The intermediate node should create an entry in neighbor cache 277 for the address, marking the address as "reachable". As this 278 point, the packet should be forwarded to the tester destination 279 interface. 281 2. After the neighbor advertisement from the destination tester 282 interface in step one, the tester will send no more NA messages 284 3. Continue sending packets from the scanning source interface to 285 the same address in the target network. 287 4. Note the time at which the DUT no longer forwards packets. The 288 stale timer value will be the period of time between when the DUT 289 received the first neighbor advertisement above and the point at 290 which the DUT no longer forwards packets for this flow to the 291 tester destination interface. 293 6.2. Neighbor Cache Exhaustion Determination 295 Discover the point at which the neighbor cache is exhausted and 296 evaluate intermediate node behavior when this threshold is reached. 297 If the stale timer is configurable, it should be set to its maximum 298 value.. A side-effect of this test is to confirm that intermediate 299 node behaves correctly; in particular, it shouldn't crash. 301 Note that some intermediate nodes may restrict the frequency of 302 allowed neighbor discovery packets transmitted. The maximum allowed 303 packets per second must either be set to a value which doesn't impact 304 the outcome of the test must allow for this restriction. 306 6.2.1. General Testing Procedure 308 1. At a very fast rate, send packets incrementally to valid unique 309 addresses in the target network, within stale entry time period. 310 Simultaneously, send packets for addresses previously added to 311 the neighbor cache. The neighbor cache has been exhausted when 312 previously added addresses must be re-discovered with a neighbor 313 solicitation (within the stale entry time period). 315 2. Observe what happens when one address greater than the maximum 316 neighbor cache size ("n") is reached. When "n+1" is reached, if 317 either the first or most recent cache entry are dropped, this may 318 be acceptable. 320 3. Confirm intermediate node doesn't crash when "n+1" is reached. 322 6.3. Preference For Previously Discovered Neighbors 324 Determine whether the DUT prefers previously discovered neighbors. 326 6.3.1. General Testing Procedures 328 Repeat the test describe . However, in this test, the test device 329 withholds the NA message for odd numbered IP addresses. At the end 330 of the test, only even numbered IP addresses should appear in the 331 neighbor cache. 333 7. Measurements Explicitly Excluded 335 These are measurements which aren't recommended because of the 336 itemized reasons below: 338 7.1. DUT CPU Utilization 340 This measurement relies on the DUT to provide utilization 341 information, which is subjective. 343 7.2. Malformed Packets 345 This benchmarking test is not intended to test DUT behavior in the 346 presence of malformed packets. 348 8. IANA Considerations 350 This document makes no request of IANA. 352 Note to RFC Editor: this section may be removed on publication as an 353 RFC. 355 9. Security Considerations 357 Benchmarking activities as described in this memo are limited to 358 technology characterization using controlled stimuli in a laboratory 359 environment, with dedicated address space and the constraints 360 specified in the sections above. 362 The benchmarking network topology will be an independent test setup 363 and MUST NOT be connected to devices that may forward the test 364 traffic into a production network, or misroute traffic to the test 365 management network. 367 Further, benchmarking is performed on a "black-box" basis, relying 368 solely on measurements observable external to the DUT/SUT. Special 369 capabilities SHOULD NOT exist in the DUT/SUT specifically for 370 benchmarking purposes. 372 Any implications for network security arising from the DUT/SUT SHOULD 373 be identical in the lab and in production networks. 375 10. Acknowledgements 377 Helpful comments and suggestions were offered by Al Morton, Joel 378 Jaeggli, Nalini Elkins, Scott Bradner, Ram Krishnan, and Marius 379 Georgescu on the BMWG e-mail list and at BMWG meetings. Precise 380 grammatical corrections and suggestions were offered by Ann Cerveny. 382 11. References 384 11.1. Normative References 386 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 387 Converting Network Protocol Addresses to 48.bit Ethernet 388 Address for Transmission on Ethernet Hardware", STD 37, 389 RFC 826, DOI 10.17487/RFC0826, November 1982, 390 . 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 398 Network Interconnect Devices", RFC 2544, 399 DOI 10.17487/RFC2544, March 1999, 400 . 402 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 403 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 404 DOI 10.17487/RFC4861, September 2007, 405 . 407 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 408 Dugatkin, "IPv6 Benchmarking Methodology for Network 409 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 410 2008, . 412 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 413 Neighbor Discovery Problems", RFC 6583, 414 DOI 10.17487/RFC6583, March 2012, 415 . 417 11.2. Informative References 419 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 420 Detection Is Too Impatient", RFC 7048, 421 DOI 10.17487/RFC7048, January 2014, 422 . 424 Authors' Addresses 425 Bill Cerveny 426 Arbor Networks 427 2727 South State Street 428 Ann Arbor, MI 48104 429 USA 431 Email: wcerveny@arbor.net 433 Ron Bonica 434 Juniper Networks 435 2251 Corporate Park Drive 436 Herndon, VA 20170 437 USA 439 Email: rbonica@juniper.net