RE: IPv6 Benchmarking

["Chip Popoviciu \(cpopovic\)" <cpopovic@cisco.com>]

NOTE: Cross posting this discussion of the IPv6 Benchmarking draft
(http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.
txt) to the v6ops and bmwg aliases as this is a topic of interest to
both work groups. Feedback is very welcomed!

------------------------------------------------------------------------
----------------------------------------------

Bill,

I appreciate the fact that you shared with us this particular reference.
It is an excellent example that supports our decision to include in the
IPv6 Benchmarking draft the scenario of evaluating the performance of
processing traffic with extension headers (section 4.3) while filters
for upper layer protocols are applied (section 5.2.2). Such benchmarking
tests could uncover the fact that the DUT either is not processing such
traffic correctly or that its forwarding performance is significantly
impacted under such circumstances. Both these situations would be
critical data points in the process of evaluating networking equipment.

Thank you again for your valuable comments and suggestions below and we
hope you will continue to help us improve this draft.

Best Regards,
Chip

-----Original Message-----
From: Bill Cerveny [mailto:bill@wjcerveny.com] 
Sent: Thursday, August 17, 2006 6:30 PM
To: Chip Popoviciu (cpopovic)
Cc: Ahmed Hamza (ahamza); Gunter Van de Velde (gvandeve); Diego
Dugatkin; Kine, Bill; Al Morton
Subject: RE: IPv6 Benchmarking

Chip,

Regarding the fragmentation header comment, I did a presentation at
Joint-Techs in Summer 2005 about the scenario I encountered. See:
<http://www.internet2.edu/presentations/jtvancouver/20050718-IPv6-Cerven
y.ppt>

After reviewing the presentation I did and the original problem, the
problem really appeared to have been a combination of the next header of
a fragmented UDP packet being listed as a fragmentation header and
perhaps the UDP message being shifted in the packet because of the
fragmentation header.  The router "firewall filter" has been configured
to allow packets with a specific UDP port number. The router failed to
recognize that the packets with fragmentation headers contained UDP
messages.  The router likely never thought to evaluate the UDP port
number because it had already determined the payload wasn't a UDP
message.

In the scenario I encountered, the incorrect filtering behavior resulted
in "good" packets being dropped.  But, of course, the opposite could
happen where "bad" packets don't get dropped.

To my knowledge, this issue still exists with some routers. I'm told
other routers will correctly figure this out, but I've always wanted to
test and confirm this. A network security expert suggested that an
answer might be to filter/drop all packets with extension headers.
 
Finally, there was also one other failure with the scenario regarding
the application.  The application (iperf) should have performed PMTU
discovery and figured out the packets would fragment, which it did not.
An iperf application developer happened to be in the audience and said
he would fix iperf in the next release ;-)

Bill


On Thu, 17 Aug 2006 16:41:26 -0400, "Chip Popoviciu (cpopovic)"
<cpopovic@cisco.com> said:
> 
> Bill,
> 
> Thank you very much for your comments and suggestions and I apologize 
> for the delay in my reply.
> 
> Here is a summary of the actions taken:
> 
> We will follow your advice regarding the filters and IPv4-IPv6 parity 
> We will strengthen the point about packet size differences as you 
> suggested Yes, you are right, we covered the handling of Fragmentation

> Header conceptually and explicitly in section 4.3. When you say in 
> your comment "how the DUT filters fragmented packets" are you 
> referring at filtering based on the Fragmentation EH type?
> 
> I integrated all the editorial suggestions you made.
> 
> Again, many thanks for your feedback!
> 
> Best Regards,
> Chip
> 
> -----Original Message-----
> From: William Cerveny [mailto:wcerveny@eml.cc]
> Sent: Monday, July 24, 2006 4:59 PM
> To: Chip Popoviciu (cpopovic)
> Cc: Ahmed Hamza (ahamza); Gunter Van de Velde (gvandeve); Diego 
> Dugatkin; Kine, Bill
> Subject: Re: IPv6 Benchmarking
> 
> Chip,
> 
> My comments on the IPv6 benchmarking draft.  First I think this is a 
> pretty good document.  That said, I have a some comments for your
> consideration:
> - You detail IPv6 filter recommendations.  I would recommend 
> mentioning that if comparisons between IPv4 and IPv6 performance are 
> desired, an equal number of IPv4 filters should be implemented on the 
> DUT (I could be convinced this isn't important though).
> - You allude to this at the end of section 4.3, but I would more 
> clearly recommend that testers ensure that the total IPv4 and IPv6 
> packet sizes are the same as IPv4 and IPv6 headers will be different
sizes.
> - One case I was looking for was the case I encountered in the wild; 
> where a router didn't allow a specific UDP port number because of the 
> presence of a fragmentation header.  I think you've covered this 
> topic, although it could be interesting to document how the DUT 
> filters fragmented packets.
> 
> Grammatical:
> - Section 1, Introduction:
> s/facilitates the objective/facilitates objective/ %s/Extension 
> Header/extension header/g
> - Section 3: Test Environment Set Up
> s/are the same to the ones/are the same as the ones/ s/test conditions

> or it is/test conditions or if it is/ "The dynamic option is however 
> preferred ..." -- awkward, in my opinion, consider rewording this 
> s/scenarios stem from the assumption that/scenarios assume/ s/end 
> points, the/end points and the/ s/DUT, but is seen/DUT, but are seen/
> - Section 4.1, Frame Formats and Sizes:
> s/40 bytes long header/40-byte header/
> - Section 4.1.2: Frame sizes to be used on SONET:
> "For this reason it is recommended to evaluate the forwarding 
> performance of such interfaces if present or are an option in the DUT"
> -- What does the "or are an option in the DUT" mean?
> - Section 4.2.1: DUT Protocol Addresses:
> s/In order to maintain the consistency with the IPv4/To maintain 
> consistency with IPv4/ -Section 4.2.2: Test Traffic Protocol
Addresses:
> s/sources and destinations/source and destination addresses/ "The 
> source addresses SHOULD belon to one half..." -- This looks like a 
> repeat of same from 4.2.1 %s/Hop-by-Hop/hop-by-hop/g
> - Section 5.2.2: Filter Format:
> s/measure the impact on performance/measure the performance impact/ 
> s/In
> IPv6 routers do not/In IPv6, routers do not/ s/analyzed due to the 
> filters for example/analyzed due to the filters, for example./ s/For 
> this/For these/ ???
> s/in order to evaluate/to evaluate/
> 
> Bill Cerveny
> 
> On Fri, 14 Jul 2006 01:57:18 -0400, "Chip Popoviciu (cpopovic)"
> <cpopovic@cisco.com> said:
> > Dear v6ops,
> >  
> > Thank you for the opportunity offered to bring before you some 
> > challenging topics related to IPv6 benchmarking. We believe strongly

> > in the need for IPv6 benchmarking guidelines to help IPv6 deployment

> > planning and we hope to receive advice based on the operational 
> > expertise of this WG. As promised during the Wednesday session, here

> > is a pointer to the IPv6 benchmarking draft:
> >  
> > http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-
> > 01
> > .t
> > xt
> >  
> > Please send us your comments and suggestions, they are very much 
> > appreciated.
> >  
> > Best Regards,
> > Chip
> --
> William Cerveny
> wcerveny@wjcerveny.com
> 7117 North Lake Orchard Drive
> Gregory, MI  48137
> phone: 734-780-8131