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

[William Cerveny <[e-mail]>]

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:
> 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.
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg