Subject: [bmwg] Status of draft-cerveny-bmwg-ipv6-nd

From: William Cerveny <[email-masked]>
Date: Mon, 29 Jul 2013 17:58:36 -0400

Dear BMWGers,

I had hoped to provide updates at IETF-87 regarding
draft-cerveny-bmwg-ipv6-nd, but I had to change my travel plans at the
last minute.

So, via e-mail, an update on where things are with the IPv6 NDP
benchmarking draft, since IETF-86.

The draft is currently at version 00:
http://tools.ietf.org/html/draft-cerveny-bmwg-ipv6-nd-00 (see bottom of
e-mail for more access info).

I got a lot of good feedback at the BMWG meeting in Orlando (IETF-86). 

I also met with Ron Bonica and Varun Santosh after the BMWG meeting and
we discussed 3 primary testing scenarios, as described below:  

1) How many hosts can I have on a network
- Still have connectivity between all endpoints
- We use addresses in ascending order

tester#1new sets up new addresses
tester#2renew is pinging existing addresses
granularity is something between a millisecond and a second.

#1 and #2 should get responses to every packet

2) Given that you have that many hosts, how long does it take for the
neighbor cache get into a reasonable state.
- Lowest timer value and still have connectivity between all endpoints.
- Make sure tester can keep up
- Keep getting smaller intervals

reduce timer on #new
#1new should not always get responses
#2renew should get responses to every packet

3) How do we behave when we’re being scanned. priority to hosts that
have been seen before?
Slow down tester#2 until one gets into refreshing every 6 seconds. If
you have address in stale state, it should get priority over new
request.

increase timer on ixia#renew
tester#renew should always get responses
tester#1new should not always get responses.

The above procedure is a bit of a departure on how I implemented the
tests discussed draft version 00. I'm in the process of confirming this
testing methodology on a commercial testing system.

I'm hoping to update the draft and have something available to discuss
at IETF-88.

Regards,

Bill Cerveny

Filename:        draft-cerveny-bmwg-ipv6-nd
Revision:        00
Title:           Benchmarking Neighbor Discovery Problems
Creation date:   2013-03-11
Group:           Individual Submission
Number of pages: 10
URL:            
http://www.ietf.org/internet-drafts/draft-cerveny-bmwg-ipv6-nd-00.txt
Status:         
http://datatracker.ietf.org/doc/draft-cerveny-bmwg-ipv6-nd
Htmlized:       
http://tools.ietf.org/html/draft-cerveny-bmwg-ipv6-nd-00

Abstract:
   This document is a benchmarking instantiation of RFC 6583:
   "Operational Neighbor Discovery Problems".  It describes a 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.

---

From: William Cerveny <[email-masked]>
Date: Tue, 30 Jul 2013 10:37:48 -0400

Notes and comments I should have added to my status e-mail regarding
draft-cerveny-bmwg-ipv6, but didn't ( :-( ):

Draft version 00 was done based on a testing methodology derived from
using Linux-based IPv6 attacks tools and simple ICMPv6 echo requests
(pings). This methodology was loosely derived from discussion in the
“Neighbor Discovery Problems” RFC (6583) on how the authors were able to
replicate the behavior using attack tools.

The revisions that were discussed after IETF 86 at Orlando are based on
using testing systems, which makes things a bit more complicated for me
to instrument, as I’m more familiar with using Linux based tools than
“traditional” benchmarking testers.  

The new tests need to be implemented, both to confirm that the
methodology is correctly described in the draft and that the tests
appear to be meaningful.

Bill

On Mon, Jul 29, 2013, at 05:58 PM, William Cerveny wrote:
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg