RFC 3046 DHCP Option 82 support (and RFC 3315/4649/4580 for IPv6)
We use an HPE switch to implement MAC layer security. It is configured to snoop DHCP request & inject Option 82 (RFC 3046) to tell us exactly which port and chassis a client is connected to.
isc-dhcpd will record Option 82 in the lease file, but the pfSense GUI does not do anything with the information.
We understand there is a third-party patch for this, but it currently appears to be unmaintained, and may not have been updated for pfSense 2.3.1-x.
(This might well be a good fit for a more general package of Layer 2 security features in pfSense)
Our switch does not currently support the DHCPv6 Interface-ID option, (as in RFCs 3315, 4649, 4580) but we're keen to use these also.
Updated by Jim Pingle almost 3 years ago
- Category set to DHCP (IPv4)
- Priority changed from Normal to Very Low
If someone wants to make PR to show this info in the GUI somewhere, we can consider it. But adding a whole column for a feature few people use seems like it wouldn't be a good use of GUI real estate. Maybe as a second line under the MAC address column.
Updated by Viktor Gurov almost 2 years ago
comment from https://forum.netgate.com/topic/64792/usd-50-dhcp-option-82-on-status_dhcp_leases-php-page/12:
Please see RFC 3046:
Agent Circuit ID Sub-option: https://tools.ietf.org/html/rfc3046#section-3.1
Agent Remote ID Sub-option: https://tools.ietf.org/html/rfc3046#section-3.2
Both are supposed to be opaque:
"The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server."
"The option [NB: Remote ID] SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server."
In addition, the meaning of both are left to the specific implementations of each particular DHCP Relay Agents:
- Router interface number
- Switching Hub port number
- Remote Access Server port number
- Frame Relay DLCI
- ATM virtual circuit number
- Cable Data virtual circuit number
– a "caller ID" telephone number for dial-up connection
-- a "user name" prompted for by a Remote Access Server
-- a remote caller ATM address
-- a "modem ID" of a cable data modem
-- the remote IP address of a point-to-point link
-- a remote X.25 address for X.25 connections
IMHO, each switch/router/ras manufacturer/model would have its own implementation that would invalidate the code below (or above depending on sorting :) )
If one would be to implement such a feature, maybe an optional input box with some modifiable regex that would be applied on the raw strings might be more future-proof ?