BIND 10 #3207: per-client option values (hook lib extension)

BIND 10 Development do-not-reply at isc.org
Wed Oct 23 11:36:56 UTC 2013


#3207: per-client option values (hook lib extension)
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:
                       Type:         |                Status:  new
  enhancement                        |             Milestone:  New Tasks
                   Priority:         |              Keywords:
  medium                             |             Sensitive:  0
                  Component:  dhcp   |           Sub-Project:  DHCP
               CVSS Scoring:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 This is a follow up to #3186.

 We need to have the capability to define option values per client. The
 primary use case for this is to provision cable modems.

 Cable modems may work in v4 mode or v6 mode. In both cases the modem
 requires TFTP server and bootfile. Boot file is essentially a
 configuration script that the modem downloads and needs to boot properly.

 TFTP server is the same for all modems, but the bootfile may differ for
 each model. Even the same models may get different boot files (e.g.
 running at different speeds due to subscription plans or line quality).

 In v4 mode, cable modem requires boot-file-name option in
 src/lib/dhcp/std_option_defs.h (merged as part of #3199 work). In v6 mode,
 that is sent as a vendor-option. See config-file vendor option in
 src/lib/dhcp/docsis3_option_defs.h (to be merged as part of #3194).

 A note about vendor options. They are handled a bit differently. There is
 one vendor option (OptionVendor class instance) that has a collection of
 sub-options.

 Please keep in mind that:
 1. the server will have some default values for those. The code should
 either try to get existing option and update it (setValue) or remove
 existing instance and insert new option object instead.

 2. It is not clear whether this is required or not, but it may be possible
 that we will require content of the boot-file option to be also stored in
 file field in DHCPv4 packet (see Pkt4::setFile()).

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


More information about the bind10-tickets mailing list