ISO/IEC IEC 29341-14-3:2011 — UPnP LAN Device

Overview of the UPnP LAN Device Template

ISO/IEC 29341-14-3:2011 defines the LANDevice:1 device template, a component of the UPnP Internet Gateway Device (IGD) specification that focuses on local area network management. While the WANIPConnection service manages the upstream Internet link, the LANDevice template provides the service interfaces for configuring and monitoring the gateway’s LAN-side network parameters. This includes DHCP server configuration, IP address pool management, subnet mask and gateway address settings, and LAN interface statistics.

The LANDevice template is identified by the device type urn:schemas-upnp-org:device:LANDevice:1. It encapsulates the LANHostConfigManagement:1 service, which provides the core configuration actions for the gateway’s DHCP server and IP address management. The standard defines the LAN device as a logical entity that manages a single broadcast domain (subnet). Gateways with multiple LAN segments (e.g., guest networks, VLANs) may expose multiple LANDevice instances, each with its own service configuration.

The LANHostConfigManagement service exposes state variables that define the network configuration: DHCPServerEnabled (boolean), MinAddress, MaxAddress (pool range), SubnetMask, IPRouters (default gateway), DNSServers, and DomainName. These variables collectively define the configuration that the DHCP server delivers to clients through DHCPOFFER and DHCPACK messages. The service also provides a DHCPLeaseInfo variable that aggregates active lease information for monitoring purposes.

DHCP Server Configuration and Lease Management

The LANHostConfigManagement service provides actions for reading and modifying the DHCP server configuration. The GetSubnetMask(), GetIPRouters(), GetDNSServers(), and GetDomainName() actions retrieve the current network configuration parameters. The SetSubnetMask(), SetIPRouters(), SetDNSServers(), and SetDomainName() actions allow control points to modify these parameters. A key design consideration is that changes to these parameters do not take effect until the DHCP server is restarted — the service provides a separate mechanism for this.

The DHCP lease information is exposed through the GetDHCPLeaseInfo() action, which returns a CSV-formatted string containing details about each active lease: MAC address, assigned IP address, lease start time, lease duration, and hostname. This is particularly valuable for network monitoring and inventory management applications. The lease information format is: MAC,IP,StartTime,Duration,Hostname. For example: 00:11:22:33:44:55,192.168.1.101,1265432100,86400,johns-phone. Control points can parse this information to build a real-time map of connected devices and their network usage patterns.

An important engineering detail is the interaction between the DHCP server and the gateway’s routing subsystem. When the DHCP server assigns an IP address to a client, the gateway should automatically create an ARP entry and, if configured, install a corresponding firewall rule allowing the client to access the WAN. The LANHostConfigManagement service does not directly manage firewall rules, but the IGD overall architecture expects the gateway to coordinate between DHCP assignments and firewall policy. This coupling is implementation-specific and represents a common source of integration complexity for gateway firmware engineers.

Address Pool Management and Network Configuration

The MinAddress and MaxAddress state variables define the inclusive range of the DHCP address pool. The address pool must be within the subnet defined by SubnetMask and should exclude the gateway’s own IP address (typically the first address in the subnet). When a control point modifies the address pool range, the gateway must ensure that existing DHCP leases whose addresses fall outside the new range are gracefully handled — typically by allowing them to expire naturally rather than forcing immediate reassignment, which would cause network disruption for those clients.

The IPRouters variable specifies the default gateway addresses advertised to DHCP clients. While typically a single address (the gateway’s own LAN IP), the CSV format allows multiple router addresses for networks with redundant gateways. Similarly, DNSServers can list multiple DNS servers for redundancy. The gateway should validate that all configured router and DNS addresses are reachable within the local subnet — advertising unreachable addresses causes connectivity issues that are difficult for end users to diagnose.

The DHCPServerEnabled boolean variable controls whether the DHCP server is active. When disabled, clients on the LAN must use static IP configuration or rely on an external DHCP server. This is useful in enterprise environments where a centralized DHCP server is already deployed. The gateway should still maintain its own IP address and routing functionality when DHCP is disabled — only the address assignment service is deactivated. The SetDHCPServerEnabled() action with false causes the gateway to stop responding to DHCPDISCOVER messages but does not clear existing leases, allowing connected clients to retain their addresses until lease expiration.

Engineering Insights for LAN Device Implementation

Implementing the LANDevice template requires careful coordination between the UPnP service layer and the gateway’s networking stack. The UPnP state variables must reflect the actual running configuration of the DHCP server and network interfaces. A common architectural pattern uses a configuration abstraction layer that translates UPnP actions into calls to the underlying operating system’s networking APIs (ioctl, netlink, or system configuration files). On Linux-based gateways, this typically involves reading and modifying /etc/dhcpd.conf (or equivalent) and sending SIGHUP to the DHCP daemon process to apply changes.

Multi-instance support is another important consideration. Some gateways support multiple LAN segments through VLANs or additional physical interfaces. Each LAN segment should be exposed as a separate LANDevice instance with its own independent configuration. The IGD device description must enumerate all LANDevice instances, and control points can use the GetLANDevice() action on the IGD to discover available instances. The standard suggests that instances be numbered sequentially (LANDevice.1, LANDevice.2, etc.) although the actual instance numbering is implementation-defined.

DHCP lease persistence across gateway reboots is critical for user experience. Without persistence, all connected devices lose their assigned IP addresses on every reboot and must renegotiate new leases, causing a temporary network outage that can last from seconds to minutes depending on the DHCP client timeout configuration. Implement a lease database in non-volatile storage (flash, NVRAM, or a configuration file) that is restored during gateway initialization. The lease database should be updated on every DHCPACK event and checkpointed periodically to minimize data loss on unexpected power failure.

Frequently Asked Questions