draft-ietf-bmwg-ipv6-nd-02.txt   draft-ietf-bmwg-ipv6-nd-03.txt 
Network Working Group W. Cerveny Network Working Group W. Cerveny
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational R. Bonica Intended status: Informational R. Bonica
Expires: October 7, 2016 Juniper Networks Expires: March 26, 2017 R. Thomas
April 5, 2016 Juniper Networks
September 22, 2016
Benchmarking IPv6 Neighbor Cache Behavior Benchmarking The Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-02 draft-ietf-bmwg-ipv6-nd-03
Abstract Abstract
This document is a benchmarking instantiation of RFC 6583: This document provides benchmarking procedures for Neighbor Discovery
"Operational Neighbor Discovery Problems" [RFC6583]. It describes a Protocol (NDP). It also proposes metrics by which an NDP
general testing procedure and measurements that can be performed to implementation's scaling capabilities can be measured.
evaluate how the problems described in RFC 6583 may impact the
functionality or performance of intermediate nodes.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 41 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 7, 2016. This Internet-Draft will expire on March 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Relevant NDP and Intermediate Node Behavior . . . 3 2.1. Device Under Test (DUT) . . . . . . . . . . . . . . . . . 4
4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 4
4.1. Testing Interfaces . . . . . . . . . . . . . . . . . . . 5 2.1.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 4
5. Modifiers (Variables) . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Frequency of NDP Triggering Packets . . . . . . . . . . . 5 2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5
6.1. Stale Entry Time Determination . . . . . . . . . . . . . 6 2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6
6.1.1. General Testing Procedure . . . . . . . . . . . . . . 6 2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Neighbor Cache Exhaustion Determination . . . . . . . . . 7 2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6
6.2.1. General Testing Procedure . . . . . . . . . . . . . . 7 2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Preference For Previously Discovered Neighbors . . . . . 7 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3.1. General Testing Procedures . . . . . . . . . . . . . 7 3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8
7. Measurements Explicitly Excluded . . . . . . . . . . . . . . 7 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8
7.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 8 3.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 8 3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.2.2. Results . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document is a benchmarking instantiation of RFC 6583: When an IPv6 node forwards a packet, it executes the following
"Operational Neighbor Discovery Problems" [RFC6583]. It describes a procedure:
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 o Identify the IPv6 next-hop (i.e., the next IPv6 node that the
packet traverses on route to its ultimate destination)
Intermediate Node A router, switch, firewall or any other device o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's
which separates end-nodes. The tests in this document can be link-layer address
completed with any intermediate node which maintains a neighbor
cache, although not all measurements and performance
characteristics may apply.
Neighbor Cache See RFC 4861 [RFC4861] o Encapsulate the packet in a link-layer header. The link-layer
header includes the IPv6 next-hop's link-layer address
Neighbor Discovery See Section of RFC 4861 o Forward the packet to the IPv6 next-hop
Scanner Network The network from which the scanning tester is IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to
connected. maintain the NC. Operational experience [RFC6583] shows that when an
implementation cannot maintain a sufficiently complete NC, its
ability to forward packets is impaired.
Scanning Interface The interface from which the scanning activity is NDP, like any other protocol, consumes processing, memory, and
initiated. bandwidth resources. Its ability to maintain a sufficiently complete
NC depends upon the availability of the above-mentioned resources.
Stale Entry Time See RFC 4861 This document provides benchmarking procedures for NDP. Benchmarking
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,
through Link B, back to the Tester.
Target Network The network for which the scanning tests is targeted. The above-mentioned traffic stream contains 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.
Target Network Destination Interface The interface that resides on In the Baseline Test, the traffic stream contains exactly one flow.
the target network, which is primarily used to measure DUT Because every packet in the stream has the same IPv6 Destination
performance while the scanning activity is occurring. Address, the DUT can forward the entire stream using exactly one NC
entry. NDP is exercised minimally and no packet loss should be
observed.
3. Overview of Relevant NDP and Intermediate Node Behavior The NDP Scaling Test is identical to the Baseline Test, except that
the traffic stream contains many flows. In order to forward the
stream without loss, the DUT must maintain one NC entry for each
flow. If the DUT cannot maintain one NC entry for each flow, packet
loss will be observed and attributed to NDP scaling limitations.
Network elements map IP addresses to link-layer addresses. ARP This document proposes an NDP scaling metric, called NDP-MAX-
[RFC0826] manages the mapping process for IPv4, while the Neighbor NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to
Discovery Protocol [RFC4861] manages mapping for IPv6. With IPv6, which an IPv6 node can send traffic during periods of high NDP
when a node forwards a packet: activity.
1. The node determines if the destination IPv6 address is present in The procedures described herein reveal how many IPv6 neighbors an NDP
its neighbor cache. implementation can discover. They also provide a rough estimate of
the time required 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.
2. If the address is present in the neighbor cache, the node The test procedures described herein assume that on the DUT, NDP does
forwards the packet to the destination node using the appropriate not compete for resources with other applications. When NDP
link-layer address. completes for resources, its scaling characteristics may not be
commensurate with those reported by the benchmarks described herein.
3. If the destination IPv6 address is not in the intermediate node's 2. Test Setup
neighbor cache:
1. An entry for the IPv6 address is added to the neighbor cache +---------------+ +-----------+
and the entry is marked "INCOMPLETE". | | | |
| | Link A | Device |
| |------------>| Under |
| Tester | | Test |
| |<------------| (DUT) |
| | Link B | |
+---------------+ +-----------+
2. The intermediate node sends an ICMP Neighbor Solicitation Figure 1: Test Setup
(NS) packet.
3. If an ICMP Neighbor Advertisement (NA) for the IPv6 address The DUT is an IPv6 router. The DUT is connected to a Tester by two
is received by the node, the neighbor cache entry is marked links (A and B). Link A capabilities must be identical to Link B
"REACHABLE" and remains in this state for 15 to 45 seconds. 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. Furthermore, Link A and Link B must be
lossless.
4. If a neighbor advertisement is not received, the intermediate 2.1. Device Under Test (DUT)
node will continue sending NS packets every second until
either an NA is received or the maximum number of
solicitations has been sent. If an NA is not received in
this period, the entry can be discarded.
There are two scenarios where a neighbor cache can grow to a very 2.1.1. Interfaces
large size:
1. There are a large number of real nodes connected via an interface DUT interfaces are numbered as follows:
and a large number of these nodes are sending and receiving
traffic simultaneously.
2. There are a large number of addresses for which a scanning o Link A - 2001:2:0:0::2/64
activity is occurring and no real node will respond to the
neighbor solicitation. This scanning activity can be
unintentional or malicious. In addition to maintaining the
"INCOMPLETE" neighbor cache entry, the intermediate node must
send a NS packet every second for the maximum number of
solicitations.
A node's neighbor cache is of a finite size and can only accommodate o Link B- 2001:2:0:1::1/64
a specific number of entries, which can be limited by available
memory or a preset operating system limit. If the maximum number of
entries in a neighbor cache is reached, the intermediate node must
either drop an existing entry to make space for the new entry or deny
the new IP address to MAC address/ interface mapping with an entry in
the neighbor cache. In an extreme case, the intermediate node's
memory may become exhausted, causing the intermediate node to crash
or page memory.
RFC 6583 [RFC6583] describes a how a port scan can cause neighbor Both DUT interfaces should be configured with a 1500-byte MTU.
cache exhaustion. However, if they cannot support a 1500-byte MTU, they may be
configured with a 1280-byte MTU.
Section 7.1 of RFC 6583 describes how nodes should behave when the 2.1.2. Neighbor Discovery Protocol (NDP)
neighbor cache is exhausted. Section 6 of RFC 6583 [RFC6583]
recommends how damage from an IPv6 address scan may be mitigated.
Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning.
4. Test Setup NDP is enabled on both DUT interfaces. Therefore, the DUT emits both
solicited and unsolicited Router Advertisement (RA) messages. The
DUT emits an RA message at least once every 600 seconds and no more
frequently than once every 200 seconds.
The network has two subnets. These connect the DUT to the scanning When the DUT sends an RA message, it includes the following
and target networks. information:
It is assumed that the latency for all network segments is o Router Lifetime - 1800 seconds
negligible. By default, the target network's subnet shall be 64-bits
in length, although some tests may involve increasing the prefix
length.
Although packet size shouldn't have a direct impact, packet per o Reachable Time - 0 seconds
second (pps) rates will have an impact. Smaller packet sizes should
be utilized to facilitate higher packet per second rates.
For purposes of this test, the packet type being sent by the scanning o Retrans Time - 0 seconds
device isn't important, although most scanning applications might
want to send packets that would elicit responses from nodes within a
subnet (such as an ICMPv6 echo request). Since it is not intended
that responses be evoked from the target network node, such packets
aren't necessary.
At the beginning of each test the intermediate node should be o Source Link Layer Address - Link layer address of DUT interface
initialized. Minimally, the neighbor cache should be cleared.
Basic format of test network. The above-mentioned values are chosen because they are the default
values specified in RFC 4861.
+---------------+ +-----------+ +--------------+ NDP also manages the NC. Each NC entry represents an on-link
| | Scanner | | Target | | neighbor and is identified by the neighbor's on-link unicast IP
| Scanning |-------------| DUT |-------------|Target Network| address. NC entries contain the neighbor's link-layer address, a
| src interface | Network | | Network |dst interface | state variable, and several timers that are used by the Neighbor
| | | | | | Unreachability Detection (NUD) algorithm. Section 7.3 of RFC 4861
+---------------+ +-----------+ +--------------+ provides NUD details. On the DUT, NUD uses the protocol constants
defined in Section 10 of RFC 4861. As per these specifications, each
NC entry needs to be refreshed at least every 60 seconds. NDP
refreshes NC entries by exchanging Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages.
4.1. Testing Interfaces No static NC entries are configured on the DUT.
Two tester interfaces are configured for most tests: 2.1.3. Routing
o Scanning source (src) interface: This is the interface from which The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It
test packets are sourced. This interface sources traffic to also maintains a direct route to 2001:2:0:1/64 through Link B. No
destination IPv6 addresses on the target network from a single static routes or dynamic routing protocols are configured on the DUT.
link-local address, similar to how an adjacent intermediate node
would transit traffic through the intermediate node.
o Target network destination (dst) interface: This interface 2.2. Tester
responds to neighbor solicitations as appropriate and confirms
when an intermediate node has forwarded a packet to the interface
for consumption. Where appropriate, the target network
destination interface will respond to neighbor solicitations with
a unique link-layer address per IPv6 address solicited.
5. Modifiers (Variables) 2.2.1. Interfaces
5.1. Frequency of NDP Triggering Packets Interfaces are numbered as follows:
The frequency of NDP triggering packets can be as high as the maximum o Link A - 2001:2:0:0::1/64
packet per second rate that the scanner network will support (or is
rated for). However, it may not be necessary to send packets at a
particularly high rate. In fact, a non-benchmarking goal of testing
could be to identify if the DUT is able to withstand scans at rates
which otherwise would not impact the performance of the DUT.
Optimistically, the scanning rate should be incremented until the o Link B - Multiple addresses are configured on Link B. These
DUT's performance begins deteriorating. Depending on the software addresses are drawn sequentially from the 2001:2:0:1::/64 address
and system being used to implement the scanning, it may be block. The first address is 2001:2:0:1::2/64. Subsequent
challenging to achieve a sufficient rate. Where this maximum addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64,
threshold cannot be determined, the test results should note the 2001:2:0:1::5/64, et cetera. The number of configured addresses
highest rate tested and that DUT performance deterioration was not should be the expected value of NDP-MAX-NEIGHBORS times 1.1.
noticed at this rate.
The lowest rate tested should be the rate for which packets can be Both Tester interfaces should be configured with a 1500-byte MTU.
expected to have an impact on the DUT -- this value is of course, However, if they cannot support a 1500-byte MTU, they may be
subjective. configured with a 1280-byte MTU.
6. Tests 2.2.2. Neighbor Discovery Protocol (NDP)
6.1. Stale Entry Time Determination NDP is enabled on both Tester interfaces. Therefore, upon
initiation, 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.
This test determines the time interval when the intermediate node No static NC entries are configured on the Tester.
(DUT) identifies an address as stale.
RFC 4861, section 6.3.2 [RFC4861] states that an address can be 2.2.3. Routing
marked "stale" at a random value between 15 and 45 seconds (as
defined via constants in the RFC). This test confirms what value is
being used by the intermediate node. Note that RFC 4861 states that
this random time can be changed "at least every few hours."
6.1.1. General Testing Procedure The Tester maintains a direct route to 2001:2:0:0/64 through Link A.
It also maintains a direct route to 2001:2:0:1/64 through Link B. No
static routes or dynamic routing protocols are configured on the
Tester.
1. Send a packet from the scanning source interface to an address in 2.2.4. Test Traffic
target network. Observe that the intermediate node sends a NS to
the solicited-node multicast address on the target network, for
which tester destination interface should respond with an NA.
The intermediate node should create an entry in neighbor cache
for the address, marking the address as "reachable". As this
point, the packet should be forwarded to the tester destination
interface.
2. After the neighbor advertisement from the destination tester The Tester sends a stream test traffic through Link A to the DUT.
interface in step one, the tester will send no more NA messages The test traffic stream contains one or more interleaved flows.
Flows are numbered 1 through N, sequentially.
3. Continue sending packets from the scanning source interface to Within each flow, each packet contains an IPv6 header and each IPv6
the same address in the target network. header contains the following information:
4. Note the time at which the DUT no longer forwards packets. The o Version - 6
stale timer value will be the period of time between when the DUT
received the first neighbor advertisement above and the point at
which the DUT no longer forwards packets for this flow to the
tester destination interface.
6.2. Neighbor Cache Exhaustion Determination o Traffic Class - 0
Discover the point at which the neighbor cache is exhausted and o Flow Label - 0
evaluate intermediate node behavior when this threshold is reached.
If the stale timer is configurable, it should be set to its maximum
value.. A side-effect of this test is to confirm that intermediate
node behaves correctly; in particular, it shouldn't crash.
Note that some intermediate nodes may restrict the frequency of o Payload Length - 0
allowed neighbor discovery packets transmitted. The maximum allowed
packets per second must either be set to a value which doesn't impact
the outcome of the test must allow for this restriction.
6.2.1. General Testing Procedure o Next Header - IPv6-NoNxt (59)
1. At a very fast rate, send packets incrementally to valid unique o Hop Limit - 255
addresses in the target network, within stale entry time period.
Simultaneously, send packets for addresses previously added to
the neighbor cache. The neighbor cache has been exhausted when
previously added addresses must be re-discovered with a neighbor
solicitation (within the stale entry time period).
2. Observe what happens when one address greater than the maximum o Source Address - 2001:2:0:0::1
neighbor cache size ("n") is reached. When "n+1" is reached, if
either the first or most recent cache entry are dropped, this may
be acceptable.
3. Confirm intermediate node doesn't crash when "n+1" is reached. o Destination Address - The first 64 bits of the Destination Address
are 2001:2:0:1::. The next 64 are uniquely associated with the
flow. Every packet in the first flow carries the Destination
address 2001:2:0:1::2. Every subsequent flow has an IP address
one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4,
etc.)
6.3. Preference For Previously Discovered Neighbors In order to avoid link congestion, test traffic is offered at a rate
not to exceed 50% of available link bandwidth. In order to avoid
burstiness and buffer occupancy, every packet in the stream is
exactly 40 bytes long (i.e., the length of an IPv6 header with no
IPv6 payload). Furthermore, the gap between packets is identical.
Determine whether the DUT prefers previously discovered neighbors. During the course of a test procedure, the number of flows that the
test stream contains may increase. When this occurs, the rate at
which test traffic is offered remains constant. For example, assume
that a test stream is offered at a rate of 1,000 packets per second.
This stream contains two flows, each contributing 500 packets per
second to the 1,000 packet per second aggregate. When a third stream
is added to the flow, all three streams must contribute 333 packets
per second in order to maintain the 1,000 packet per second limit.
(As in this example, rounding error is acceptable.)
6.3.1. General Testing Procedures The DUT attempts to forward every packet in the test stream through
Link B to the Tester. It does this because:
Repeat the test describe . However, in this test, the test device o Every packet in the test stream has a destination address drawn
withholds the NA message for odd numbered IP addresses. At the end from the 2001:2:0:1::/64 address block
of the test, only even numbered IP addresses should appear in the
neighbor cache.
7. Measurements Explicitly Excluded o The DUT has a direct route to 2001:2:0:1/64 through Link B
2.2.5. Counters
For each address configured on the Tester interface to Link B, two
counters are configured. One counter, configured on the Tester
interface to Link A, increments when the Tester detects an outgoing
packet from the associated flow. The other counter, configured on
the Tester interface to Link B, increments when the Tester detects an
incoming packet from the associated flow. In order for a packet to
be associated with a flow, the following conditions must all be true:
o The IPv6 Destination Address must be that of the flow
o The IPv6 Next Header must be IPv6-NoNxt (59)
The following counters also are configured on both Tester Interfaces:
o RS packets sent
o RS packets received
o RA packets sent
o RA packets received
o NS packets sent
o NS packets received
o NA packets sent
o NA packets received
o Total packets sent
o Total packets received
3. Tests
3.1. Baseline Test
The purpose of the Baseline Test is to ensure that the DUT can
forward every packet in the test stream, wThithout loss, when NDP is
minimally exercised and not operating near its scaling limit.
3.1.1. Procedure
o Reset all counters on the Tester
o Clear the NC on the DUT
o Set a timer to expire in 60 seconds
o Start the test stream with exactly one flow (i.e., IPv6
Destination Address equals 2001:2:0:1::2)
o Wait for either the timer to expire or the packets-received
counter associated with the flow to increment
o If the timer expires, stop the test stream and end the test
o If the packets-received counter increments, pause the traffic
stream, clear the timer, log the counters associated with the
flow, clear the counters associated with the flow, reset the timer
to expire in 1800 seconds and restart the traffic stream
o When the timer expires, stop the test stream, log all counters and
end the test
3.1.2. Results
The two counters associated with the flow (packets-sent and packets-
received) must have equal values. If they do not, an error has
occurred. Because this error is likely to affect Scaling Test
results, the error must be corrected before the Scaling Test is
executed.
The log contains two counters (packets-sent and packets-received) for
the flow. If these values are identical, none of the initial packets
belonging to the flow were lost. However, if packets-sent is greater
than packets received, initial packets were lost. This loss of
initial packets is acceptable.
3.2. Scaling Test
The purpose of the Scaling Test is to discover the number of
neighbors to which an IPv6 node can send traffic during periods of
high NDP activity. We call this number NDP-MAX-NEIGHBORS.
3.2.1. Procedure
Execute the following procedure:
o Clear all counters on the Tester
o Clear the NC on the DUT
o Set a timer to expire in 60 seconds
o Start the test stream with exactly one flow (i.e., IPv6
Destination Address equals 2001:2:0:1::2)
o Wait for either the timer to expire or the packets-received
counter associated with the flow to increment
o If the timer expires, stop the test stream and end the test
o If the packets-received counter increments, proceed as described
below:
Execute the following procedure N times, starting at 2 and ending at
the number of expected value of NDP-MAX-NEIGHBORS time 1.1.
o Pause the test stream
o Clear the timer
o Log the time, the value of N minus one, and the packets-sent and
packets-received counters associated with the previous flow (i.e.,
N minus one)
o Clear the packets-sent and packets-received counters associated
with the previous flow (i.e., N minus one)
o Reset the timer to expire in 60 seconds
o Add the next flow to the test stream (i.e.,IPv6 Destination
Address is a function of N)
o Restart the test stream
o Wait for either the timer to expire or the packets-received
counter associated with the new flow to increment
After the above described procedure had been executed 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.
3.2.2. Results
The test report includes the following:
o A description of the DUT (make, model, processor, memory,
interfaces)
o Rate at which the Tester offers test traffic to the DUT (measured
in packets per second)
o A log that records the time at which each flow was introduced to
the test stream
o All counter values
NDP-MAX-NEIGHBORS is equal to the number of counter pairs where
packets-sent is equal to packets-recieved. Two counters are members
of a pair if they are both associated with the same IPv6 address. If
packets-sent is greater than zero and equal to packets-recieved for
every counter pair, the test should be repeated with a larger
expected value of NDP-MAX-NEIGHBORS.
If an implementation abides by the recommendation of RFC 6583, for
any given counter pair, packets-received will either be equal to zero
or packets-received.
The log documents the time at which each flow was introduced to the
test stream. This log reveals the effect of NC size to the time
required to discover a new IPv6 neighbor.
The log contains two counters (packets-sent and packets-received) for
each flow. If these values are identical, none of the initial
packets belonging to the flow were lost. However, if packets-sent is
greater than packets received, initial packets were lost. This loss
of initial packets is acceptable.
4. Measurements Explicitly Excluded
These are measurements which aren't recommended because of the These are measurements which aren't recommended because of the
itemized reasons below: itemized reasons below:
7.1. DUT CPU Utilization 4.1. DUT CPU Utilization
This measurement relies on the DUT to provide utilization This measurement relies on the DUT to provide utilization
information, which is subjective. information, which is subjective.
7.2. Malformed Packets 4.2. Malformed Packets
This benchmarking test is not intended to test DUT behavior in the This benchmarking test is not intended to test DUT behavior in the
presence of malformed packets. presence of malformed packets.
8. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
9. Security Considerations 6. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test traffic into a production network, or misroute traffic to the test
management network. management network.
Further, benchmarking is performed on a "black-box" basis, relying Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT. Special solely on measurements observable external to the DUT/SUT. Special
capabilities SHOULD NOT exist in the DUT/SUT specifically for capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. benchmarking purposes.
Any implications for network security arising from the DUT/SUT SHOULD Any implications for network security arising from the DUT/SUT SHOULD
be identical in the lab and in production networks. be identical in the lab and in production networks.
10. Acknowledgements 7. Acknowledgements
Helpful comments and suggestions were offered by Al Morton, Joel Helpful comments and suggestions were offered by Al Morton, Joel
Jaeggli, Nalini Elkins, Scott Bradner, Ram Krishnan, and Marius Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG
Georgescu on the BMWG e-mail list and at BMWG meetings. Precise e-mail list and at BMWG meetings. Precise grammatical corrections
grammatical corrections and suggestions were offered by Ann Cerveny. and suggestions were offered by Ann Cerveny.
11. References
11.1. Normative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 8. Normative References
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<http://www.rfc-editor.org/info/rfc2544>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May
2008, <http://www.rfc-editor.org/info/rfc5180>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012, DOI 10.17487/RFC6583, March 2012,
<http://www.rfc-editor.org/info/rfc6583>. <http://www.rfc-editor.org/info/rfc6583>.
11.2. Informative References
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection Is Too Impatient", RFC 7048,
DOI 10.17487/RFC7048, January 2014,
<http://www.rfc-editor.org/info/rfc7048>.
Authors' Addresses Authors' Addresses
Bill Cerveny Bill Cerveny
Arbor Networks Arbor Networks
2727 South State Street 2727 South State Street
Ann Arbor, MI 48104 Ann Arbor, MI 48104
USA USA
Email: wcerveny@arbor.net Email: wcerveny@arbor.net
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
skipping to change at line 440 skipping to change at page 13, line 4
Email: wcerveny@arbor.net Email: wcerveny@arbor.net
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Reji Thomas
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore, KA 560103
India
Email: rejithomas@juniper.net
 End of changes. 80 change blocks. 
253 lines changed or deleted 383 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/