Basic-static

DHCP Reservation

The DHCP Reservation menu contains settings to configure DHCP Reservations, Static ARP bindings and enable/disable IP Traffic monitoring for clients with the above mappings.

DHCP Reservation

Since release 2020.8, what was called "Static DHCP" is now more accurately named "DHCP Reservation". Please see "Inconsistent Terminology" in this section for further clarification and differentiation of terminology.

DHCP Reservation is a simple way to ensure that Tomato64 offers certain client devices the same IP address each time they request a lease. Simply enter the MAC address for a client device (found in Device List), into the MAC Address field, enter the IP Address (and optionally, Hostname) you want to assign into the appropriate fields and click Save.

The Bound to button is optional. Only check the Bound to button if you want to enable Static ARP binding. Tomato64 will then offer that address (and hostname) to the MAC address you specified every time it offers a lease. In general, the client device will always get that IP address whenever it requests one. That last part, “whenever it requests one” is the key part here. See the explanation of the term Hostname later on this page.

Configuring DHCP Reservations

When assigning DHCP Reservations, you should use an IP address in Tomato64's main subnet, but outside the normal IP Range (in the Network menu). This avoids potential address conflicts. For example, if your DHCP server is set to assign addresses in the range: 10.0.1.1 - 10.0.1.100, then choosing DHCP Reservation assignments of 10.0.1.101 - 10.0.1.254 might work well.

