Summary

  • RFC 3456 placed DHCPv4 inside a temporary IPsec tunnel so leases, pools, options, reconfiguration and failover could remain in an existing configuration system rather than being rebuilt inside IKE.
  • The DHCPACK and leased inner address were configuration receipts, not access credentials: a host could choose its own source address, and the relay-to-server path was outside IPsec protection unless separately authenticated.

Two addresses described two different realities

Published in January 2003, RFC 3456 described a remote host with an Internet-facing outer address and a separately configured intranet-facing virtual address. The outer address terminated the IPsec tunnel at a corporate security gateway. The inner address made the host appear to corporate resources as if it sat behind that gateway.

That was useful indirection, not identity fusion. The plain-text RFC, RFC Editor record, Datatracker file, history, references, later citations and errata search establish the standards record. They do not show that a particular lease authorized a user or that an application reached its destination.

The sequence began with an IKE security association. A short-lived, DHCP-only tunnel-mode SA then carried DHCPDISCOVER or DHCPREQUEST traffic to the gateway. After DHCP returned an address and options, the host could establish a broader VPN SA using the new address in the Quick Mode identity. The temporary channel, the lease and the general data tunnel were separate state transitions.

Reuse kept configuration out of the key exchange

The contemporaneous remote-access requirements in RFC 3457 called for more than an address. Administrators needed pools, options, reconfiguration, failover and integration with existing management. RFC 2131 and the option vocabulary in RFC 2132 already supplied that machinery. RFC 3442 shows how routing information could also travel as a DHCP option.

RFC 3456 therefore resisted turning IKE into a second configuration service. Its appendix argued that a minimal IKE configuration exchange would eventually duplicate leases, renewals, authentication and failover. The design kept cryptographic negotiation bounded and let DHCP retain ownership of address state.

The virtual interface received hardware type 31. A client identifier had to be unique on the virtual subnet and should survive reboots. The current IANA ARP parameters registry preserves the allocation. Those identifiers helped correlate configuration; neither was declared a human identity or authorization token.

The relay created a visible security seam

The gateway usually acted as a DHCP relay rather than the server. It could place its address in giaddr or use the Relay Agent Information mechanism from RFC 3046, including a circuit identifier for the virtual tunnel port. It could inspect yiaddr in DHCPACK and install a route back to the correct tunnel.

Yet IPsec protected DHCP only from remote host to gateway. Between gateway and DHCP server, integrity and authentication required a separate mechanism such as RFC 3118. One protected segment did not confer protection on the next.

The strongest sentence in the security section followed from a mundane capability: a remote host could set its own IP address. Even authenticated DHCP could not stop that. The assigned address therefore had to remain outside the access-control decision. Per-tunnel filters or Quick Mode selectors had to bind permitted traffic to the authenticated tunnel context. The IPsec architecture in RFC 2401 and IKE in RFC 2409 provide the surrounding policy and negotiation model, not proof that one deployment installed the intended selectors.

The ACK was one receipt in a longer chain

A DHCPACK showed that configuration returned through a transaction. A relay circuit identifier showed where the gateway meant to send the response. A route entry showed a local forwarding decision. An SPD rule or negotiated selector showed a policy binding. Observed application traffic showed something later. None could silently stand in for all the others.

Heng Lu's reality-layer discipline makes that separation explicit. Running-code primacy directs attention to installed routes, selectors and packets rather than a reassuring diagram. The minimum-initial-specification lens explains the value of reusing DHCP instead of inflating IKE. These are later editorial interpretations, not evidence of the RFC authors' private intent.

RFC 3456 did not diminish DHCP by refusing to call a lease authorization. It preserved the protocol's authority. DHCP could configure the virtual presence; the security gateway still had to decide what that presence was allowed to do.

Sources