BIND 10 #2681: DHCPv6 server crashes on Solicit and Request when pool has been exhausted.

[BIND 10 Development]

#2681: DHCPv6 server crashes  on Solicit and Request when pool has been exhausted.
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  marcin                             |                Status:  new
                       Type:         |             Milestone:  Sprint-
  defect                             |  DHCP-20130214
                   Priority:  high   |              Keywords:
                  Component:  dhcp6  |             Sensitive:  0
               CVSS Scoring:         |           Sub-Project:  DHCP
            Defect Severity:  High   |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 I perform the manual test v6.general.log.exhausted-pool described in the
 dhcp-val repo: tests/common/.

 This test limits the address pool to 5 addresses while the number of
 simulated clients is 10. The expected output from this test is that 5
 leases are assigned and that the server logs debug messages for 5
 remaining requests that the pool is exhausted. The debug message is not
 logged by the server.

 In the course of debugging it turned out that the server crashes and gets
 restarted by the BIND10 Boss when new Solicit or Request comes in. This
 happens after making attempt to allocate a new lease 100 times. When it
 fails the following call in ''src/bin/dhcp6/dhcp6_srv.cc (line 630)''
 throws the ''AllocFailed'' exception:
 {{{
 Lease6Ptr lease = alloc_engine_->allocateAddress6(subnet, duid,
 ia->getIAID(), hint, fake_allocation);
 }}}

 This exception propagates to the main function causing process to abort.

 This is undesired behaviour because it (to my understanding) violates the
 RFC 3315 (par 17.2.2.) which says that !''If the server will not assign
 any addresses to any IAs in a subsequent Request from the client, the
 server MUST send an Advertise message to the client that includes only a
 Status Code option with code NoAddrsAvail...!''. Obviously the client does
 not get anything.

 Another obvious implication is that the server is vulnerable to DoS
 attacks and its performance is affected by the frequent need to restart
 the process.

 Thus, setting the Priority and Severity to High.

 The log file has been attached.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2681>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development