idnits 2.17.1 draft-ietf-bmwg-ipv6-nd-06.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 : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2017) is 2606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: September 2, 2017 R. Thomas 6 Juniper Networks 7 March 1, 2017 9 Benchmarking The Neighbor Discovery Protocol 10 draft-ietf-bmwg-ipv6-nd-06 12 Abstract 14 This document provides benchmarking procedures for Neighbor Discovery 15 Protocol (NDP). It also proposes metrics by which an NDP 16 implementation's scaling capabilities can be measured. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 2, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Device Under Test (DUT) . . . . . . . . . . . . . . . . . 4 61 2.1.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 4 62 2.1.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 4 63 2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5 66 2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6 67 2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6 69 2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1.2. Baseline Test Procedure Flow Chart . . . . . . . . . 8 74 3.1.3. Results . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2.2. Scaling Test Procedure Flow Chart . . . . . . . . . . 11 78 3.2.3. Results . . . . . . . . . . . . . . . . . . . . . . . 13 79 4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 14 80 4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 14 81 4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 85 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 When an IPv6 node forwards a packet, it executes the following 91 procedure: 93 o Identifies the outbound interface and IPv6 next-hop 95 o Queries a local Neighbor Cache (NC) to determine the IPv6 next- 96 hop's link-layer address 98 o Encapsulates the packet in a link-layer header. The link-layer 99 header includes the IPv6 next-hop's link-layer address 101 o Forwards the packet to the IPv6 next-hop 103 IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to 104 maintain the NC. Operational experience [RFC6583] shows that when an 105 implementation cannot maintain a sufficiently complete NC, its 106 ability to forward packets is impaired. 108 NDP, like any other protocol, consumes processing, memory, and 109 bandwidth resources. Its ability to maintain a sufficiently complete 110 NC depends upon the availability of the above-mentioned resources. 112 This document provides benchmarking procedures for NDP. Benchmarking 113 procedures include a Baseline Test and an NDP Scaling Test. In both 114 tests, the Device Under Test (DUT) is an IPv6 router. Two physical 115 links (A and B) connect the DUT to a Tester. The Tester sends 116 traffic through Link A to the DUT. The DUT forwards that traffic, 117 through Link B, back to the Tester. 119 The above-mentioned traffic stream contains one or more interleaved 120 flows. An IPv6 Destination Address uniquely identifies each flow. 121 Or, said another way, every packet within a flow has the same IPv6 122 Destination Address. 124 In the Baseline Test, the traffic stream contains exactly one flow. 125 Because every packet in the stream has the same IPv6 Destination 126 Address, the DUT can forward the entire stream using exactly one NC 127 entry. NDP is exercised minimally and no packet loss should be 128 observed. 130 The NDP Scaling Test is identical to the Baseline Test, except that 131 the traffic stream contains many flows. In order to forward the 132 stream without loss, the DUT must maintain one NC entry for each 133 flow. If the DUT cannot maintain one NC entry for each flow, packet 134 loss will be observed and attributed to NDP scaling limitations. 136 This document proposes an NDP scaling metric, called NDP-MAX- 137 NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to 138 which an IPv6 node can send traffic during periods of high NDP 139 activity. 141 The procedures described herein reveal how many IPv6 neighbors an NDP 142 implementation can discover. They also provide a rough estimate of 143 the time required to discover those neighbors. However, that 144 estimate does not reflect the maximum rate at which the 145 implementation can discover neighbors. Maximum rate discovery is a 146 topic for further exploration. 148 The test procedures described herein assume that NDP does not compete 149 with other applications for resources on the DUT. When NDP competes 150 for resources, its scaling characteristics may differ from those 151 reported by the benchmarks described, and may vary over time. 153 2. Test Setup 155 +---------------+ +-----------+ 156 | | | | 157 | | Link A | Device | 158 | |------------>| Under | 159 | Tester | | Test | 160 | |<------------| (DUT) | 161 | | Link B | | 162 +---------------+ +-----------+ 164 Figure 1: Test Setup 166 The DUT is an IPv6 router. Two links (A and B) connect the DUT to 167 the Tester. Link A capabilities must be identical to Link B 168 capabilities. For example, if the interface to Link A is a 10 169 Gigabit Ethernet port, the interface to Link B must also be a 10 170 Gigabit Ethernet port. 172 2.1. Device Under Test (DUT) 174 2.1.1. Interfaces 176 DUT interfaces are numbered as follows: 178 o Link A - 2001:2:0:0::2/64 180 o Link B- 2001:2:0:1::1/64 182 Both DUT interfaces should be configured with a 1500-byte MTU. 183 However, if they cannot support a 1500-byte MTU, they may be 184 configured with a 1280-byte MTU. 186 2.1.2. Neighbor Discovery Protocol (NDP) 188 NDP is enabled on both DUT interfaces. Therefore, the DUT emits both 189 solicited and unsolicited Router Advertisement (RA) messages. The 190 DUT emits an RA message at least once every 600 seconds and no more 191 frequently than once every 200 seconds. 193 When the DUT sends an RA message, it includes the following 194 information: 196 o Router Lifetime - 1800 seconds 198 o Reachable Time - 0 seconds 200 o Retrans Time - 0 seconds 202 o Source Link Layer Address - Link layer address of DUT interface 204 o M-bit is clear (0) 206 o O-bit is clear (0) 208 The above-mentioned values are chosen because they are the default 209 values specified in RFC 4861. 211 NDP manages the NC. Each NC entry represents an on-link neighbor and 212 is identified by the neighbor's on-link unicast IP address. As per 213 RFC 4861, each NC entry needs to be refreshed periodically. NDP 214 refreshes NC entries by exchanging Neighbor Solicitation (NS) and 215 Neighbor Advertisement (NA) messages. 217 No static NC entries are configured on the DUT. 219 2.1.3. Routing 221 The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It 222 also maintains a direct route to 2001:2:0:1/64 through Link B. No 223 static routes or dynamic routing protocols are configured on the DUT. 225 2.2. Tester 227 2.2.1. Interfaces 229 Interfaces are numbered as follows: 231 o Link A - 2001:2:0:0::1/64 233 o Link B - Multiple addresses are configured on Link B. These 234 addresses are drawn sequentially from the 2001:2:0:1::/64 address 235 block. The first address is 2001:2:0:1::2/64. Subsequent 236 addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64, 237 2001:2:0:1::5/64, et cetera. The number of configured addresses 238 should be the expected value of NDP-MAX-NEIGHBORS times 1.1. 240 Both Tester interfaces should be configured with a 1500-byte MTU. 241 However, if they cannot support a 1500-byte MTU, they may be 242 configured with a 1280-byte MTU. 244 2.2.2. Neighbor Discovery Protocol (NDP) 246 NDP is enabled on both Tester interfaces. Therefore, upon 247 initiation, the Tester sends Router Solicitation (RS) messages and 248 waits for Router Advertisement (RA) messages. The Tester also 249 exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 250 messages with the DUT. 252 No static NC entries are configured on the Tester. 254 2.2.3. Routing 256 The Tester maintains a direct route to 2001:2:0:0/64 through Link A. 257 It also maintains a direct route to 2001:2:0:1/64 through Link B. No 258 static routes or dynamic routing protocols are configured on the 259 Tester. 261 2.2.4. Test Traffic 263 The Tester sends a stream of test traffic through Link A to the DUT. 264 The test traffic stream contains one or more interleaved flows. 265 Flows are numbered 1 through N, sequentially. 267 Within each flow, each packet contains an IPv6 header and each IPv6 268 header contains the following information: 270 o Version - 6 272 o Traffic Class - 0 274 o Flow Label - 0 276 o Payload Length - 0 278 o Next Header - IPv6-NoNxt (59) 280 o Hop Limit - 255 282 o Source Address - 2001:2:0:0::1 284 o Destination Address - The first 64 bits of the Destination Address 285 are 2001:2:0:1::. The next 64 are uniquely associated with the 286 flow. Every packet in the first flow carries the Destination 287 address 2001:2:0:1::2. Every subsequent flow has an IP address 288 one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4, 289 etc.) 291 In order to avoid link congestion, test traffic is offered at a rate 292 not to exceed 50% of available link bandwidth. In order to avoid 293 burstiness and buffer occupancy, every packet in the stream is 294 exactly 40 bytes long (i.e., the length of an IPv6 header with no 295 IPv6 payload). Furthermore, the gap between packets is identical. 297 During the course of a test, the number of flows that the test stream 298 contains may increase. When this occurs, the rate at which test 299 traffic is offered remains constant. For example, assume that a test 300 stream is offered at a rate of 1,000 packets per second. This stream 301 contains two flows, each contributing 500 packets per second to the 302 1,000 packet per second aggregate. When a third stream is added to 303 the flow, all three streams must contribute 333 packets per second in 304 order to maintain the 1,000 packet per second limit. (As in this 305 example, rounding error is acceptable.) 307 The DUT attempts to forward every packet in the test stream through 308 Link B to the Tester. It does this because: 310 o Every packet in the test stream has a destination address drawn 311 from the 2001:2:0:1::/64 address block 313 o The DUT has a direct route to 2001:2:0:1/64 through Link B 315 2.2.5. Counters 317 On the Tester, two counters are configured for each flow. One 318 counter, configured on Link A, increments when the Tester sends a 319 packet belonging to the flow. The other counter, configured on Link 320 B, increments when the Tester receives packet from the flow. In 321 order for a packet to be associated with a flow, the following 322 conditions must all be true: 324 o The IPv6 Destination Address must be that of the flow 326 o The IPv6 Next Header must be IPv6-NoNxt (59) 328 The following counters also are configured on both Tester Interfaces: 330 o RS packets sent 332 o RA packets received 334 o NS packets sent 335 o NS packets received 337 o NA packets sent 339 o NA packets received 341 o Total packets sent 343 o Total packets received 345 3. Tests 347 3.1. Baseline Test 349 The purpose of the Baseline Test is to ensure that the DUT can 350 forward every packet in the test stream, without loss, when NDP is 351 minimally exercised and not operating near its scaling limit. 353 3.1.1. Procedure 355 o On the DUT, clear the NC 357 o On the Tester, clear all counters 359 o On the Tester, set a timer to expire in 60 seconds 361 o On the Tester, start the test stream with exactly one flow (i.e., 362 IPv6 Destination Address equals 2001:2:0:1::2) 364 o Wait for either the timer to expire or the packets-received 365 counter associated with the flow to increment 367 o If the timer expires, stop the test stream and end the test 369 o If the packets-received counter increments, pause the traffic 370 stream, log the initial counter values, clear the counters, reset 371 the timer to expire in 1800 seconds and restart the traffic stream 373 o When the timer expires, stop the test stream, wait sufficient time 374 for any queued packets to exit, log the final counter values and 375 end the test 377 3.1.2. Baseline Test Procedure Flow Chart 379 +--------------------------+ 380 | On the DUT, clear the NC | 381 +-------------|------------+ 382 | 383 +------------------v------------------+ 384 | On the tester, clear all counters | 385 +------------------|------------------+ 386 | 387 +------------------v-----------------+ 388 | On the tester, set a | 389 | timer to expire in | 390 | 60 seconds | 391 +------------------|-----------------+ 392 | 393 +------------------v-----------------+ 394 |On the tester, start the test stream| 395 |with exactly one flow (i.e., IPv6 | 396 |destination address equals | 397 |2001:2:0:0:1::2) | 398 +------------------|-----------------+ 399 | 400 +------------------v-----------------+ 401 |Wait for either the timer to expire | 402 |or packets-received counter | 403 |associated with the flow to | 404 |increment | 405 +------------------|-----------------+ 406 | 407 /-------v-------\ 408 / \ Yes +--------------+ 409 |Did timer expire?|-------| End the test | 410 \ / +--------------+ 411 \-------|-------/ 412 | No 413 | 414 /---------v--------\ 415 / \ No +--------------+ 416 |Did packets-received|------| End the test | 417 |counter increment? | +--------------+ 418 \ / 419 \---------|--------/ 420 | Yes 421 | 422 +------------------v-----------------+ 423 |Pause traffic stream, log initial | 424 |counter values, clear the counters, | 425 |reset the time to expire in 1800 | 426 |seconds and restart traffic stream | 427 +------------------|-----------------+ 428 | 429 +------------------v-----------------+ 430 |When timer expires, stop the test | 431 |stream, wait sufficient time for | 432 |any queued packets to exit, log the | 433 |final counter values | 434 +------------------|-----------------+ 435 | 436 +----v---+ 437 |End test| 438 +--------+ 440 Figure 2: Baseline Test Procedure Flow Chart 442 3.1.3. Results 444 The log contains initial and final values for the following counters: 446 o packets-sent 448 o packets-received 450 The initial values of packets-sent and packets-received may be equal 451 to one another. If these values are identical, none of the initial 452 packets belonging to the flow were lost. However, if the initial 453 value of packets-sent is greater than the initial value of packets- 454 received, initial packets were lost. This loss of initial packets is 455 acceptable. 457 The final values of packets-sent and packets-received should be equal 458 to one another. If they are not, an error has occurred. Because 459 this error is likely to affect Scaling Test results, the error must 460 be corrected before the Scaling Test is executed. 462 3.2. Scaling Test 464 The purpose of the Scaling Test is to discover the number of 465 neighbors to which an IPv6 node can send traffic during periods of 466 high NDP activity. We call this number NDP-MAX-NEIGHBORS. 468 3.2.1. Procedure 470 Execute the following procedure: 472 o On the DUT, clear the NC 474 o On the Tester, clear all counters 476 o On the Tester, set a timer to expire in 60 seconds 477 o On the Tester, start the test stream with exactly one flow (i.e., 478 IPv6 Destination Address equals 2001:2:0:1::2) 480 o Wait for either the timer to expire or the packets-received 481 counter associated with the flow to increment 483 o If the timer expires, stop the test stream and end the test 485 o If the packets-received counter increments, proceed as described 486 below: 488 Execute the following procedure N times, starting at 2 and ending at 489 the number of expected value of NDP-MAX-NEIGHBORS times 1.1. 491 o Pause the test stream 493 o Log the time and the value of N minus one 495 o Clear the packets-sent and packets-received counters associated 496 with the previous flow (i.e., N minus one) 498 o Reset the timer to expire in 60 seconds 500 o Add the next flow to the test stream (i.e.,IPv6 Destination 501 Address is a function of N) 503 o Restart the test stream 505 o Wait for either the timer to expire or the packets-received 506 counter associated with the new flow to increment 508 After the above described procedure had been executed N times, clear 509 the timer and reset it to expire in 1800 seconds. When the timer 510 expires, stop the stream, log all counters and end the test (after 511 waiting sufficient time for any queued packets to exit). 513 3.2.2. Scaling Test Procedure Flow Chart 515 +--------------------------+ 516 | On the DUT, clear the NC | 517 +-------------|------------+ 518 | 519 +------------------v------------------+ 520 | On the tester, clear all counters | 521 +------------------|------------------+ 522 | 523 +------------------v-----------------+ 524 | On the tester, set a | 525 | timer to expire in | 526 | 60 seconds | 527 +------------------|-----------------+ 528 | 529 +------------------v-----------------+ 530 |On the tester, start the test stream| 531 |with exactly one flow (i.e., IPv6 | 532 |destination address equals | 533 |2001:2:0:0:1::2) | 534 +------------------|-----------------+ 535 | 536 +------------------v-----------------+ 537 |Wait for either the timer to expire | 538 |or packets-received counter | 539 |associated with the flow to | 540 |increment | 541 +------------------|-----------------+ 542 | 543 /-------v-------\ 544 / \ Yes +--------------+ 545 |Did timer expire?|-------| End test | 546 \ / | and return | 547 \-------|-------/ +--------------+ 548 | No 549 | 550 /---------v--------\ 551 / \ No +--------------+ 552 |Did packets-received|------| End test | 553 |counter increment? | | and return | 554 \ / +--------------+ 555 \---------|--------/ 556 | Yes 557 | 558 +------v------+ 559 | N=2 | 560 +------|------+ 561 | 562 /--------------v-------------\ 563 / Is \ No +----------+ 564 | N < NDP-MAX-NEIGHBORS |----| End test | 565 -------| times 1.1 | +----------+ 566 | \ / 567 | \--------------|-------------/ 568 | | Yes 569 | +-----------v----------+ 570 | |Pause the test stream | 571 | +-----------|----------+ 572 | | 573 | +----------v----------+ 574 | |Log the time and the | 575 | |value of N minus one | 576 | +----------|----------+ 577 | | 578 | +----------v----------+ 579 | |Reset the timer to | 580 | |expire in 60 seconds | 581 | +----------|----------+ 582 | | 583 | +--------------v---------------+ 584 | |Add the next flow to the test | 585 | |stream (i.e., IPv6 destination| 586 | |address is a function of N) | 587 | +--------------|---------------+ 588 | | 589 | +----------v------------+ 590 ------------|Restart the test stream| 591 +-----------------------+ 593 Figure 3: Scaling Test Procedure Flow Chart 595 3.2.3. Results 597 The test report includes the following: 599 o A description of the DUT (make, model, processor, memory, 600 interfaces) 602 o Rate at which the Tester offers test traffic to the DUT (measured 603 in packets per second) 605 o A log that records the time at which each flow was introduced to 606 the test stream and the final value of all counters 608 o The expected value of NDP-MAX-NEIGHBORS 610 o The actual value of NDP-MAX-NEIGHBORS 612 NDP-MAX-NEIGHBORS is equal to the number of counter pairs where 613 packets-sent is equal to packets-received. Two counters are members 614 of a pair if they are both associated with the same flow. If 615 packets-sent is equal to packets-recieved for every counter pair, the 616 test should be repeated with a larger expected value of NDP-MAX- 617 NEIGHBORS. 619 If an implementation abides by the recommendation of Section 7.1 of 620 RFC 6583, for any given counter pair, packets-received will either be 621 equal to zero or packets-sent. 623 The log documents the time at which each flow was introduced to the 624 test stream. This log reveals the effect of NC size to the time 625 required to discover a new IPv6 neighbor. 627 4. Measurements Explicitly Excluded 629 These are measurements which aren't recommended because of the 630 itemized reasons below: 632 4.1. DUT CPU Utilization 634 This measurement relies on the DUT to provide utilization 635 information, which is not externally observable (not black-box). 636 However, some testing organizations may find the CPU utilization is 637 useful auxiliary information specific to the DUT model, etc. 639 4.2. Malformed Packets 641 This benchmarking test is not intended to test DUT behavior in the 642 presence of malformed packets. 644 5. IANA Considerations 646 This document makes no request of IANA. 648 Note to RFC Editor: this section may be removed on publication as an 649 RFC. 651 6. Security Considerations 653 Benchmarking activities as described in this memo are limited to 654 technology characterization using controlled stimuli in a laboratory 655 environment, with dedicated address space and the constraints 656 specified in the sections above. 658 The benchmarking network topology will be an independent test setup 659 and MUST NOT be connected to devices that may forward the test 660 traffic into a production network, or misroute traffic to the test 661 management network. 663 Further, benchmarking is performed on a "black-box" basis, relying 664 solely on measurements observable external to the DUT/SUT. Special 665 capabilities SHOULD NOT exist in the DUT/SUT specifically for 666 benchmarking purposes. 668 Any implications for network security arising from the DUT/SUT SHOULD 669 be identical in the lab and in production networks. 671 7. Acknowledgments 673 Helpful comments and suggestions were offered by Al Morton, Joel 674 Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG 675 e-mail list and at BMWG meetings. Precise grammatical corrections 676 and suggestions were offered by Ann Cerveny. 678 8. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 684 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 685 September 2007. 687 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 688 Neighbor Discovery Problems", RFC 6583, March 2012. 690 Authors' Addresses 692 Bill Cerveny 693 Arbor Networks 694 2727 South State Street 695 Ann Arbor, MI 48104 696 USA 698 Email: wcerveny@arbor.net 700 Ron Bonica 701 Juniper Networks 702 2251 Corporate Park Drive 703 Herndon, VA 20170 704 USA 706 Email: rbonica@juniper.net 707 Reji Thomas 708 Juniper Networks 709 Elnath-Exora Business Park Survey 710 Bangalore, KA 560103 711 India 713 Email: rejithomas@juniper.net