{{Header}}
{{#seo:
|description=Design Documentation {{project_name_long}} DHCP Server
}}
{{intro|
Design Documentation {{project_name_long}} DHCP Server
}}
= If {{project_name_short}} had a DHCP server running on eth1 on {{project_name_gateway_long}}... =

Advantages:

* Setting up [[Multiple Whonix-Workstation|Multiple {{project_name_workstation_long}}]] would be simpler.
* In particular, you could trivially clone an existing workstation instance (including the unmodified standard template), use it, and delete it... or even run it with all "disk writes" done only in RAM.
* Using [[Other Operating Systems]] would be simpler.

Disadvantages:

* Higher attack surface due to DHCP?
** ''Anything'' obviously creates attack surface. DHCP itself is a simple protocol, but that doesn't mean it has zero risk.
** ISC dhcpd is the reference implementation:
*** It's probably more complicated than you'd like to see, because it provides so many facilities for conditional responses.
*** On the other hand, it's mature, heavily used in exposed places, and much of its attack surface is probably only reachable from the server side.
** There are other implementations.

Needs research:

* Does DHCP have some feature which a compromised {{project_name_workstation_short}} could abuse? Does DHCP have a feature such as "tell me the IP of your upstream router"?
** Answer:
*** The basic idea behind DHCP is that the client tells the server some things it knows about itself and asks the server to tell it more.
**** The "things" are attribute-value pairs that use well-known numeric attribute identifiers, some of which are reserved for local customization.
**** The client usually asks for specific attributes. The server is free to leave some out or add unrequested ones.
*** There is no standard attribute for "IP of your upstream router" because that's not useful. It would be possible to add it, but that would require ''server'' support.
*** DHCP servers ''can'' be configured to ''forward'' requests to upstream servers, which may be routers. That is a server-side configuration option, and a client can't ask the server to do it.
*** Any reasonable DHCP server can be configured to give clients only a fixed set of attributes chosen by the server.
*** DHCP server code, in general, gives the admin a huge amount of control over the information it will provide to clients. You could certainly configure ISC dhcpd to give only X or Y attributes.
** TODO: Read this stuff...
*** https://www.ietf.org/rfc/rfc2131.txt
*** https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

= If {{project_name_short}} had a DHCP client running on eth0 on {{project_name_workstation_short}}... =

Disadvantages:

* Needs research: Some users with little knowledge only download {{project_name_workstation_short}} and set its network settings to DHCP. ([[Special:AWCforum/st/id240/#post_1143|example]]) Accepting any IP from DHCP would allow them to non-anonymously use {{project_name_workstation_short}} easily. We would have to add some protection to avoid accepting an IP from VirtualBox NAT, if that is possible.
* Needs research: Configuration of [[Onion Services]] could become more difficult because these need a fixed internal IP?
** No. DHCP typically assigns only addresses from a configured range within a subnet. If you want a host with a fixed address, you give it an address outside the dynamic range. You can also configure a DHCP server to always assign a given IP address to a given MAC address or other host identifier, although that's not necessarily something you'd want to rely on for a hidden service.

[[Category:Design]]

{{Footer}}