Project

General

Profile

Actions

Feature #6544

open

RFC 3046 DHCP Option 82 support (and RFC 3315/4649/4580 for IPv6)

Added by Bruce Simpson over 7 years ago. Updated over 3 years ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
DHCP (IPv4)
Target version:
-
Start date:
06/27/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

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.

Actions #1

Updated by Jim Pingle over 4 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.

Actions #2

Updated by Viktor Gurov over 3 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:
Circuit ID:
- Router interface number
- Switching Hub port number
- Remote Access Server port number
- Frame Relay DLCI
- ATM virtual circuit number
- Cable Data virtual circuit number
Remote ID:
– 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 ?

Actions

Also available in: Atom PDF