BIND 10 #1337: DHCP benchmarking - enhanced reply verification

[BIND 10 Development]

#1337: DHCP benchmarking - enhanced reply verification
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  stephen                            |                Status:  new
                       Type:         |             Milestone:  DHCP 2011
  enhancement                        |            Resolution:
                   Priority:  minor  |             Sensitive:  0
                  Component:  dhcp   |           Sub-Project:  DHCP
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by tomek):

 Couple other pass-criteria that we should eventually develop is listed
 below. They are listed here in no particular order. This list is by no
 means complete.

 - no mismatched responses, e.g. server could use wrong transaction-id or
 there may be transactions for real clients - in both cases this means that
 the experiment is not conducted properly

 - required fields are present. For example in DHCPv6, server response must
 include client-id (that is a direct copy of what was sent in SOLICIT or
 REQUEST); server must include its own server-id; server must include IA_NA
 option in its response for each IA_NA option present in request.
 - response is positive. In v6 check that IA_NA response contains actual
 address and not status code that says "sorry". In v4 check that we get ACK
 and not NACK.
 - verify that assigned leases (addresses prefixes) are really from range.
 That would require additional parameter for perfdhcp to specify allowed
 range. This would verify that server really assigns something useful and
 not just garbage.
 - if user specified that he/she wants option X, verify that option X is
 present in server response

 We should eventually look at sending and verifying multiple addresses.

 We should eventually develop support for FQDN and name assignments.

 We may implement verification that for each message exchange a different
 address/prefix was ssigned (search for duplicates). That may not be
 feasible for longer tests.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1337#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development