RFC 8161
Benchmarking the Neighbor Discovery Protocol
RFC 8161: Benchmarking the Neighbor Discovery Protocol 💖
Okay bestie, here's the deal with this one 🧚
- Authors: W. Cerveny (Arbor Networks), R. Bonica, and R. Thomas (Juniper Networks)
- Category: Informational
- ISSN: 2070-1721
- Date: May 2017
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Abstract ✨
This doc gives you benchmarking procedures for the Neighbor Discovery Protocol (NDP) 🦋 It also proposes metrics for measuring how well an NDP implementation scales. Main character energy 👑
Status of This Memo 📜
This document is not an Internet Standards Track specification, so it's just published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that. 💅
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc8161. Go check it out 🌈
Copyright Notice 🎀
Copyright (c) 2017 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) as they're in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. Read the fine print, babe 🫶
Table of Contents 🗺️
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Test Setup ......................................................4
2.1. Device Under Test (DUT) ....................................4
2.1.1. Interfaces ..........................................4
2.1.2. Neighbor Discovery Protocol (NDP) ...................5
2.1.3. Routing .............................................5
2.2. Tester .....................................................6
2.2.1. Interfaces ..........................................6
2.2.2. Neighbor Discovery Protocol (NDP) ...................6
2.2.3. Routing .............................................6
2.2.4. Test Traffic ........................................7
2.2.5. Counters ............................................8
3. Tests ...........................................................8
3.1. Baseline Test ..............................................8
3.1.1. Procedure ...........................................9
3.1.2. Baseline Test Procedure Flow Chart ..................9
3.1.3. Results ............................................11
3.2. Scaling Test ..............................................11
3.2.1. Procedure ..........................................11
3.2.2. Scaling Test Procedure Flow Chart ..................13
3.2.3. Results ............................................15
4. Measurements Explicitly Excluded ...............................15
4.1. DUT CPU Utilization .......................................15
4.2. Malformed Packets .........................................15
5. IANA Considerations ............................................16
6. Security Considerations ........................................16
7. Normative References ...........................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................171. Introduction ✨
When an IPv6 node forwards a packet, it runs through this little routine 🦋
- Identifies the outbound interface and IPv6 next hop.
- Queries a local Neighbor Cache (NC) to determine the IPv6 next hop's link-layer address.
- Encapsulates the packet in a link-layer header. The link-layer header includes the IPv6 next hop's link-layer address.
- Forwards the packet to the IPv6 next hop.
IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to keep the NC up to date. Operational experience [RFC6583] shows that when an implementation can't maintain a sufficiently complete NC, its ability to forward packets takes a hit 😭
NDP, like any other protocol, eats up processing, memory, and bandwidth. Whether it can keep a sufficiently complete NC depends on having those resources available 💜
This document gives benchmarking procedures for NDP. The procedures include a Baseline Test and an NDP Scaling Test. In both tests, the Device Under Test (DUT) is an IPv6 router. Two physical links (A and B) connect the DUT to a Tester. The Tester sends traffic through Link A to the DUT. The DUT forwards that traffic back to the Tester through Link B 🌸
The traffic stream described above can contain one or more interleaved flows. An IPv6 Destination Address uniquely identifies each flow. Or, said another way, every packet within a flow has the same IPv6 Destination Address 🎀
In the Baseline Test, the traffic stream contains exactly one flow. Since every packet in the stream has the same IPv6 Destination Address, the DUT can forward the whole stream using exactly one NC entry. NDP barely gets exercised here, and no packet loss should be observed 🍓
The NDP Scaling Test is the same as the Baseline Test, except the traffic stream contains many flows. To forward the stream without loss, the DUT must maintain one NC entry for each flow. If the DUT can't maintain one NC entry per flow, packet loss will show up and get blamed on NDP scaling limitations 💀
This document proposes an NDP scaling metric called NDP-MAX-NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors an IPv6 node can send traffic to during periods of high NDP activity ⭐
The procedures here show how many IPv6 neighbors an NDP implementation can discover. They also give a rough estimate of how long it takes to discover those neighbors. However, that estimate does not reflect the maximum rate at which the implementation can discover neighbors. Maximum rate discovery is a topic for further exploration 🔥
The test procedures here assume that NDP does not compete with other applications for resources on the DUT. When NDP does compete for resources, its scaling characteristics may differ from what the benchmarks report, and they may change over time 🙈
1.1. 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]. Translation: those are the official capital-letter words, and they're read the RFC 2119 way 💅
2. Test Setup 🌈
Here's the layout, picture-perfect ✨
+---------------+ +-----------+
| | | |
| | Link A | Device |
| |------------>| Under |
| Tester | | Test |
| |<------------| (DUT) |
| | Link B | |
+---------------+ +-----------+
Figure 1: Test SetupThe DUT is an IPv6 router. Two links (A and B) connect the DUT to the Tester. Link A capabilities must be identical to Link B capabilities. For example, if the interface to Link A is a 10 Gigabit Ethernet port, the interface to Link B must also be a 10 Gigabit Ethernet port 🫶
2.1. Device Under Test (DUT) 🖥️
2.1.1. Interfaces
The DUT interfaces are numbered like this:
- Link A -
2001:2:0:0::2/64 - Link B -
2001:2:0:1::1/64
Both DUT interfaces should be configured with a 1500-byte MTU. If they can't support a 1500-byte MTU, they may be configured with a 1280-byte MTU 🌸
2.1.2. Neighbor Discovery Protocol (NDP)
NDP is enabled on both DUT interfaces, so the DUT sends both solicited and unsolicited Router Advertisement (RA) messages. The DUT emits an RA message at least once every 600 seconds, and no more often than once every 200 seconds ⏰
When the DUT sends an RA message, it includes the following information:
- Router Lifetime - 1800 seconds
- Reachable Time - 0 seconds
- Retrans Time - 0 seconds
- Source Link-Layer Address - link-layer address of DUT interface
- M-bit is clear (0)
- O-bit is clear (0)
Those values are picked because they're the default values specified in RFC 4861. Iconic defaults, honestly 👑
NDP manages the NC. Each NC entry represents an on-link neighbor and is identified by that neighbor's on-link unicast IP address. As per RFC 4861, each NC entry needs to be refreshed periodically. NDP refreshes NC entries by exchanging Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages 🦋
No static NC entries are configured on the DUT 🙅♀️
2.1.3. Routing
The DUT keeps a direct route to 2001:2:0:0/64 through Link A. It also keeps a direct route to 2001:2:0:1/64 through Link B. No static routes or dynamic routing protocols are configured on the DUT 💜
2.2. Tester 🧪
2.2.1. Interfaces
The interfaces are numbered like this:
- Link A -
2001:2:0:0::1/64 - Link B - Multiple addresses are configured on Link B. These addresses are drawn sequentially from the
2001:2:0:1::/64address block. The first address is2001:2:0:1::2/64. Subsequent addresses are2001:2:0:1::3/64,2001:2:0:1::4/64,2001:2:0:1::5/64, and so on. The number of configured addresses should be the expected value ofNDP-MAX-NEIGHBORStimes 1.1 🍓
Both Tester interfaces should be configured with a 1500-byte MTU. If they can't support a 1500-byte MTU, they may be configured with a 1280-byte MTU 🎀
2.2.2. Neighbor Discovery Protocol (NDP)
NDP is enabled on both Tester interfaces. So, when it starts up, the Tester sends Router Solicitation (RS) messages and waits for Router Advertisement (RA) messages. The Tester also exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages with the DUT 🫶
No static NC entries are configured on the Tester ✨
2.2.3. Routing
The Tester keeps a direct route to 2001:2:0:0/64 through Link A. It also keeps a direct route to 2001:2:0:1/64 through Link B. No static routes or dynamic routing protocols are configured on the Tester 🌸
2.2.4. Test Traffic ✨
okay so the Tester sends a stream of test traffic through Link A to the DUT 🚀 The stream can have one or more interleaved flows, and they're numbered 1 through N, in order.
Every packet in a flow has an IPv6 header, and each header has this info:
- Version -
6 - Traffic Class -
0 - Flow Label -
0 - Payload Length -
0 - Next Header -
IPv6-NoNxt (59) - Hop Limit -
255 - Source Address -
2001:2:0:0::1 - Destination Address - The first 64 bits are
2001:2:0:1::. The next 64 are uniquely tied to the flow. Every packet in the first flow carries2001:2:0:1::2. Every flow after that gets an IP address one greater than the last (so2001:2:0:1::3,2001:2:0:1::4, etc.) 💖
Now the bandwidth part, which is very important bestie 🫶 To avoid link congestion, test traffic is offered at a rate not to exceed 50% of available link bandwidth. To avoid burstiness and buffer occupancy, every packet in the stream is exactly 40 bytes long (aka the length of an IPv6 header with no IPv6 payload). The gap between packets is identical too, so it's super even 🌸
While a test is running, the number of flows can go up. When that happens, the offered rate stays constant. Like, say a stream is offered at 1,000 packets per second. It has two flows, each giving 500 packets per second to that 1,000 total. When a third stream gets added, all three streams must contribute 333 packets per second to keep the 1,000 packet per second limit. (Rounding error is fine here, as in this example 🙈)
The DUT tries to forward every packet in the test stream through Link B to the Tester. It does this because:
- Every packet in the test stream has a Destination Address drawn from the
2001:2:0:1::/64address block. - The DUT has a direct route to
2001:2:0:1/64through Link B.
2.2.5. Counters 🔢
On the Tester, two counters are set up for each flow. One counter, on Link A, goes up when the Tester sends a packet that belongs to the flow. The other counter, on Link B, goes up when the Tester receives a packet from the flow. For a packet to count as part of a flow, all of these conditions must be true:
- The IPv6 Destination Address must be that of the flow.
- The IPv6 Next Header must be
IPv6-NoNxt (59).
Both Tester Interfaces also get these counters:
- RS packets sent
- RA packets received
- NS packets sent
- NS packets received
- NA packets sent
- NA packets received
- Total packets sent
- Total packets received
3. Tests 🎀
3.1. Baseline Test 🌈
The point of the Baseline Test is to check that the DUT can forward every packet in the test stream, without loss, when NDP is only lightly used and isn't anywhere near its scaling limit 💅
3.1.1. Procedure
- On the DUT, clear the NC.
- On the Tester, clear all counters.
- On the Tester, set a timer to expire in 60 seconds.
- On the Tester, start the test stream with exactly one flow (i.e., IPv6 Destination Address equals
2001:2:0:1::2). - Wait for either the timer to expire or the packets-received counter associated with the flow to increment.
- If the timer expires, stop the test stream and end the test.
- If the packets-received counter increments, pause the traffic stream, log the initial counter values, clear the counters, reset the timer to expire in 1800 seconds, and restart the traffic stream.
- When the timer expires, stop the test stream, wait sufficient time for any queued packets to exit, log the final counter values, and end the test.
3.1.2. Baseline Test Procedure Flow Chart 📊
+--------------------------+
| On the DUT, clear the NC |
+-------------|------------+
|
+------------------v------------------+
| On the Tester, clear all counters |
+------------------|------------------+
|
+------------------v-----------------+
| On the Tester, set a |
| timer to expire in |
| 60 seconds |
+------------------|-----------------+
|
+------------------v-----------------+
|On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 |
|Destination Address equals |
|2001:2:0:0:1::2) |
+------------------|-----------------+
|
|
+------------------v-----------------+
|Wait for either the timer to expire |
|or packets-received counter |
|associated with the flow to |
|increment |
+------------------|-----------------+
|
/-------v-------\
/ \ Yes +--------------+
|Did timer expire?|-------| End the test |
\ / +--------------+
\-------|-------/
| No
|
/---------v--------\
/ \ No +--------------+
|Did packets-received|------| End the test |
|counter increment? | +--------------+
\ /
\---------|--------/
| Yes
|
+------------------v-----------------+
|Pause traffic stream, log initial |
|counter values, clear the counters, |
|reset the timer to expire in 1800 |
|seconds, and restart traffic stream |
+------------------|-----------------+
|
+------------------v-----------------+
|When timer expires, stop the test |
|stream, wait sufficient time for |
|any queued packets to exit, log the |
|final counter values |
+------------------|-----------------+
|
+----v---+
|End test|
+--------+
Figure 2: Baseline Test Procedure Flow ChartHeads up bestie 👀 the chart says2001:2:0:0:1::2(with the extra:0:), while the procedure above says2001:2:0:1::2. I copied both exactly as they are, typos and all 🫣
3.1.3. Results 📝
The log holds initial and final values for these counters:
- packets-sent
- packets-received
The initial values of packets-sent and packets-received may be equal to one another. If they're identical, none of the initial packets belonging to the flow were lost. But if the initial value of packets-sent is greater than the initial value of packets-received, then initial packets were lost. That loss of initial packets is acceptable 🫧
The final values of packets-sent and packets-received should be equal to one another. If they aren't, an error has happened 😭 Because this error is likely to mess with Scaling Test results, the error must be corrected before the Scaling Test is executed.
3.2. Scaling Test 🚀
The point of the Scaling Test is to find out how many neighbors an IPv6 node can send traffic to during periods of high NDP activity. We call this number NDP-MAX-NEIGHBORS 👑
3.2.1. Procedure
Execute the following procedure:
- On the DUT, clear the NC.
- On the Tester, clear all counters.
- On the Tester, set a timer to expire in 60 seconds.
- On the Tester, start the test stream with exactly one flow (i.e., IPv6 Destination Address equals
2001:2:0:1::2). - Wait for either the timer to expire or the packets-received counter associated with the flow to increment.
- If the timer expires, stop the test stream and end the test.
- If the packets-received counter increments, execute the following procedure N times, starting at 2 and ending at the expected value of NDP-MAX-NEIGHBORS times 1.1.
- Pause the test stream.
- Log the time and the value of N minus one.
- Clear the packets-sent and packets-received counters associated with the previous flow (i.e., N minus one).
- Reset the timer to expire in 60 seconds.
- Add the next flow to the test stream (i.e., IPv6 Destination Address is a function of N).
- Restart the test stream.
- Wait for either the timer to expire or the packets-received counter associated with the new flow to increment.
After the procedure above has been run N times, clear the timer and reset it to expire in 1800 seconds. When the timer expires, stop the stream, log all counters, and end the test (after waiting sufficient time for any queued packets to exit) 🦋
3.2.2. Scaling Test Procedure Flow Chart 🦋
okay bestie, here's the whole flow chart, and it's giving choreography 💃 every box has to run in order or the whole test is cooked 😭
+--------------------------+
| On the DUT, clear the NC |
+-------------|------------+
|
+------------------v------------------+
| On the Tester, clear all counters |
+------------------|------------------+
|
+------------------v-----------------+
| On the Tester, set a |
| timer to expire in |
| 60 seconds |
+------------------|-----------------+
|
+------------------v-----------------+
|On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 |
|Destination Address equals |
|2001:2:0:0:1::2) |
+------------------|-----------------+
|
+------------------v-----------------+
|Wait for either the timer to expire |
|or packets-received counter |
|associated with the flow to |
|increment |
+------------------|-----------------+
|
/-------v-------\
/ \ Yes +--------------+
|Did timer expire?|-------| End test |
\ / | and return |
\-------|-------/ +--------------+
| No
|
/---------v--------\
/ \ No +--------------+
|Did packets-received|------| End test |
|counter increment? | | and return |
\ / +--------------+
\---------|--------/
| Yes
|
+------v------+
| N=2 |
+------|------+
|
/--------------v-------------\
/ Is \ No +----------+
| N < NDP-MAX-NEIGHBORS |----| End test |
-------| times 1.1 | +----------+
| \ /
| \--------------|-------------/
| | Yes
| +-----------v----------+
| |Pause the test stream |
| +-----------|----------+
| |
| +----------v----------+
| |Log the time and the |
| |value of N minus one |
| +----------|----------+
| |
| +-----------v-----------+
| |Clear the packets-sent |
| |and packets-received |
| |counters associated |
| |with the previous flow |
| |(i.e., N minus one) |
| +-----------|-----------+
| |
| +----------v----------+
| |Reset the timer to |
| |expire in 60 seconds |
| +----------|----------+
| |
| +--------------v---------------+
| |Add the next flow to the test |
| |stream (i.e., IPv6 Destination|
| |Address is a function of N) |
| +--------------|---------------+
| |
| +------v------+
| | N=N+1 |
| +------|------+
| |
| +----------v------------+
------------|Restart the test stream|
+-----------------------+
Figure 3: Scaling Test Procedure Flow Chart3.2.3. Results 📊
the test report is where you show your receipts, bestie 🧾✨ it has to include all of this:
- A description of the DUT (make, model, processor, memory, and interfaces)
- Rate at which the Tester offers test traffic to the DUT (measured in packets per second)
- A log that records the time at which each flow was introduced to the test stream and the final value of all counters
- The expected value of NDP-MAX-NEIGHBORS
- The actual value of NDP-MAX-NEIGHBORS
okay so NDP-MAX-NEIGHBORS is basically the number of counter pairs where packets-sent is equal to packets-received 🫶 two counters count as a pair if they belong to the same flow. and if packets-sent equals packets-received for every pair? the test should be repeated with a larger expected value of NDP-MAX-NEIGHBORS. no skipping that step, it's giving "try again bigger" 💅
if an implementation follows the recommendation in Section 7.1 of RFC 6583, then for any given counter pair, packets-received will either be equal to zero or packets-sent. 🔥
the log is the tea ☕ it shows the time each flow got added to the test stream, and that reveals how much the NC size affects how long it takes to discover a brand new IPv6 neighbor. main character data 👑
4. Measurements Explicitly Excluded 🙈
these measurements are not recommended, and here's why, one by one:
4.1. DUT CPU Utilization 💻
this one relies on the DUT telling you its utilization, which you can't see from outside the box (not black-box). some testing orgs might still find CPU utilization useful as extra info specific to the DUT model and so on, so it's not banned, just not the main event 🌸
4.2. Malformed Packets 💀
this benchmarking test is not meant to check how the DUT behaves when it gets malformed packets. that's a different party 🙅♀️
5. IANA Considerations 🌈
this document does not require any IANA actions. zero registry drama ✨
6. Security Considerations 🔐
okay this section is serious, bestie, so no skipping 😭🫶
benchmarking as described in this memo is 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. 🚨 that is a hard no, periodt.
also, benchmarking is done on a "black-box" basis, relying only on measurements you can observe from outside the DUT or System Under Test (SUT). special capabilities SHOULD NOT exist in the DUT/SUT just for benchmarking purposes. no sneaky benchmark-only cheat codes 🙅♀️
any implications for network security that come up with the DUT/SUT SHOULD be identical in the lab and in production networks. same energy everywhere, no lab-only vibes 💜
7. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
- [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
Acknowledgments 🎀
helpful comments and suggestions came from Al Morton, Joel Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG email list and at BMWG meetings 🫶 precise grammatical corrections and suggestions came from Ann Cerveny. the people who made this possible, iconic 👑
Authors' Addresses 🦋
Bill Cerveny Arbor Networks 2727 South State Street Ann Arbor, MI 48104 United States of America
Email: wcerveny@arbor.net
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20170 United States of America
Email: rbonica@juniper.net
Reji Thomas Juniper Networks Elnath-Exora Business Park Survey Bangalore, KA 560103 India
Email: rejithomas@juniper.net
And that's the whole thing, bestie! 🌈✨ RFC 8161 is a wrap 💖
📦 where this page comes from
- ietf: rfc8161 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms