BIND 10 #2488: Create DHCP Test Plan

[BIND 10 Development]

#2488: Create DHCP Test Plan
-------------------------------------+-------------------------------------
            Reporter:  stephen       |                        Owner:  tomek
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:                |                    Milestone:
  documentation                      |  Sprint-DHCP-20130122
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DHCP          |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => tomek


Comment:

 >> The document does not describe the tests in detail - that will be
 covered elsewhere.
 > Where? Does such document exist? We can't run tests if we don't even
 have them listed.
 The tickets that will run the tests include the creation of the
 appropriate documentation.  Once the tests are complete, the test
 documents will be collected together into a single document.

 > I've added several v4 features that were omitted (release a lease,
 recycle/reuse expired lease).
 Thanks.

 > Although it is possible to specify multiple subnets in v6, server does
 not support relayed traffic. We do not have the ability to specify which
 subnet is local if there is more than one defined.
 Following the [wiki:SprintPlanningDHCP20130103 sprint planning meeting] of
 3 January 2013, ticket #2596 has been created for this.


 > Option (both v4 and v6): selection of standard options available.
 > We should specify them exactly (a range 1 to X with X well specified
 will suffice). Which are considered a standard? Everything there is RFC
 published for? That's 78 options for DHCPv6 alone.
 I've changed this to "requested options".  We are checking that the server
 sends the configured options and does not send the unconfigured ones.

 > Performance tool: ability to simulate a number of clients.
 > Need concrete values here. "A number" may mean "more than one" or "a
 million".
 I have set that to 100 clients.  Small enough to check, large enough to be
 reasonably certain that larger numbers are supported.

 > Performance - we need to clarify that while the ultimate goal is to have
 multi-process support, it is not part of this release.
 Done.

 > Start/stop: Added 2 cases.
 Thanks.

 > Logging: Added more details about logging.
 Thanks

 > Pool exhaustion is not supported too well. Currently server will give up
 after it tries to allocate an address after 100 tries. This parameter is
 not configurable yet.
 Does it log this? If so, the test for a debug message is OK.

 >> Check that a reconfiguration removing a particular address pool causes
 clients with leases in that pool to be refused a renewal and to obtain
 another address.
 > Kea doesn't work that way. If the client gets back to us after the lease
 expired and the lease was not assigned to anyone else, we will still give
 it back to the original client.
 So even if we say that we no longer want to allocate that particular
 address, Kea will still allocate it if a client that had previously had
 the address comes back and asks for it?


 >> Check that the server rejects all but DISCOVER and REQUEST messages.
 > Kea also accepts RELEASE. The code also responds with empty packets to
 all other message types. This part of the code is still what we used to
 call a skeleton.
 "all other message types": Does this mean that it will respond to messages
 meant for the client?  The idea of the test is to check that the server
 will not respond to messages that by the protocol are not meant to be sent
 to the server.

 >> Check that the server rejects malformed DISCOVER and REQUEST messages.
 > That will be interesting to watch. :)
 Probably as dull as watching paint dry actually.  I was thinking that we
 could use Scapy for this.


 >> DHCPv6 features: Set up multiple subnets and pools: using different
 client characteristics, check that leases are allocated from the correct
 pool.
 > See my comment above.
 Should be addressed by #2596.

 >> Check that a reconfiguration removing a particular address pool causes
 clients with leases in that pool to be refused a renewal and to obtain
 another address.
 > Not supported yet.
 Same question as before.


 >> Check that the server rejects all but SOLICIT, REQUEST and RENEW
 messages.
 > RELEASE message is also supported.
 OK


 > Is the perfdhcp part of the official delivery? If not, we should
 definitely trim down its validation and focus on server.
 It is a formal part of the software.  Given the refactoring that took
 place this year, a quick check (and this is all that the check is) that it
 is working is justified.

 > Two big things are missing:
 > explicit list of clients we want to test inter-op with
 For now, we will just say ISC DHCP clients.

 > the actual list of tests (currently this document only lists
 requirements, there are no test descriptions).
 Test descriptions will be built up as part of the test tickets.

 > For example of actual test descriptions, please take a look at Section 5
 of doc/dhcp-test-plan.txt from dhcp-val repository.
 Will do.  We should use that as a template as we create the tests for the
 different parts of the server.

 The [DhcpTestPlan test plan] has been modified: the new version is version
 4.

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