dhcp4_hooks.dox 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220
  1. // Copyright (C) 2013 Internet Systems Consortium, Inc. ("ISC")
  2. //
  3. // Permission to use, copy, modify, and/or distribute this software for any
  4. // purpose with or without fee is hereby granted, provided that the above
  5. // copyright notice and this permission notice appear in all copies.
  6. //
  7. // THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  8. // REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
  9. // AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  10. // INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  11. // LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  12. // OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  13. // PERFORMANCE OF THIS SOFTWARE.
  14. /**
  15. @page dhcpv4Hooks The Hooks API for the DHCPv4 Server
  16. @section dhcpv4HooksIntroduction Introduction
  17. Kea features an API (the "Hooks" API) that allows user-written code to
  18. be integrated into Kea and called at specific points in its processing.
  19. An overview of the API and a tutorial for writing such code can be found in
  20. the @ref hooksdgDevelopersGuide. Information for Kea maintainers can be
  21. found in the @ref hooksComponentDeveloperGuide.
  22. This manual is more specialised and is aimed at developers of hook
  23. code for the DHCPv4 server. It describes each hook point, what the callouts
  24. attached to the hook are able to do, and the arguments passed to the
  25. callouts. Each entry in this manual has the following information:
  26. - Name of the hook point.
  27. - Arguments for the callout. As well as the argument name and data type, the
  28. information includes the direction, which can be one of:
  29. - @b in - the server passes values to the callout but ignored any data
  30. returned.
  31. - @b out - the callout is expected to set this value.
  32. - <b>in/out</b> - the server passes a value to the callout and uses whatever
  33. value the callout sends back. Note that the callout may choose not to
  34. do any modification, in which case the server will use whatever value
  35. it sent to the callout.
  36. - Description of the hook. This explains where in the processing the hook
  37. is located, the possible actions a callout attached to this hook could take,
  38. and a description of the data passed to the callouts.
  39. - Skip flag action: the action taken by the server if a callout chooses to set
  40. the "skip" flag.
  41. @section dhcpv4HooksHookPoints Hooks in the DHCPv4 Server
  42. The following list is ordered by appearance of specific hook points during
  43. packet processing. Hook points that are not specific to packet processing
  44. (e.g. lease expiration) will be added to the end of this list.
  45. @subsection dhcpv4HooksBuffer4Receive buffer4_receive
  46. - @b Arguments:
  47. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  48. - @b Description: this callout is executed when an incoming DHCPv4
  49. buffer is received, before its content is parsed. The sole argument
  50. - query4 - contains a pointer to an isc::dhcp::Pkt4 object that
  51. contains raw information regarding incoming packet, including its
  52. source and destination addresses, interface over which it was
  53. received, and a raw buffer stored in data_ field. None of the
  54. packet fields (op_, hlen_, chaddr_, etc.) are set yet. Callouts
  55. installed on this hook point can modify the incoming buffer. The
  56. server will parse the buffer afterwards.
  57. - <b>Skip flag action</b>: If any callout sets the skip flag, the server will
  58. skip the buffer parsing. In such case there is an expectation that
  59. the callout will parse the buffer and create option objects (see
  60. isc::dhcp::Pkt4::addOption()). Otherwise the server will find out
  61. that some mandatory options are missing (e.g. DHCP Message Type) and
  62. will drop the packet. If you want to have the capability to drop
  63. a message, it is better to use skip flag in pkt4_receive callout.
  64. @subsection dhcpv4HooksPkt4Receive pkt4_receive
  65. - @b Arguments:
  66. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  67. - @b Description: this callout is executed when an incoming DHCPv4
  68. packet is received and its content has been parsed. The sole
  69. argument - query4 - contains a pointer to an isc::dhcp::Pkt4 object
  70. that contains all information regarding incoming packet, including
  71. its source and destination addresses, interface over which it was
  72. received, a list of all options present within and relay
  73. information. All fields of the Pkt4 object can be modified at this
  74. time, except data_. (By the time this hook is reached, the contents
  75. of the data_ field has been already parsed and stored in other
  76. fields. Therefore, the modification in the data_ field has no
  77. effect.)
  78. - <b>Skip flag action</b>: If any callout sets the skip flag, the server will
  79. drop the packet and start processing the next one. The reason for the drop
  80. will be logged if logging is set to the appropriate debug level.
  81. @subsection dhcpv4HooksSubnet4Select subnet4_select
  82. - @b Arguments:
  83. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  84. - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in/out</b>
  85. - name: @b subnet4collection, type: const isc::dhcp::Subnet4Collection *, direction: <b>in</b>
  86. - @b Description: this callout is executed when a subnet is being
  87. selected for the incoming packet. All parameters and addresses
  88. will be assigned from that subnet. A callout can select a
  89. different subnet if it wishes so, the list of all subnets currently
  90. configured being provided as 'subnet4collection'. The list itself must
  91. not be modified.
  92. - <b>Skip flag action</b>: If any callout installed on 'subnet4_select'
  93. sets the skip flag, the server will not select any subnet. Packet processing
  94. will continue, but will be severely limited (i.e. only global options
  95. will be assigned).
  96. @subsection dhcpv4HooksLeaseSelect lease4_select
  97. - @b Arguments:
  98. - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
  99. - name: @b fake_allocation, type: bool, direction: <b>in</b>
  100. - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
  101. - @b Description: this callout is executed after the server engine
  102. has selected a lease for client's request but before the lease has
  103. been inserted into the database. Any modifications made to the
  104. isc::dhcp::Lease4 object will be stored in the lease's record in
  105. the database. The callout should sanity check all modifications as
  106. the server will use that data as is with no further checking.\n\n
  107. The server processes lease requests for DISCOVER and REQUEST in a
  108. very similar way. The only major difference is that for DISCOVER
  109. the lease is just selected, but not inserted into the database. It
  110. is possible to distinguish between DISCOVER and REQUEST by checking
  111. value of the fake_allocation flag: a value of true indicates that the
  112. lease won't be inserted into the database (DISCOVER), a value of
  113. false indicates that it will (REQUEST).
  114. - <b>Skip flag action</b>: If any callout installed on 'lease4_select'
  115. sets the skip flag, the server will not assign any lease. Packet
  116. processing will continue, but client will not get an address.
  117. @subsection dhcpv4HooksLeaseRenew lease4_renew
  118. - @b Arguments:
  119. - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
  120. - name: @b clientid, type: isc::dhcp::ClientId, direction: <b>in</b>
  121. - name: @b hwaddr, type: isc::dhcp::HWAddr, direction: <b>in</b>
  122. - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
  123. - @b Description: this callout is executed when the server engine
  124. is about to renew a lease, as a result of receiving REQUEST/Renewing
  125. packet. The lease4 argument points to Lease4 object that contains
  126. the updated values. Callout can modify those values. Care should be taken
  127. as the server will attempt to update the lease in the database without
  128. any additional checks.
  129. - <b>Skip flag action</b>: If any callout installed on 'lease4_renew'
  130. sets the skip flag, the server will not update the lease and will
  131. use old values instead.
  132. @subsection dhcpv4HooksLeaseRelease lease4_release
  133. - @b Arguments:
  134. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
  135. - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in</b>
  136. - @b Description: this callout is executed when the server engine
  137. is about to release a lease, as a result of receiving RELEASE packet.
  138. The lease4 argument points to Lease4 object that contains the lease to
  139. be released. It doesn't make sense to modify it at this time.
  140. - <b>Skip flag action</b>: If any callout installed on 'lease4_release'
  141. sets the skip flag, the server will not delete the lease. It will be
  142. kept in the database and will go through the regular expiration/reuse
  143. process.
  144. @subsection dhcpv4HooksPkt4Send pkt4_send
  145. - @b Arguments:
  146. - name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  147. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
  148. - @b Description: this callout is executed when server's response
  149. is about to be sent back to the client. The argument response4
  150. contains a pointer to an isc::dhcp::Pkt4 object that contains the
  151. packet, with source and destination addresses set, interface over which
  152. it will be sent, and a list of all options and relay information. All fields
  153. of the Pkt4 object can be modified at this time, except buffer_out_.
  154. (This is scratch space used for constructing the packet after all
  155. pkt4_send callouts are complete, so any changes to that field will
  156. be overwritten.)\n\n
  157. The argument query4 contains a pointer to the corresponding query packet
  158. (allowing to perform correlation between response and query). This object
  159. cannot be modified.
  160. - <b>Skip flag action</b>: if any callout sets the skip flag, the server
  161. will not construct raw buffer. The expectation is that if the callout
  162. set skip flag, it is responsible for constructing raw form on its own.
  163. Otherwise the output packet will be sent with zero length.
  164. @subsection dhcpv4HooksBuffer4Send buffer4_send
  165. - @b Arguments:
  166. - name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  167. - @b Description: this callout is executed when server's response
  168. is about to be sent back to the client. The sole argument - response4 -
  169. contains a pointer to an isc::dhcp::Pkt4 object that contains the
  170. packet, with source and destination addresses set, interface over which
  171. it will be sent, and a list of all options and relay information. The raw
  172. on-wire form is already prepared in buffer_out_ (see isc::dhcp::Pkt4::getBuffer())
  173. It doesn't make any sense to modify packet fields or options content
  174. at this time, because they were already used to construct on-wire buffer.
  175. - <b>Skip flag action</b>: if any callout sets the skip flag, the server
  176. will drop this response packet. However, the original request packet
  177. from a client was processed, so server's state was most likely changed
  178. (e.g. lease was allocated). Setting this flag merely stops the change
  179. being communicated to the client.
  180. */