dhcp4_hooks.dox 7.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138
  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. BIND10 features an API (the "Hooks" API) that allows user-written code to
  18. be integrated into BIND 10 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 BIND 10 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 dhcpv4HooksPkt4Receive pkt4_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. packet is received and its content is parsed. The sole argument -
  50. query4 - contains a pointer to an isc::dhcp::Pkt4 object that contains
  51. all information regarding incoming packet, including its source and
  52. destination addresses, interface over which it was received, a list
  53. of all options present within and relay information. All fields of
  54. the Pkt4 object can be modified at this time, except data_. (data_
  55. contains the incoming packet as raw buffer. By the time this hook is
  56. reached, that information has already parsed and is available though
  57. other fields in the Pkt4 object. For this reason, it doesn't make
  58. sense to modify it.)
  59. - <b>Skip flag action</b>: If any callout sets the skip flag, the server will
  60. drop the packet and start processing the next one. The reason for the drop
  61. will be logged if logging is set to the appropriate debug level.
  62. @subsection dhcpv4HooksSubnet4Select subnet4_select
  63. - @b Arguments:
  64. - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  65. - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in/out</b>
  66. - name: @b subnet4collection, type: const isc::dhcp::Subnet4Collection *, direction: <b>in</b>
  67. - @b Description: this callout is executed when a subnet is being
  68. selected for the incoming packet. All parameters and addresses
  69. will be assigned from that subnet. A callout can select a
  70. different subnet if it wishes so, the list of all subnets currently
  71. configured being provided as 'subnet4collection'. The list itself must
  72. not be modified.
  73. - <b>Skip flag action</b>: If any callout installed on 'subnet4_select'
  74. sets the skip flag, the server will not select any subnet. Packet processing
  75. will continue, but will be severely limited (i.e. only global options
  76. will be assigned).
  77. @subsection dhcpv4HooksLeaseSelect lease4_select
  78. - @b Arguments:
  79. - name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
  80. - name: @b fake_allocation, type: bool, direction: <b>in</b>
  81. - name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
  82. - @b Description: this callout is executed after the server engine
  83. has selected a lease for client's request but before the lease
  84. has been inserted into the database. Any modifications made to the
  85. isc::dhcp::Lease4 object will be stored in the lease's record in the
  86. database. The callout should make sure that any modifications are
  87. sanity checked as the server will use that data as is with no further
  88. checking.\n\n The server processes lease requests for DISCOVER and
  89. REQUEST in a very similar way. The only major difference is that
  90. for DISCOVER the lease is just selected, but not inserted into
  91. the database. It is possible to distinguish between DISCOVER and
  92. REQUEST by checking value of the fake_allocation flag: a value of true
  93. means that the lease won't be inserted into the database (DISCOVER),
  94. a value of false means that it will (REQUEST).
  95. - <b>Skip flag action</b>: If any callout installed on 'lease4_select'
  96. sets the skip flag, the server will not assign any lease. Packet
  97. processing will continue, but client will not get an address.
  98. @subsection dhcpv4HooksPkt4Send pkt4_send
  99. - @b Arguments:
  100. - name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
  101. - @b Description: this callout is executed when server's response
  102. is about to be send back to the client. The sole argument - response4 -
  103. contains a pointer to an isc::dhcp::Pkt4 object that contains the
  104. packet, with set source and destination addresses, interface over which
  105. it will be send, list of all options and relay information. All fields
  106. of the Pkt4 object can be modified at this time, except bufferOut_.
  107. (This is scratch space used for constructing the packet after all
  108. pkt4_send callouts are complete, so any changes to that field will
  109. be overwritten.)
  110. - <b>Skip flag action</b>: if any callout sets the skip flag, the server
  111. will drop this response packet. However, the original request packet
  112. from a client was processed, so server's state was most likely changed
  113. (e.g. lease was allocated). Setting this flag merely stops the change
  114. being communicated to the client.
  115. */