Summary

  • RFC 3361 gave DHCPv4 option 120 two mutually exclusive encodings: a preferred list of DNS names or an ordered list of IPv4 addresses for local SIP outbound proxies.
  • The name form could delegate transport, port, instance selection and fallback to DNS service records; the address form fixed a host order. Neither a valid option nor a successful lease proved the later SIP transaction or call path.

A network lease can look like an answer because it arrives at the beginning. The client receives an address, a router, perhaps a resolver and, under RFC 3361, a place to send outbound SIP requests. The packet is authoritative within a bounded configuration exchange. It is tempting to extend that authority all the way to a working call.

The protocol did not make that extension. It supplied a starting coordinate.

Published on the Standards Track in August 2002, RFC 3361 defined DHCPv4 option 120 for a local SIP outbound proxy. SIP clients could sometimes contact the destination named in a SIP URI directly. In other environments, including those with firewalls, they needed a local server for outbound requests. DHCP was one discovery method among several; manual configuration remained another.

The option contained a small but consequential switch. After its code and length came an encoding byte. A zero meant that the remaining value was a sequence of DNS domain names. A one meant that it was one or more binary IPv4 addresses. Implementations had to support both forms, even though the document preferred names.

Those were not two spellings of the same fact. A domain name could lead into the SIP server-location procedure defined by RFC 3263. That procedure used NAPTR records to discover supported transports, SRV records to identify service instances with ports, priorities and weights, and address records as a fallback. The client intersected what the domain offered with the transports it could use. The name was a delegation to a changing service-discovery graph.

An IPv4 list carried something narrower. The addresses were ordered by preference. The client could try one host and then another, but option 120 itself supplied no NAPTR service, SRV port, priority, weight or transport metadata. The ordered addresses were closer to a frozen route to candidate hosts than to a service description.

This distinction changed who could alter the next decision. With a domain, a DNS administrator could move service among instances, change the advertised transport or adjust SRV ordering without issuing a new DHCP lease. With a literal address list, the DHCP administrator held more of that selection in the option. Neither model eliminated client policy, software capability, cached state or failure. They placed the levers differently.

RFC 3361 also gave multiple domain names a specific meaning. They should represent different NAPTR domains, not merely different A records for the same domain. The client tried them in listed order. It moved to the next name only if contacting the first failed, no common transport existed, or client policy prohibited the domain. The feature allowed one DHCP authority to identify outbound proxies operated by different providers; it was not meant to replace NAPTR and SRV balancing inside a provider.

Order therefore existed at several layers. DHCP ordered provider domains. NAPTR ordered transport services. SRV applied priority and weight among instances. Address resolution produced reachable candidates. Client capability and policy removed unacceptable choices. A single phrase such as “the configured proxy” hides all those selectors.

RFC 3263 added an important transaction boundary. Once a SIP server had been contacted successfully for a transaction, retransmissions, a CANCEL and the ACK for a non-2xx final response had to remain with the same server. Discovery could choose among candidates before contact, but it could not randomly spread one transaction after state existed. A changing DNS answer and a transaction's chosen peer belonged to different clocks.

The option format exposed another boundary between syntax and meaning. A DHCP server was forbidden to mix the DNS and IPv4 encodings in one message, even by putting them in separate instances of option 120. DHCP processing concatenates repeated occurrences of one option before interpreting them. Two locally well-formed fragments with different first-byte grammars would become one malformed semantic object.

That prohibition anticipated a wider DHCP problem. RFC 3396, issued later in 2002, standardized the order for concatenating repeated DHCPv4 options and allowed long values to span option instances and overloaded fields. It also recorded an uncomfortable deployment fact: many DHCP agents then in use did not implement option concatenation. A sender could follow the long-option rule and still meet a receiver that could not reconstruct the permitted value.

RFC 3361 required a DNS-name list longer than one option's capacity to use that mechanism. Thus even before DNS began, a long provider list depended on correct DHCP fragment ordering and reassembly. “The server sent it” and “the client parsed the same option” were separate claims.

The following year's DHCPv6 design made the trade-off visible by changing it. RFC 3319 defined two option codes, one for SIP server domain names and another for IPv6 addresses. It explicitly said DHCPv6 did not suffer from a shortage of option codes, so it could avoid the IPv4 encoding byte. Separate options shortened and simplified parsing, improved alignment for numeric addresses and let a client request the form it wanted. Scarcity in one namespace had shaped complexity in another protocol message.

The DNS encoding carried its own historical ambitions. RFC 3361 used RFC 1035 label encoding and required clients to support DNS compression, partly to accommodate future internationalized domain-name mechanisms. The service records beneath a name drew on the SRV model in RFC 2782 and the NAPTR record formalized by RFC 3403. Option 120 was small because it could point into larger, independently maintained machinery.

That indirection enlarged both flexibility and trust. RFC 3361 warned that an attacker able to modify or insert a DHCP response could send a user agent to a rogue SIP server, enabling interception or denial of service. A modified reply could also omit host names that would resolve to TLS-based SIP servers, making interception easier. The configuration source did not carry media, yet it could decide which signaling gate the client approached and which safer possibilities disappeared before selection.

The current IANA BOOTP and DHCP Parameters registry still records code 120 as the SIP Servers DHCP Option. That is a durable coordination record. It proves the code's registered association, not that a particular server sends it, a client requests it, an implementation parses both forms or a network uses it today.

The same restraint applies to an observed lease. A packet capture can prove that option 120 arrived with particular bytes. A decoder can prove that those bytes form a name list or an address list. Neither proves that DNS returned records, that the selected transport overlapped with client capability, that a connection opened, that the proxy accepted a SIP transaction, that downstream proxies located the destination, that session negotiation completed or that media flowed.

Each layer needs its own receipt. Preserve the DHCP server and relay path, raw option bytes, encoding and ordering. For a name, preserve NAPTR, SRV and A or AAAA answers with TTLs and the client's filtered choice. For an address, preserve attempt order, port and transport. Then record proxy contact, transaction response, downstream routing, session description negotiation and media separately.

Two essays by Lu Heng are used here as disclosed analytical lenses. “Minimum Initial Specification” helps explain the value of a narrow common option that leaves provider operation, DNS policy and deployment decisions local. “Reality Layers” keeps a registered code, delivered configuration, resolved service, running implementation and call outcome from collapsing into one claim. These are editorial readings, not statements about the authorship or intent of RFC 3361.

Option 120 did exactly enough to create a rendezvous. Its two encodings also showed that a rendezvous could be delegated to a live naming system or frozen into an address order. The lease named where signaling should begin. Whether signaling continued was a question for the next evidence layer.

Sources