[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"article-dhcp-option-82-device-identification-field-networks-en":3},"# DHCP Option 82 Device Identification in Field Networks: Why Static IP Is Not Enough\n\nIn a modem fleet spread across thousands of branches, managing devices with static IPs looks orderly at first: every branch has an address, a table is kept, and when there is a problem you look at the address. As the network grows this table drifts away from reality. When a modem is replaced the old address is moved to the new device by hand, the installer enters the wrong address, two branches end up with the same address, and which device is really at which branch only becomes clear once somebody goes out to the site. More importantly, a static IP leaves the device's identity to the device itself: anyone who knows the address and can reach the device can look like that branch.\n\nDHCP Option 82 reverses this relationship. When the device sends a DHCP request it adds extra fields about itself to the request: the Circuit ID that identifies the circuit it is attached to, the Remote ID that identifies the far end, the serial number, VLAN ID, physical port and, where present, the SSID. The central DHCP server hands out the address by looking at this information. Identity is no longer the answer to \"which address\" but to \"which circuit, which port, which VLAN\". When a device is removed and plugged in at another point the Circuit ID changes and the system sees this on the first request.\n\nThis has three practical consequences in large field networks. Inventory stays correct on its own; wherever the device is seen on a circuit is where it is. The IP assignment policy becomes a rule; modems carrying camera traffic take an address from one range, alarm panels from another and management traffic from a third, and this separation becomes the basis of the segmentation rules. Incident review gets easier; because the log record carries the Circuit ID and port information alongside the address, suspicious traffic is tied directly to a physical point.\n\nThere is less to watch out for on the deployment side. The Circuit ID and Remote ID format should be settled at the start according to the organisation's naming scheme; changing it later requires reconfiguring every device. Existing devices with static IPs are not migrated overnight; running in mixed mode and moving over in groups, verifying the inventory and the access rules after each group, is safer. If there are older modems without Option 82 support, they either have to be replaced or the fields have to be added through an intermediate layer (relay). If the device supports OpenWrt there is a third route: OpenWrt's DHCP client (udhcpc/odhcp6c) can be configured to send the Option 82 sub-options, so that even when the manufacturer firmware does not support it the same hardware becomes Option 82 compatible with OBIFI OpenWrt firmware.\n\nIn OBIFI Fleet Management, Option 82 based identification is the default mode of operation; the field formats are customised from the panel and static IP use can be switched off as a policy. For the details you can look at the product page: [Modem and Router Fleet Management](/product/fleet-management).\n",1789393017018]