kea/src/bin/dhcp4/dhcp4_hooks.dox

// Copyright (C) 2013-2015  Internet Systems Consortium, Inc. ("ISC")
//
// Permission to use, copy, modify, and/or distribute this software for any
// purpose with or without fee is hereby granted, provided that the above
// copyright notice and this permission notice appear in all copies.
//
// THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
// REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
// AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
// INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
// LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
// OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
// PERFORMANCE OF THIS SOFTWARE.

/**
 @page dhcpv4Hooks The Hooks API for the DHCPv4 Server

 @section dhcpv4HooksIntroduction Introduction
 Kea features an API (the "Hooks" API) that allows user-written code to
 be integrated into Kea and called at specific points in its processing.
 An overview of the API and a tutorial for writing such code can be found in
 the @ref hooksdgDevelopersGuide.  Information for Kea maintainers can be
 found in the @ref hooksComponentDeveloperGuide.

 This manual is more specialized and is aimed at developers of hook
 code for the DHCPv4 server. It describes each hook point, what the callouts
 attached to the hook are able to do, and the arguments passed to the
 callouts.  Each entry in this manual has the following information:

 - Name of the hook point.
 - Arguments for the callout.  As well as the argument name and data type, the
   information includes the direction, which can be one of:
   - @b in - the server passes values to the callout but ignored any data
     returned.
   - @b out - the callout is expected to set this value.
   - <b>in/out</b> - the server passes a value to the callout and uses whatever
     value the callout sends back.  Note that the callout may choose not to
     do any modification, in which case the server will use whatever value
     it sent to the callout.
 - Description of the hook. This explains where in the processing the hook
   is located, the possible actions a callout attached to this hook could take,
   and a description of the data passed to the callouts.
 - Next step status: the action taken by the server when a callout chooses to set
    status to specified value. Actions not listed explicitly are not supported.
   If a callout sets status to unsupported value, this specific value will be
   ignored and treated as if the status was CONTINUE.

@section dhcpv4HooksHookPoints Hooks in the DHCPv4 Server

The following list is ordered by appearance of specific hook points during
packet processing. Hook points that are not specific to packet processing
(e.g. lease expiration) will be added to the end of this list.

 @subsection dhcpv4HooksBuffer4Receive buffer4_receive

 - @b Arguments:
   - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed when the server has received a
   buffer containing a DHCPv4 message, but the message hasn't yet been parsed.
   The sole argument "query4" contains a pointer to the isc::dhcp::Pkt4
   object, which contains the source and destination address of the
   received packet, the interface over which the packet has been received, and
   a raw buffer, stored in the data_ field, containing the DHCPv4 message
   in the wire format. None of the packet fields (op_, hlen_, chaddr_, etc.)
   are set yet. Callouts installed on this hook point can modify the data
    in the received buffer. The server will parse the buffer afterwards.

 - <b>Next step status</b>: If any callout sets the status to SKIP, the server will
   skip the buffer parsing. In this case there is an expectation that
   the callout will parse the options carried in the buffer, create
   @c isc::dhcp::Option objects (or derived) and add them to the "query4"
   object using the @c isc::dhcp::Pkt4::addOption.
   Otherwise the server will find out that some mandatory options are
   missing (e.g. DHCP Message Type) and will drop the message. If you
   want to have the capability to drop a message, it is better to use
   the skip flag in the "pkt4_receive" callout.

 @subsection dhcpv4HooksPkt4Receive pkt4_receive

 - @b Arguments:
   - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed when an incoming DHCPv4
   packet is received and its content has been parsed. The sole
   argument "query4" contains a pointer to an isc::dhcp::Pkt4 object
   that contains all information regarding incoming packet, including
   its source and destination addresses, interface over which it was
   received, a list of all options present within and the relay
   information.  All fields of the Pkt4 object can be modified at this
   time. By the time this hook is reached, the contents of the data_
   field has been already parsed and stored in other fields. Therefore,
   the modification in the data_ field has no effect.

 - <b>Next step status</b>: If any callout sets the status to SKIP, the server will
   drop the packet and start processing the next one.  The reason for the drop
   will be logged if logging is set to the appropriate debug level.

@subsection dhcpv4HooksSubnet4Select subnet4_select

 - @b Arguments:
   - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
   - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in/out</b>
   - name: @b subnet4collection, type: const isc::dhcp::Subnet4Collection *,
     direction: <b>in</b>

 - @b Description: this callout is executed when a subnet is being
   selected for the incoming packet. All parameters and addresses
   will be assigned from that subnet. A callout can select a
   different subnet if it wishes so. The list of all subnets currently
   configured are provided as "subnet4collection". The list itself must
   not be modified.

 - <b>Next step status</b>: If any callout installed on the "subnet4_select" hook
   sets the next step status to SKIP, the server will not select any subnet.
   Packet processing will continue, but will be severely limited.

@subsection dhcpv4HooksLeaseSelect lease4_select

 - @b Arguments:
   - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
   - name: @b fake_allocation, type: bool, direction: <b>in</b>
   - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed after the server engine
   has selected a lease for the client's request, but before the lease has
   been inserted into the database. Any modifications made to the
   "lease4" object will affect the lease's record in the database.
   The callout should sanity check all modifications as the server will
   use that data as is, with no further checking.\n\n
   The server processes lease requests for DHCPDISCOVER and DHCPREQUEST in a
   very similar way. The only major difference is that for DHCPDISCOVER
   the lease is only selected, but not inserted into the database. The callouts
   may distinguish between DHCPDISCOVER and DHCPREQUEST by checking the
   value of the "fake_allocation" flag: a value of true indicates that the
   lease won't be inserted into the database (DHCPDISCOVER case), a value of
   false indicates that it will (DHCPREQUEST case).

 - <b>Next step status</b>: If any callout installed on the "lease4_select" hook
   sets the next step action to SKIP, the server will not assign any lease and
   the callouts become responsible for the lease assignment. If the callouts
   fail to provide a lease, the packet processing will continue, but client
   will not get an address.

@subsection dhcpv4HooksLeaseRenew lease4_renew

 - @b Arguments:
   - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
   - name: @b clientid, type: isc::dhcp::ClientId, direction: <b>in</b>
   - name: @b hwaddr, type: isc::dhcp::HWAddr, direction: <b>in</b>
   - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed when the server engine
   is about to renew a lease, as a result of receiving DHCPREQUEST/Renewing
   packet. The "lease4" argument points to @c isc::dhcp::Lease4 object that
   contains the updated values. Callout can modify those values. Care should
   be taken as the server will attempt to update the lease in the database
   without any additional checks.

 - <b>Next step status</b>: If any callout installed on the "lease4_renew" hook
   sets the next step action to SKIP, the server will not update the lease in the
   database and will continue using the old values instead.

@subsection dhcpv4HooksLeaseRelease lease4_release

 - @b Arguments:
   - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
   - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in</b>

 - @b Description: this callout is executed when the server engine
   is about to release a lease, as a result of receiving DHCPRELEASE packet.
   The "lease4" argument points to @c Lease4 object that contains the lease to
   be released. It doesn't make sense to modify it at this time.

 - <b>Next step status</b>: If any callout installed on the "lease4_release" hook
   sets the next step action to SKIP, the server will not delete the lease.
   It will be kept in the database and will go through the regular expiration/reuse
   process.

@subsection dhcpv4HooksLeaseDecline lease4_decline

 - @b Arguments:
   - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
   - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in</b>

 - @b Description: this callout is executed when the server engine
   is about to decline a lease, as a result of receiving DHCPDECLINE packet.
   The server already sanity checked it (the packet is sane, attempts to decline
   a lease that is valid and belongs to the client that requests its decline).
   The "lease4" argument points to @c Lease4 object that contains the lease to
   be released. Note this lease still contains client identifying information.
   That data is provided for informational purposes and it doesn't make sense to
   modify it at this time. All the information will be removed from the lease
   before it is updated in the database.

 - <b>Next step status</b>: If any callout installed on the "lease4_release" hook
   sets the next step action to DROP, the server will not decline the lease.
   Care should be taken when setting this status.  The lease will be kept in
   the database as it is and the client will incorrectly assume that the server
   marked this lease as unavailable. If the client restarts its configuration,
   it will get the same (not declined) lease as a result.

@subsection dhcpv4HooksPkt4Send pkt4_send

 - @b Arguments:
   - name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed when server's response
   is about to be sent back to the client. The sole argument "response4"
   contains a pointer to an isc::dhcp::Pkt4 object carrying the
   packet, with source and destination addresses set, interface over which
   it will be sent, and a list of all options and relay information.  All fields
   of the @c Pkt4 object can be modified at this time, except @c buffer_out_.
   (This is scratch space used for constructing the packet after all
   pkt4_send callouts are complete, so any changes to that field will
   be overwritten.)

 - <b>Next step action</b>: if any callout installed on the "pkt4_send" hook
   sets the next step action to SKIP, the server will not construct the raw
   buffer. The expectation is that if the callout set skip flag, it is
   responsible for constructing raw form on its own. Otherwise the output
   packet will be sent with zero length.

@subsection dhcpv4HooksBuffer4Send buffer4_send

 - @b Arguments:
   - name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>

 - @b Description: this callout is executed when server's response
   is about to be sent back to the client. The sole argument "response4"
   contains a pointer to an @c isc::dhcp::Pkt4 object that contains the
   packet, with source and destination addresses set, interface over which
   it will be sent, and a list of all options and relay information. The raw
   on-wire form is already prepared in @c buffer_out_ (see
   @c isc::dhcp::Pkt4::getBuffer())
   Callouts should not modify the packet fields or options contents at this
   time, because they were already used to construct on-wire buffer. Their
   modification would have no effect.

 - <b>Next step status</b>: if any callout sets the next step action to SKIP,
   the server will drop this response packet. However, the original request
   packet from a client was processed, so server's state most likely has changed
   (e.g. lease was allocated). Setting this flag merely stops the change
   being communicated to the client.

@subsection dhcpv4HooksLease4Expire lease4_expire

- @b Arguments:
  - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
  - name: @b remove_lease, type: bool, direction: <b>in</b>

- @b Description: this callout is executed for each expired lease when
  the server performs reclamation of the expired leases. During this
  process the server executes "lease4_expire" callout, removes the DNS
  records associated with this lease and finally removes the lease from
  the database or updates its status to "expired-reclaimed". The "lease4"
  argument contains the pointer to the lease being reclaimed. The second
  argument "remove_lease" indicates if the reclaimed leases should be
  removed from the lease database (if true), or their state should be
  set to "expired-reclaimed" in the lease database. This argument
  is only used by the callout if it takes responsibility for the lease
  reclamation, i.e. it sets the "skip" flag to "true". The "remove_lease"
  argument is set to "true" if the "flush-reclaimed-timer-wait-time" is
  set to 0 in the server configuration file.

- <b>Next step status</b>: if the callout sets the next step action to SKIP,
  the server will assume that the callout has fully reclaimed the lease, i.e.
  performed the DNS update and updated the lease in the database. The
  server will not perform any further actions on the lease for which the
  skip flag has been set. It is important to note that if the callout
  sets this flag but fails to reclaim the lease in the database, the
  reclamation routine will repeatedly process this lease in subsequent
  runs. Therefore, the implementors of this callout must make sure that
  skip flag is only set when the lease has been actually reclaimed in the
  database by the callout.

@subsection dhcpv4HooksLease4Recover lease4_recover

- @b Arguments:
  - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in</b>

- @b Description: this callout is executed for each declined lease that
  has expired and is being recovered. The lease has already been stripped
  from any client identifying information when it was put into declined
  state. In principle the callouts can modify the lease in this hook,
  but it makes little sense. There's no useful data in the lease, except
  the IPv4 address (which must not be modified).

- <b>Next step status</b>: if the callout sets the next step action to SKIP,
  the server will skip the lease recovery. In other words, it will keep
  the lease as is. This is not recommended in general, as the declined
  expired leases will remain in the database and their recovery will
  be attempted during the next reclaim cycle.

*/