Changes between Version 2 and Version 3 of DhcpDigToolDiscussion


Ignore:
Timestamp:
Oct 30, 2015, 12:21:23 PM (2 years ago)
Author:
stephen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DhcpDigToolDiscussion

    v2 v3  
    88
    99== Features of "dig" ==
    10 * directable ( @server ) - will default to using resolv.conf, but can be used to target individual servers.
    11   * in the DHCP world the default could be sending to the broadcast address but individual IPs can be targeted.
    12   * if a client configuration is found then that could be used to set the default values for a bunch of options.
    13 * options to control retry/retransmit intervals and number of attempts
    14   * similar concepts exist in the DHCP world, although it seems reasonable here to report on timeouts and to possibly default to no retries.
    15   * alternatively, ther default should be what most DHCP clients do or what the protocol advises on retries.
    16 * options to control what output is produced at a fairly granular level
    17   * the concept would be pretty much the same in the DHCP world, although thought needs to be given to what the logical chunks should be
    18 * options for different display methods for some specific data
    19   *  probably also appropriate
    20   * nice to have, but not needed for the first implementation.
    21 * options to control the header flags and EDNS option settings
    22   * in the DHCP world this gets a lot more complex, as the messages from the client are more commonly richer in sent data. (This is a topic all by itself, specific to DHCP...)
    23 * IPv4 and IPv6 support
    24   * in the DNS world this is a relatively trivial distinction but in the DHCP world the two protocols are significantly different.
    25   * it may be better to have two completely separate programs than to try to combine both protocols into one program. (This idea does have support.)
    26 * does not directly affect the system it is run from.
    27   * this is the default for the DNS world, but in the DHCP world it is worth mentioning explicitly.  has no built-in capability to change any files or interface settings.  Has no built-in capability to invoke scripts with received data.
    28   * just as in the DNS world querying a server can alter cache contents, in the DHCP world conversing with a server can alter the server's lease database.  Care should be taken with the defaults to prevent accidental changes to the lease database that would be detrimental to the current system should it be a DHCP client (including changes to the DNS name associated with the lease).
    29     * we may need two potential operational options here.
    30       * if we're running this tool against a test server, then we may actually *want* the server to update its leases.
    31       * if we're running against a live server, then it becomes a much harder thing to prevent impact.  We could add an option that the tool should attempt to release any leases it is granted at the end of the test run - but even being given leases temporarily is going to change the state of the server because we'll have leases that have the concept of having been granted before and which therefore would be lower preference for handing out to a new client and so on.
    32 * tracks stats for the data sent/received (sizes, counts of various sections, timing, etc).
    33   * the concept stays the same, but the details of what ought to be tracked will change
    34 * produced output is stable from version to version.
    35   * this makes the tool more useful for automation, this implies that extra care should go into crafting the first version to produce display modes that will hold up over the long haul.
    36 * compiled program, leveraging existing code while also being relatively
    37   minimal in the way of runtime dependencies
    38   * I don't think that our existing DHCP codebase is architected to be well suited for this kind of code reuse
    39   * an implementation using a scripting language could be easier to write but likely at the expense of adding runtime requirements in the form of referenced external modules/libraries/etc that will complicate the install process
    40 * able to specify multiple queries and/or servers in a single command-line invocation, with some options being able to behave either globally or locally depending on where in the sequence they are used
    41   * I think it less likely in the DHCP world for it to be common to explicitly specify multiple servers to "query" with different options, all in one single invocation
    42   * given that "querying" a broadcast address is expected to be a normal behavior with multiple received responses something that already needs to be handled, it seems that much of the "hard work" for handling this is already required functionality
    43     * we already have a bulk-test tool - we don't need to reinvent it here.  But it would be good to be able to emulate a PXE client...
     10* Directable ( @server ) - will default to using resolv.conf, but can be used to target individual servers.
     11  * In the DHCP world the default could be sending to the broadcast address but individual IPs can be targeted.
     12  * If a client configuration is found then that could be used to set the default values for a bunch of options.
     13* Options to control retry/retransmit intervals and number of attempts.
     14  * Similar concepts exist in the DHCP world, although it seems reasonable here to report on timeouts and to possibly default to no retries.
     15  * Alternatively, ther default should be what most DHCP clients do or what the protocol advises on retries.
     16* Options to control what output is produced at a fairly granular level.
     17  * The concept would be pretty much the same in the DHCP world, although thought needs to be given to what the logical chunks should be.
     18* Options for different display methods for some specific data.
     19  * Probably also appropriate,
     20  * Nice to have, but not needed for the first implementation.
     21* Options to control the header flags and EDNS option settings.
     22  * In the DHCP world this gets a lot more complex, as the messages from the client are more commonly richer in sent data. (This is a topic all by itself, specific to DHCP...)
     23* IPv4 and IPv6 support.
     24  * In the DNS world this is a relatively trivial distinction but in the DHCP world the two protocols are significantly different.
     25  * It may be better to have two completely separate programs than to try to combine both protocols into one program. (This idea does have support.)
     26* Does not directly affect the system it is run from.
     27  * This is the default for the DNS world, but in the DHCP world it is worth mentioning explicitly.  has no built-in capability to change any files or interface settings.  Has no built-in capability to invoke scripts with received data.
     28  * Just as in the DNS world querying a server can alter cache contents, in the DHCP world conversing with a server can alter the server's lease database.  Care should be taken with the defaults to prevent accidental changes to the lease database that would be detrimental to the current system should it be a DHCP client (including changes to the DNS name associated with the lease).
     29    * We may need two potential operational options here.
     30      * If we're running this tool against a test server, then we may actually *want* the server to update its leases.
     31      * If we're running against a live server, then it becomes a much harder thing to prevent impact.  We could add an option that the tool should attempt to release any leases it is granted at the end of the test run - but even being given leases temporarily is going to change the state of the server because we'll have leases that have the concept of having been granted before and which therefore would be lower preference for handing out to a new client and so on.
     32* Tracks statistics for the data sent/received (sizes, counts of various sections, timing, etc).
     33  * The concept stays the same, but the details of what ought to be tracked will change.
     34* Produced output is stable from version to version.
     35  * This makes the tool more useful for automation, this implies that extra care should go into crafting the first version to produce display modes that will hold up over the long haul.
     36* Compiled program, leveraging existing code while also being relatively minimal in the way of runtime dependencies.
     37  * I don't think that our existing DHCP codebase is architected to be well suited for this kind of code reuse.
     38  * In implementation using a scripting language could be easier to write but likely at the expense of adding runtime requirements in the form of referenced external modules/libraries/etc that will complicate the install process.
     39* Able to specify multiple queries and/or servers in a single command-line invocation, with some options being able to behave either globally or locally depending on where in the sequence they are used.
     40  * It is probably less likely in the DHCP world for it to be common to explicitly specify multiple servers to "query" with different options, all in one single invocation.
     41  * Given that "querying" a broadcast address is expected to be a normal behavior with multiple received responses something that already needs to be handled, it seems that much of the "hard work" for handling this is already required functionality.
     42    * We already have a bulk-test tool - we don't need to reinvent it here.  But it would be good to be able to emulate a PXE client...
    4443
    4544== "dig" Use Cases ==
    46 * manual probing of suspected issues
    47   * in my mind this implies a richness of being able to quickly and easily tweak the command options to change the outbound packet to explore the behavior boundaries of whatever is being investigated.
    48   * this ought not be at the expense of being able to concisely refer to user-created persistent behavioral "bundles".
    49 * automated data collection program embedded in other systems so they don't have to grow the ability to handle DNS natively
    50   * in the DHCP world this type of use /might/ be mostly limited to monitoring systems, but I'm sure I can think of other (ab)uses.
    51   * an extension of this is the potential for use in automated tests of DHCP client/server behavior.
    52 * while it's possible to manually validate DNSSEC signed responses with "dig", it's not recommended, but "delv" is designed for that
    53   * as such, maybe a more useful tool would be a "delv" equivalent than a "dig" equivalent, due to the implication of a "session" in which multiple "queries" are made and answers received before a final result is determined.
     45* Manual probing of suspected issues.
     46  * In my mind this implies a richness of being able to quickly and easily tweak the command options to change the outbound packet to explore the behavior boundaries of whatever is being investigated.
     47  * This ought not be at the expense of being able to concisely refer to user-created persistent behavioral "bundles".
     48* Automated data collection program embedded in other systems so they don't have to grow the ability to handle DNS natively
     49  * In the DHCP world this type of use /might/ be mostly limited to monitoring systems, but I'm sure I can think of other (ab)uses.
     50  * An extension of this is the potential for use in automated tests of DHCP client/server behavior.
     51* While it's possible to manually validate DNSSEC signed responses with "dig", it's not recommended, but "delv" is designed for that.
     52  * As such, maybe a more useful tool would be a "delv" equivalent than a "dig" equivalent, due to the implication of a "session" in which multiple "queries" are made and answers received before a final result is determined.
    5453  * Session mode v. packet mode?  Session mode handles the entire dialogue necessary to obtain a lease (or not, if this fails).  There are probably multiple 'session' types too - to emulate the different things that a client might 'do' in relation to a lease.
    55   * or maybe we call it a "dig"-like tool while really building a "delv"-like tool, since "dig" is more well-known than "delv".
     54  * Or maybe we call it a "dig"-like tool while really building a "delv"-like tool, since "dig" is more well-known than "delv".
    5655
    5756== DHCP Specific Considerations ==
    58 * it is common enough for multiple DHCP servers to respond to a request, especially a broadcast request, that a DHCP "dig" tool MUST be prepared to handle this well
    59   * capable of not simply moving on or terminating with the first received response (but the order of received responses MUST be noted and preserved)
    60   * capable of displaying equivalent information from all received responses in a manner that makes it easy to distinguish the groupings
    61   * whatever default is chosen, options MUST exist to choose handling of multiple responses
    62 * in the DHCP world for troubleshooting you sometimes need to listen first ather than speak first
    63 * is there value in putting effort into making shortcut options for easy use  with "derivative protocols" such as [https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol WPAD] or [https://en.wikipedia.org/wiki/Boot_Service_Discovery_Protocol BSDP]?
    64   * This is a good idea - a shortcut to standardises client settings.
     57* It is common enough for multiple DHCP servers to respond to a request, especially a broadcast request, that a DHCP "dig" tool MUST be prepared to handle this well.
     58  * Capable of not simply moving on or terminating with the first received response (but the order of received responses MUST be noted and preserved).
     59  * Capable of displaying equivalent information from all received responses in a manner that makes it easy to distinguish the groupings.
     60  * Whatever default is chosen, options MUST exist to choose handling of multiple responses.
     61* In the DHCP world for troubleshooting you sometimes need to listen first rather than speak first.
     62* Is there value in putting effort into making shortcut options for easy use with "derivative protocols" such as [https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol WPAD] or [https://en.wikipedia.org/wiki/Boot_Service_Discovery_Protocol BSDP]?
     63  * This is a good idea - a shortcut to standardizes client settings.
    6564  * How about having the tool have a concept of client 'profiles' that you can either set up manually (which options it requests, what it will/won't accept, whether it has a prior expired lease etc.).  From there you can either ask it to operate in session or in packet mode. Session mode I suppose, also has retry timeouts? And then on top of this, we provide some quick-setup profiles, such as PXE client and various Apple clients (build these up, perhaps as folks contribute them to us or we see them during troubleshooting). In fact.. we could have an online repository of client profiles that we maintain ourselves with a few key useful ones to start with, but accept updates and suggestions and alternatives from our user base into?
    66 * sometimes the in-packet representation of a value is just as significant as  the logical value (e.g. a value encoded as a single instance of an option vs. being encoded as two concatenated instances of the option).  Sometimes the order of options within the packet is significant.  for maximum utility this kind of behavior needs to be easily controllable
    67 * it is common for option data to use values outside of the normal printable ASCII range, so the tool needs to have mechanisms for unambiguous, yet easy to use, encoding of these values when necessary
    68 * it is much more common to need to emulate a "broken" client behavior when troubleshooting DHCP than it is when troubleshooting DNS, enough so that the tool should be capable of producing a wide variety of known broken behaviors (e.g. incorrect option value encodings) while still making it easy for the user to produce proper packets by default
     65* Sometimes the in-packet representation of a value is just as significant as  the logical value (e.g. a value encoded as a single instance of an option vs. being encoded as two concatenated instances of the option).  Sometimes the order of options within the packet is significant.  for maximum utility this kind of behavior needs to be easily controllable.
     66* It is common for option data to use values outside of the normal printable ASCII range, so the tool needs to have mechanisms for unambiguous, yet easy to use, encoding of these values when necessary.
     67* It is much more common to need to emulate a "broken" client behavior when troubleshooting DHCP than it is when troubleshooting DNS, enough so that the tool should be capable of producing a wide variety of known broken behaviors (e.g. incorrect option value encodings) while still making it easy for the user to produce proper packets by default.
    6968  * Part of the 'profile' concept suggested earlier?  Plus of course the ability to override non-broken profiles manually to emulate a new brokenness, not encountered before...
    70 * in DHCP there are a much larger set of factors that determine the answer you will receive from a given server, especially the client identifier (and MAC address), apparent subnet of origin of the request, and relay agent options.
    71 * in some cases it may be impossible to both emulate a specific request 100% /and/ directly observe the response (if any).  it may be worthwhile to build the tool in such a way that it can be fed data from indirect sources (e.g. getting a feed from a tcpdump) in order to still perform the display and/or analysis portions of the tool's functionality
    72 * it may be useful to build a programmable state machine into the tool (i.e. paralleling "delv" more than "dig"), but I think it will also be useful to have the tool be able to
    73 * one alternative to building in a programmable state machine would be building the tool with the idea of being able to chain invocations together where the output of one invocation is fed into a second invocation as input (along with command-line options) to produce the "final" result
    74   * how this should interact with cases where multiple responses are received requires additional thought
    75   * there is a question on if we should build a mechanism whereby the second invocation can have conditional behavior based on either input data, random factors, etc.
     69* In DHCP there are a much larger set of factors that determine the answer you will receive from a given server, especially the client identifier (and MAC address), apparent subnet of origin of the request, and relay agent options.
     70* In some cases it may be impossible to both emulate a specific request 100% /and/ directly observe the response (if any).  it may be worthwhile to build the tool in such a way that it can be fed data from indirect sources (e.g. getting a feed from a tcpdump) in order to still perform the display and/or analysis portions of the tool's functionality.
     71* It may be useful to build a programmable state machine into the tool (i.e. paralleling "delv" more than "dig"), but I think it will also be useful to have the tool be able to send a sequence of packets where the second and subsequent packet takes account of the responses to previous packets.
     72* One alternative to building in a programmable state machine would be building the tool with the idea of being able to chain invocations together where the output of one invocation is fed into a second invocation as input (along with command-line options) to produce the "final" result.
     73  * How this should interact with cases where multiple responses are received requires additional thought.
     74  * There is a question on if we should build a mechanism whereby the second invocation can have conditional behavior based on either input data, random factors, etc.
    7675    * This ties in with my 'session mode' versus 'packet mode' idea, although being able to step through session mode with choices could be a third way.  Maybe.  I'd put that on the 'nice to have but not essential' list too.
    77 * note that some "queries" don't expect any output, e.g. RELEASE but the tool ought to be prepared to show them anyway
    78 * it may be useful for some people to be able to supply an external "options definition file" that is used to allow complex vendor encapsulated options to be specified more easily, without us having to find and build-in support for all of them (or to select between ones that are incompatible but overlap in their identifiers)
     76* Note that some "queries" don't expect any output, e.g. RELEASE but the tool ought to be prepared to show them anyway.
     77* It may be useful for some people to be able to supply an external "options definition file" that is used to allow complex vendor encapsulated options to be specified more easily, without us having to find and build-in support for all of them (or to select between ones that are incompatible but overlap in their identifiers).