If you want to assign multiple hostnames to the same IP address (for example, you want the the server 10.0.1.3 to be known as both “galaxy” and “mail”, you put them in the Hostname field, separated by a space. A space isn't a valid DHCP Hostname character, so you must use a hyphen for a single, multi-word Hostname like “My-PC”. If a client has multiple network interfaces (such as Ethernet and WiFi) with different MAC addresses, it might not assign the hostname properly to both devices. You could get a “Duplicate name” error.

If Tomato64 can't find a match for the device's Hostname (first priority) or MAC address (second priority), the server may fall back to either Dynamic or Automatic allocation. For an explanation of the term Hostname, see later on this page.

Security Limitations

As mentioned earlier, DHCP Reservation offers the mapped IP address (and Hostname) to the MAC address you specified every time it offers a lease. DHCP Reservation does not prevent a different client from being configured with the same IP address. This is because DHCP Reservation only offers a static mapping to client devices which request a lease. If another device were self-configured with a (true) static IP, or if the router/DHCP were disabled, the other device could take that IP address. Similarly, if the first client for which DHCP Reservation were then self-configured with a static IP, it could claim a different IP address than the one in Tomato64's DHCP Reservation mapping.

Even if everything else were working properly, only DHCP lease offers are made static. The router's IP→MAC neighbour cache (ARP cache) is still filled in dynamically using ARP broadcasts. That means that unless we add something else, Tomato64 is relying on client devices to be honest about their MAC addresses. The data source for ARP mappings is assumed to be “honest” and accurate, even though that source is often the network clients themselves. Under such conditions, there's not much to stop unauthorized or malicious clients from pretending to be a different MAC address (ARP spoofing). ARP spoofing could even include spoofing the router or gateway's MAC address. All this could have serious consequences. This is where Static ARP becomes useful.

Inconsistent Terminology

Sometimes, confusion occurs because of imprecise or inconsistent terminology. First, DHCP Reservation is sometimes confused with Static IP. They are not the same. DHCP Reservation involves configuring an assigned IP address for the client device within (Tomato64's) DHCP server. This causes the client to receive a specific address when it requests a DHCP lease. Static IP is the configuration of an IP address manually from within the client device itself.

Second, the term "Static DHCP" is given different names by different vendors/projects.

Some terminology variations include:

• "static DHCP assignment" in DD-WRT,

• "fixed-address" in the Linux dhcp daemon (dhcpd) documentation

• "Address Reservation" by Netgear

• Either// "DHCP Reservation" or "Static DHCP"// by Cisco/Linksys

• "IP address reservation" or "MAC/IP address binding" by other router vendors.

To reduce confusion, you are advised to be precise with terminology relating to this subject.

---

Tomato64 can assign one IP/Hostname to 2 MAC addresses if the following steps here are taken:

https://www.linksysinfo.org/index.php?threads/official-freshtomato-org-website.75333/post-322397

Static ARP

ARP is a protocol that clients use to obtain the MAC address of another client, given its IP address. ARP is used so that clients can figure out how to address network packets to another client. If a network client needs to communicate with another client, it broadcasts an ARP request across the network asking for the other client's MAC address. The "other client" should just reply honestly. With Static DHCP, only DHCP lease offers were made static. The router's IP - MAC neighbour cache (aka ARP cache) is still filled in dynamically using ARP. This means that unless we add something else, Tomato64 is relying on client devices to be honest when reporting their own MAC addresses. This has several repercussions.

Reduces Broadcast Traffic

Since ARP requests are broadcast across the network, they add to network traffic. Having Tomato64 as a centralized source of ARP resolution can help to limit those ARP broadcasts, reducing network traffic.

Reduces ARP spoofing

By default, ARP gets its mapping information from other clients. It works in a peer-to-peer fashion. ARP mappings are assumed to be "honest" and accurate, even though the source of that data is often the clients themselves. Given this, there's little to stop unathorized or malicious clients from pretending to be a different MAC address (ARP spoofing). This reduces the reliability/security of Static DHCP mappings. What good is a mapping if a client can spoof another's MAC address? ARP spoofing could even include spoofing the router or gateway's MAC address. That could have dangerous consequences.

Here again, Static ARP binding can help. When enabled, Static ARP binding will ignore ARP spoofing attempts. Tomato64 will ignore all (broadcast) ARP replies of devices listed in the table. Instead, Tomato64 will check the Static DHCP tables to find the MAC address that belongs to a certain IP address. We assume this information is more accurate, since the Static DHCP table is maintained by the network administrator.

MAC Address: Here, enter the MAC Address you wish to bind.

Bound To: Checking this enables Static ARP binding for the IP - MAC address mapping. It adds a Static ARP entry for it in Tomato64's ARP table based on data found in the Static DHCP table. (Default: Disabled).

IP Address: Here, enter the address you want bound to the MAC address entered. This is optional. If you leave the IP address empty, it will only link a Hostname to a MAC address, allowing for normal DHCP operations. This "lack of IP" might be helpful for devices that don't automatically have a Hostname assigned, but for which you still prefer a dynamic IP allocation.

IP Traffic: Checking this enables IP Traffic Monitoring for the mapped MAC Address/IP address/Hostname combination. (Default: Disabled).

Hostname: Here, enter the (optional) DHCP Client Identifier to be mapped to the client device. This arbitrary human-readable nickname makes it easier to identify the device on the network.

Traditionally, devices were identified within DHCP by a hardware type code and a client hardware (MAC) address. Later, the optional Hostname field allowed more freedom when mapping device names in DHCP. Ironically, many people still used the hardware type followed by the client hardware address (for example, 01 00 01 02 a0 bc d3.) as a Hostname. However, you are not limited to that. You can create your own naming scheme.

These days, the client's DNS/Netbios name is often used as the Hostname. Every client device must have a unique Hostname on the broadcast domain. Otherwise, conflicts could occur.

Hostname description derived from IETF (IETF.ORG) RFC2131 Standards Track, DHCP Protocol, page 8 https://tools.ietf.org/html/rfc2131

Options

Ignore DHCP Requests from unknown devices:

Enabling this will ensure Tomato64 won't offer a DHCP lease to any DHCP requests from unlisted MAC addresses/Hostnames. A MAC address is considered unknown when there is no DHCP Reservation for it. Again, this won't apply to a client device configured with a (true) Static IP. By default, it will still be allowed on the network, unless further measures are taken.

The Ignore DHCP Requests from unknown devices function only works for devices in subnets with netmask 255.255.255.0 (previously called “Class C” subnets).

ARP only works with IPv4. IPv6 uses a different protocol for IP-to-MAC Address resolution protocol.

IPT

IPT stands for IP Traffic Monitoring. If Auto-Discovery is enabled in the IP Traffic Monitoring menu, every client device that is not marked as 'Disconnected' in Device List will be on the monitoring list. Enabling IPT puts inactive or disconnected client devices on the IP Traffic Monitoring list.