draft-ietf-bmwg-ipv6-nd-01.txt   draft-ietf-bmwg-ipv6-nd-02.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: July 8, 2016 Juniper Networks Expires: October 7, 2016 Juniper Networks
January 5, 2016 April 5, 2016
Benchmarking IPv6 Neighbor Cache Behavior Benchmarking IPv6 Neighbor Cache Behavior
draft-ietf-bmwg-ipv6-nd-01 draft-ietf-bmwg-ipv6-nd-02
Abstract Abstract
This document is a benchmarking instantiation of RFC 6583: This document is a benchmarking instantiation of RFC 6583:
"Operational Neighbor Discovery Problems" [RFC6583]. It describes a "Operational Neighbor Discovery Problems" [RFC6583]. It describes a
general testing procedure and measurements that can be performed to general testing procedure and measurements that can be performed to
evaluate how the problems described in RFC 6583 may impact the evaluate how the problems described in RFC 6583 may impact the
functionality or performance of intermediate nodes. functionality or performance of intermediate nodes.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 July 8, 2016. This Internet-Draft will expire on October 7, 2016.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Overview of Relevant NDP and Intermediate Node Behavior . . . 3 3. Overview of Relevant NDP and Intermediate Node Behavior . . . 3
4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Testing Interfaces . . . . . . . . . . . . . . . . . . . 6 4.1. Testing Interfaces . . . . . . . . . . . . . . . . . . . 5
5. Modifiers (Variables) . . . . . . . . . . . . . . . . . . . . 6 5. Modifiers (Variables) . . . . . . . . . . . . . . . . . . . . 5
5.1. Frequency of NDP Triggering Packets . . . . . . . . . . . 6 5.1. Frequency of NDP Triggering Packets . . . . . . . . . . . 5
6. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Stale Entry Time Determination . . . . . . . . . . . . . 6 6.1. Stale Entry Time Determination . . . . . . . . . . . . . 6
6.1.1. General Testing Procedure . . . . . . . . . . . . . . 7 6.1.1. General Testing Procedure . . . . . . . . . . . . . . 6
6.2. Neighbor Cache Exhaustion Determination . . . . . . . . . 7 6.2. Neighbor Cache Exhaustion Determination . . . . . . . . . 7
6.2.1. General Testing Procedure . . . . . . . . . . . . . . 7 6.2.1. General Testing Procedure . . . . . . . . . . . . . . 7
7. Measurements Explicitly Excluded . . . . . . . . . . . . . . 8 6.3. Preference For Previously Discovered Neighbors . . . . . 7
6.3.1. General Testing Procedures . . . . . . . . . . . . . 7
7. Measurements Explicitly Excluded . . . . . . . . . . . . . . 7
7.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 8 7.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 8
7.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 8 7.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document is a benchmarking instantiation of RFC 6583: This document is a benchmarking instantiation of RFC 6583:
"Operational Neighbor Discovery Problems" [RFC6583]. It describes a "Operational Neighbor Discovery Problems" [RFC6583]. It describes a
general testing procedure and measurements that can be performed to general testing procedure and measurements that can be performed to
evaluate how the problems described in RFC 6583 may impact the evaluate how the problems described in RFC 6583 may impact the
functionality or performance of intermediate nodes. functionality or performance of intermediate nodes.
2. Terminology 2. Terminology
Intermediate Node A router, switch, firewall or any other device Intermediate Node A router, switch, firewall or any other device
which separates end-nodes. The tests in this document can be which separates end-nodes. The tests in this document can be
completed with any intermediate node which maintains a neighbor completed with any intermediate node which maintains a neighbor
cache, although not all measurements and performance cache, although not all measurements and performance
characteristics may apply. characteristics may apply.
Neighbor Cache The neighbor cache is a database which correlates the Neighbor Cache See RFC 4861 [RFC4861]
link-layer address and the adjacent interface with an IPv6
address.
Neighbor Discovery See Section 1 of RFC 4861 [RFC4861] Neighbor Discovery See Section of RFC 4861
Scanner Network The network from which the scanning tester is Scanner Network The network from which the scanning tester is
connected. connected.
Scanning Interface The interface from which the scanning activity is Scanning Interface The interface from which the scanning activity is
initiated. initiated.
Stale Entry Time This is the duration for which a neighbor cache Stale Entry Time See RFC 4861
entry marked "Reachable" will continue to be marked "Reachable" if
an update for the address is not received.
Target Network The network for which the scanning tests is targeted. Target Network The network for which the scanning tests is targeted.
Target Network Destination Interface The interface that resides on Target Network Destination Interface The interface that resides on
the target network, which is primarily used to measure DUT the target network, which is primarily used to measure DUT
performance while the scanning activity is occurring. performance while the scanning activity is occurring.
3. Overview of Relevant NDP and Intermediate Node Behavior 3. Overview of Relevant NDP and Intermediate Node Behavior
In a traditional network, an intermediate node must support a mapping Network elements map IP addresses to link-layer addresses. ARP
between a connected node's IP address and the connected node's link- [RFC0826] manages the mapping process for IPv4, while the Neighbor
layer address and interface the node is connected to. With IPv4, Discovery Protocol [RFC4861] manages mapping for IPv6. With IPv6,
this process is handled by ARP [RFC0826]. With IPv6, this process is when a node forwards a packet:
handled by NDP and is documented in [RFC4861]. With IPv6, when a
packet arrives on one of an intermediate node's interfaces and the
destination address is determined to be reachable via an adjacent
network:
1. The intermediate node first determines if the destination IPv6 1. The node determines if the destination IPv6 address is present in
address is present in its neighbor cache. its neighbor cache.
2. If the address is present in the neighbor cache, the intermediate 2. If the address is present in the neighbor cache, the node
node forwards the packet to the destination node using the forwards the packet to the destination node using the appropriate
appropriate link-layer address and interface. link-layer address.
3. If the destination IPv6 address is not in the intermediate node's 3. If the destination IPv6 address is not in the intermediate node's
neighbor cache: neighbor cache:
1. An entry for the IPv6 address is added to the neighbor cache 1. An entry for the IPv6 address is added to the neighbor cache
and the entry is marked "INCOMPLETE". and the entry is marked "INCOMPLETE".
2. The intermediate node sends a neighbor solicitation packet to 2. The intermediate node sends an ICMP Neighbor Solicitation
the solicited-node multicast address on the interface (NS) packet.
considered on-link.
3. If a solicited neighbor advertisement for the IPv6 address is 3. If an ICMP Neighbor Advertisement (NA) for the IPv6 address
received by the intermediate node, the neighbor cache entry is received by the node, the neighbor cache entry is marked
is marked "REACHABLE" and remains in this state for 15 to 45 "REACHABLE" and remains in this state for 15 to 45 seconds.
seconds.
4. If a neighbor advertisement is not received, the intermediate 4. If a neighbor advertisement is not received, the intermediate
node will continue sending neighbor solicitation packets node will continue sending NS packets every second until
every second until either a neighbor solicitation is received either an NA is received or the maximum number of
or the maximum number of solicitations has been sent. If a solicitations has been sent. If an NA is not received in
neighbor advertisement is not received in this period, the this period, the entry can be discarded.
entry can be discarded.
There are two scenarios where a neighbor cache can grow to a very There are two scenarios where a neighbor cache can grow to a very
large size: large size:
1. There are a large number of real nodes connected via an 1. There are a large number of real nodes connected via an interface
intermediate node's interface and a large number of these nodes and a large number of these nodes are sending and receiving
are sending and receiving traffic simultaneously. traffic simultaneously.
2. There are a large number of addresses for which a scanning 2. There are a large number of addresses for which a scanning
activity is occuring and no real node will respond to the activity is occurring and no real node will respond to the
neighbor solicitation. This scanning activity can be neighbor solicitation. This scanning activity can be
unintentional or malicious. In addition to maintaining the unintentional or malicious. In addition to maintaining the
"INCOMPLETE" neighbor cache entry, the intermediate node must "INCOMPLETE" neighbor cache entry, the intermediate node must
send a neighbor solicitation packet every second for the maximum send a NS packet every second for the maximum number of
number of socicitations. With today's network link bandwidths, a solicitations.
scanning event could cause a lot of entries to be added to the
neighbor cache and solicited for in the time that it takes for a
neighbor cache entry to be discarded.
An intermediate node's neighbor cache is of a finite size and can A node's neighbor cache is of a finite size and can only accommodate
only accommodate a specific number of entries, which can be limited a specific number of entries, which can be limited by available
by available memory or a preset operating system limit. If the memory or a preset operating system limit. If the maximum number of
maximum number of entries in a neighbor cache is reached, the entries in a neighbor cache is reached, the intermediate node must
intermediate node must either drop an existing entry to make space either drop an existing entry to make space for the new entry or deny
for the new entry or deny the new IP address to MAC address/ the new IP address to MAC address/ interface mapping with an entry in
interface mapping with an entry in the neighbor cache. In an extreme the neighbor cache. In an extreme case, the intermediate node's
case, the intermediate node's memory may become exhausted, causing memory may become exhausted, causing the intermediate node to crash
the intermediate node to crash or begin paging memory. or page memory.
At the core of the neighbor discovery problems presented in RFC 6583 RFC 6583 [RFC6583] describes a how a port scan can cause neighbor
[RFC6583], unintentional or malicious IPv6 traffic can transit the cache exhaustion.
intermediate node that resembles an IP address scan similar to an
IPv4-based network scan. Unlike IPv4 networks, an IPv6 end network
is typically configured with a /64 address block, allowing for
upwards of 2**64 addresses. When a network node attempts to scan all
the addresses in a /64 address block directly attached to the
intermediate node, it is possible to create a huge amount of state in
the intermediate node's neighbor cache, which may stress processing
or memory resources.
Section 7.1 of RFC 6583 recommends how intermediate nodes should Section 7.1 of RFC 6583 describes how nodes should behave when the
behave when the neighbor cache is exceeded. Section 6 of RFC 6583 neighbor cache is exhausted. Section 6 of RFC 6583 [RFC6583]
[RFC6583] recommends how damage from an IPv6 address scan may be recommends how damage from an IPv6 address scan may be mitigated.
mitigated. Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning. Section 6.2 of RFC 6583 [RFC6583] discusses queue tuning.
4. Test Setup 4. Test Setup
The network needs to minimally have two subnets: one from which the The network has two subnets. These connect the DUT to the scanning
scanner(s) source their scanning activity and the other which is the and target networks.
target network of the address scans.
It is assumed that the latency for all network segments is neglible. It is assumed that the latency for all network segments is
By default, the target network's subnet shall be 64-bits in length, negligible. By default, the target network's subnet shall be 64-bits
although some tests may involve increasing the prefix length. in length, although some tests may involve increasing the prefix
length.
Although packet size shouldn't have a direct impact, packet per Although packet size shouldn't have a direct impact, packet per
second (pps) rates will have an impact. Smaller packet sizes should second (pps) rates will have an impact. Smaller packet sizes should
be utilized to facilitate higher packet per second rates. be utilized to facilitate higher packet per second rates.
For purposes of this test, the packet type being sent by the scanning For purposes of this test, the packet type being sent by the scanning
device isn't important, although most scanning applications might device isn't important, although most scanning applications might
want to send packets that would elicit responses from nodes within a want to send packets that would elicit responses from nodes within a
subnet (such as an ICMPv6 echo request). Since it is not intended subnet (such as an ICMPv6 echo request). Since it is not intended
that responses be evoked from the target network node, such packets that responses be evoked from the target network node, such packets
skipping to change at page 7, line 14 skipping to change at page 6, line 35
RFC 4861, section 6.3.2 [RFC4861] states that an address can be RFC 4861, section 6.3.2 [RFC4861] states that an address can be
marked "stale" at a random value between 15 and 45 seconds (as marked "stale" at a random value between 15 and 45 seconds (as
defined via constants in the RFC). This test confirms what value is defined via constants in the RFC). This test confirms what value is
being used by the intermediate node. Note that RFC 4861 states that being used by the intermediate node. Note that RFC 4861 states that
this random time can be changed "at least every few hours." this random time can be changed "at least every few hours."
6.1.1. General Testing Procedure 6.1.1. General Testing Procedure
1. Send a packet from the scanning source interface to an address in 1. Send a packet from the scanning source interface to an address in
target network. Observe that the intermediate node sends a target network. Observe that the intermediate node sends a NS to
neighbor solicitation to the solicited-node multicast address on the solicited-node multicast address on the target network, for
the target network, for which tester destination interface should which tester destination interface should respond with an NA.
respond with a neighbor advertisement. The intermediate node The intermediate node should create an entry in neighbor cache
should create an entry in neighbor cache for the address, marking for the address, marking the address as "reachable". As this
the address as "reachable". As this point, the packet should be point, the packet should be forwarded to the tester destination
forwarded to the tester destination interface. interface.
2. After the neighbor advertisement from the destination tester 2. After the neighbor advertisement from the destination tester
interface in step one, no more neighbor advertisements from the interface in step one, the tester will send no more NA messages
tester destination interface should be allowed.
3. Continue sending packets from the scanning source interface to 3. Continue sending packets from the scanning source interface to
the same address in the target network. the same address in the target network.
4. Note the time at which the DUT no longer forwards packets. The 4. Note the time at which the DUT no longer forwards packets. The
stale timer value will be the period of time between when the DUT stale timer value will be the period of time between when the DUT
received the first neighbor advertisement above and the point at received the first neighbor advertisement above and the point at
which the DUT no longer forwards packets for this flow to the which the DUT no longer forwards packets for this flow to the
tester destination interface. tester destination interface.
6.2. Neighbor Cache Exhaustion Determination 6.2. Neighbor Cache Exhaustion Determination
Discover the point at which the neighbor cache is exhausted and Discover the point at which the neighbor cache is exhausted and
evaluate intermediate node behavior when this threshold is reached. evaluate intermediate node behavior when this threshold is reached.
If possible, the stale timer value should be locked down to a large 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 value.. A side-effect of this test is to confirm that intermediate
node behaves correctly; in particular, it shouldn't crash. node behaves correctly; in particular, it shouldn't crash.
Note that some intermediate nodes may restrict the frequency of Note that some intermediate nodes may restrict the frequency of
allowed neighbor discovery packets transmitted. The maximum allowed allowed neighbor discovery packets transmitted. The maximum allowed
packets per second must either be set to a value which doesn't impact packets per second must either be set to a value which doesn't impact
the outcome of the test must allow for this restriction. the outcome of the test must allow for this restriction.
6.2.1. General Testing Procedure 6.2.1. General Testing Procedure
1. At a very fast rate, send packets incrementally to valid unique 1. At a very fast rate, send packets incrementally to valid unique
skipping to change at page 8, line 15 skipping to change at page 7, line 36
previously added addresses must be re-discovered with a neighbor previously added addresses must be re-discovered with a neighbor
solicitation (within the stale entry time period). solicitation (within the stale entry time period).
2. Observe what happens when one address greater than the maximum 2. Observe what happens when one address greater than the maximum
neighbor cache size ("n") is reached. When "n+1" is reached, if neighbor cache size ("n") is reached. When "n+1" is reached, if
either the first or most recent cache entry are dropped, this may either the first or most recent cache entry are dropped, this may
be acceptable. be acceptable.
3. Confirm intermediate node doesn't crash when "n+1" is reached. 3. Confirm intermediate node doesn't crash when "n+1" is reached.
6.3. Preference For Previously Discovered Neighbors
Determine whether the DUT prefers previously discovered neighbors.
6.3.1. General Testing Procedures
Repeat the test describe . However, in this test, the test device
withholds the NA message for odd numbered IP addresses. At the end
of the test, only even numbered IP addresses should appear in the
neighbor cache.
7. Measurements Explicitly Excluded 7. 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 7.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.
 End of changes. 29 change blocks. 
94 lines changed or deleted 84 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/