idnits 2.17.1 draft-ietf-bmwg-ipv6-nd-01.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 (January 5, 2016) is 3033 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2544' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC5180' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC7048' is defined on line 428, 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: July 8, 2016 Juniper Networks 6 January 5, 2016 8 Benchmarking IPv6 Neighbor Cache Behavior 9 draft-ietf-bmwg-ipv6-nd-01 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 July 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Testing Interfaces . . . . . . . . . . . . . . . . . . . 6 64 5. Modifiers (Variables) . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Frequency of NDP Triggering Packets . . . . . . . . . . . 6 66 6. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Stale Entry Time Determination . . . . . . . . . . . . . 6 68 6.1.1. General Testing Procedure . . . . . . . . . . . . . . 7 69 6.2. Neighbor Cache Exhaustion Determination . . . . . . . . . 7 70 6.2.1. General Testing Procedure . . . . . . . . . . . . . . 7 71 7. Measurements Explicitly Excluded . . . . . . . . . . . . . . 8 72 7.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 8 73 7.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This document is a benchmarking instantiation of RFC 6583: 85 "Operational Neighbor Discovery Problems" [RFC6583]. It describes a 86 general testing procedure and measurements that can be performed to 87 evaluate how the problems described in RFC 6583 may impact the 88 functionality or performance of intermediate nodes. 90 2. Terminology 92 Intermediate Node A router, switch, firewall or any other device 93 which separates end-nodes. The tests in this document can be 94 completed with any intermediate node which maintains a neighbor 95 cache, although not all measurements and performance 96 characteristics may apply. 98 Neighbor Cache The neighbor cache is a database which correlates the 99 link-layer address and the adjacent interface with an IPv6 100 address. 102 Neighbor Discovery See Section 1 of RFC 4861 [RFC4861] 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 This is the duration for which a neighbor cache 111 entry marked "Reachable" will continue to be marked "Reachable" if 112 an update for the address is not received. 114 Target Network The network for which the scanning tests is targeted. 116 Target Network Destination Interface The interface that resides on 117 the target network, which is primarily used to measure DUT 118 performance while the scanning activity is occurring. 120 3. Overview of Relevant NDP and Intermediate Node Behavior 122 In a traditional network, an intermediate node must support a mapping 123 between a connected node's IP address and the connected node's link- 124 layer address and interface the node is connected to. With IPv4, 125 this process is handled by ARP [RFC0826]. With IPv6, this process is 126 handled by NDP and is documented in [RFC4861]. With IPv6, when a 127 packet arrives on one of an intermediate node's interfaces and the 128 destination address is determined to be reachable via an adjacent 129 network: 131 1. The intermediate node first determines if the destination IPv6 132 address is present in its neighbor cache. 134 2. If the address is present in the neighbor cache, the intermediate 135 node forwards the packet to the destination node using the 136 appropriate link-layer address and interface. 138 3. If the destination IPv6 address is not in the intermediate node's 139 neighbor cache: 141 1. An entry for the IPv6 address is added to the neighbor cache 142 and the entry is marked "INCOMPLETE". 144 2. The intermediate node sends a neighbor solicitation packet to 145 the solicited-node multicast address on the interface 146 considered on-link. 148 3. If a solicited neighbor advertisement for the IPv6 address is 149 received by the intermediate node, the neighbor cache entry 150 is marked "REACHABLE" and remains in this state for 15 to 45 151 seconds. 153 4. If a neighbor advertisement is not received, the intermediate 154 node will continue sending neighbor solicitation packets 155 every second until either a neighbor solicitation is received 156 or the maximum number of solicitations has been sent. If a 157 neighbor advertisement is not received in this period, the 158 entry can be discarded. 160 There are two scenarios where a neighbor cache can grow to a very 161 large size: 163 1. There are a large number of real nodes connected via an 164 intermediate node's interface and a large number of these nodes 165 are sending and receiving traffic simultaneously. 167 2. There are a large number of addresses for which a scanning 168 activity is occuring and no real node will respond to the 169 neighbor solicitation. This scanning activity can be 170 unintentional or malicious. In addition to maintaining the 171 "INCOMPLETE" neighbor cache entry, the intermediate node must 172 send a neighbor solicitation packet every second for the maximum 173 number of socicitations. With today's network link bandwidths, a 174 scanning event could cause a lot of entries to be added to the 175 neighbor cache and solicited for in the time that it takes for a 176 neighbor cache entry to be discarded. 178 An intermediate node's neighbor cache is of a finite size and can 179 only accommodate a specific number of entries, which can be limited 180 by available memory or a preset operating system limit. If the 181 maximum number of entries in a neighbor cache is reached, the 182 intermediate node must either drop an existing entry to make space 183 for the new entry or deny the new IP address to MAC address/ 184 interface mapping with an entry in the neighbor cache. In an extreme 185 case, the intermediate node's memory may become exhausted, causing 186 the intermediate node to crash or begin paging memory. 188 At the core of the neighbor discovery problems presented in RFC 6583 189 [RFC6583], unintentional or malicious IPv6 traffic can transit the 190 intermediate node that resembles an IP address scan similar to an 191 IPv4-based network scan. Unlike IPv4 networks, an IPv6 end network 192 is typically configured with a /64 address block, allowing for 193 upwards of 2**64 addresses. When a network node attempts to scan all 194 the addresses in a /64 address block directly attached to the 195 intermediate node, it is possible to create a huge amount of state in 196 the intermediate node's neighbor cache, which may stress processing 197 or memory resources. 199 Section 7.1 of RFC 6583 recommends how intermediate nodes should 200 behave when the neighbor cache is exceeded. Section 6 of RFC 6583 201 [RFC6583] recommends how damage from an IPv6 address scan may be 202 mitigated. Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning. 204 4. Test Setup 206 The network needs to minimally have two subnets: one from which the 207 scanner(s) source their scanning activity and the other which is the 208 target network of the address scans. 210 It is assumed that the latency for all network segments is neglible. 211 By default, the target network's subnet shall be 64-bits in length, 212 although some tests may involve increasing the prefix length. 214 Although packet size shouldn't have a direct impact, packet per 215 second (pps) rates will have an impact. Smaller packet sizes should 216 be utilized to facilitate higher packet per second rates. 218 For purposes of this test, the packet type being sent by the scanning 219 device isn't important, although most scanning applications might 220 want to send packets that would elicit responses from nodes within a 221 subnet (such as an ICMPv6 echo request). Since it is not intended 222 that responses be evoked from the target network node, such packets 223 aren't necessary. 225 At the beginning of each test the intermediate node should be 226 initialized. Minimally, the neighbor cache should be cleared. 228 Basic format of test network. 230 +---------------+ +-----------+ +--------------+ 231 | | Scanner | | Target | | 232 | Scanning |-------------| DUT |-------------|Target Network| 233 | src interface | Network | | Network |dst interface | 234 | | | | | | 235 +---------------+ +-----------+ +--------------+ 236 4.1. Testing Interfaces 238 Two tester interfaces are configured for most tests: 240 o Scanning source (src) interface: This is the interface from which 241 test packets are sourced. This interface sources traffic to 242 destination IPv6 addresses on the target network from a single 243 link-local address, similar to how an adjacent intermediate node 244 would transit traffic through the intermediate node. 246 o Target network destination (dst) interface: This interface 247 responds to neighbor solicitations as appropriate and confirms 248 when an intermediate node has forwarded a packet to the interface 249 for consumption. Where appropriate, the target network 250 destination interface will respond to neighbor solicitations with 251 a unique link-layer address per IPv6 address solicited. 253 5. Modifiers (Variables) 255 5.1. Frequency of NDP Triggering Packets 257 The frequency of NDP triggering packets can be as high as the maximum 258 packet per second rate that the scanner network will support (or is 259 rated for). However, it may not be necessary to send packets at a 260 particularly high rate. In fact, a non-benchmarking goal of testing 261 could be to identify if the DUT is able to withstand scans at rates 262 which otherwise would not impact the performance of the DUT. 264 Optimistically, the scanning rate should be incremented until the 265 DUT's performance begins deteriorating. Depending on the software 266 and system being used to implement the scanning, it may be 267 challenging to achieve a sufficient rate. Where this maximum 268 threshold cannot be determined, the test results should note the 269 highest rate tested and that DUT performance deterioration was not 270 noticed at this rate. 272 The lowest rate tested should be the rate for which packets can be 273 expected to have an impact on the DUT -- this value is of course, 274 subjective. 276 6. Tests 278 6.1. Stale Entry Time Determination 280 This test determines the time interval when the intermediate node 281 (DUT) identifies an address as stale. 283 RFC 4861, section 6.3.2 [RFC4861] states that an address can be 284 marked "stale" at a random value between 15 and 45 seconds (as 285 defined via constants in the RFC). This test confirms what value is 286 being used by the intermediate node. Note that RFC 4861 states that 287 this random time can be changed "at least every few hours." 289 6.1.1. General Testing Procedure 291 1. Send a packet from the scanning source interface to an address in 292 target network. Observe that the intermediate node sends a 293 neighbor solicitation to the solicited-node multicast address on 294 the target network, for which tester destination interface should 295 respond with a neighbor advertisement. The intermediate node 296 should create an entry in neighbor cache for the address, marking 297 the address as "reachable". As this point, the packet should be 298 forwarded to the tester destination interface. 300 2. After the neighbor advertisement from the destination tester 301 interface in step one, no more neighbor advertisements from the 302 tester destination interface should be allowed. 304 3. Continue sending packets from the scanning source interface to 305 the same address in the target network. 307 4. Note the time at which the DUT no longer forwards packets. The 308 stale timer value will be the period of time between when the DUT 309 received the first neighbor advertisement above and the point at 310 which the DUT no longer forwards packets for this flow to the 311 tester destination interface. 313 6.2. Neighbor Cache Exhaustion Determination 315 Discover the point at which the neighbor cache is exhausted and 316 evaluate intermediate node behavior when this threshold is reached. 317 If possible, the stale timer value should be locked down to a large 318 value. A side-effect of this test is to confirm that intermediate 319 node behaves correctly; in particular, it shouldn't crash. 321 Note that some intermediate nodes may restrict the frequency of 322 allowed neighbor discovery packets transmitted. The maximum allowed 323 packets per second must either be set to a value which doesn't impact 324 the outcome of the test must allow for this restriction. 326 6.2.1. General Testing Procedure 328 1. At a very fast rate, send packets incrementally to valid unique 329 addresses in the target network, within stale entry time period. 330 Simultaneously, send packets for addresses previously added to 331 the neighbor cache. The neighbor cache has been exhausted when 332 previously added addresses must be re-discovered with a neighbor 333 solicitation (within the stale entry time period). 335 2. Observe what happens when one address greater than the maximum 336 neighbor cache size ("n") is reached. When "n+1" is reached, if 337 either the first or most recent cache entry are dropped, this may 338 be acceptable. 340 3. Confirm intermediate node doesn't crash when "n+1" is reached. 342 7. Measurements Explicitly Excluded 344 These are measurements which aren't recommended because of the 345 itemized reasons below: 347 7.1. DUT CPU Utilization 349 This measurement relies on the DUT to provide utilization 350 information, which is subjective. 352 7.2. Malformed Packets 354 This benchmarking test is not intended to test DUT behavior in the 355 presence of malformed packets. 357 8. IANA Considerations 359 This document makes no request of IANA. 361 Note to RFC Editor: this section may be removed on publication as an 362 RFC. 364 9. Security Considerations 366 Benchmarking activities as described in this memo are limited to 367 technology characterization using controlled stimuli in a laboratory 368 environment, with dedicated address space and the constraints 369 specified in the sections above. 371 The benchmarking network topology will be an independent test setup 372 and MUST NOT be connected to devices that may forward the test 373 traffic into a production network, or misroute traffic to the test 374 management network. 376 Further, benchmarking is performed on a "black-box" basis, relying 377 solely on measurements observable external to the DUT/SUT. Special 378 capabilities SHOULD NOT exist in the DUT/SUT specifically for 379 benchmarking purposes. 381 Any implications for network security arising from the DUT/SUT SHOULD 382 be identical in the lab and in production networks. 384 10. Acknowledgements 386 Helpful comments and suggestions were offered by Al Morton, Joel 387 Jaeggli, Nalini Elkins, Scott Bradner, Ram Krishnan, and Marius 388 Georgescu on the BMWG e-mail list and at BMWG meetings. Precise 389 grammatical corrections and suggestions were offered by Ann Cerveny. 391 11. References 393 11.1. Normative References 395 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 396 Converting Network Protocol Addresses to 48.bit Ethernet 397 Address for Transmission on Ethernet Hardware", STD 37, 398 RFC 826, DOI 10.17487/RFC0826, November 1982, 399 . 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 407 Network Interconnect Devices", RFC 2544, 408 DOI 10.17487/RFC2544, March 1999, 409 . 411 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 412 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 413 DOI 10.17487/RFC4861, September 2007, 414 . 416 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 417 Dugatkin, "IPv6 Benchmarking Methodology for Network 418 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 419 2008, . 421 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 422 Neighbor Discovery Problems", RFC 6583, 423 DOI 10.17487/RFC6583, March 2012, 424 . 426 11.2. Informative References 428 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 429 Detection Is Too Impatient", RFC 7048, 430 DOI 10.17487/RFC7048, January 2014, 431 . 433 Authors' Addresses 435 Bill Cerveny 436 Arbor Networks 437 2727 South State Street 438 Ann Arbor, MI 48104 439 USA 441 Email: wcerveny@arbor.net 443 Ron Bonica 444 Juniper Networks 445 2251 Corporate Park Drive 446 Herndon, VA 20170 447 USA 449 Email: rbonica@juniper.net