Summary

  • RFC 3319 defined two DHCPv6 options for finding local SIP outbound proxies: an ordered domain-name list and an ordered IPv6-address list.
  • The client preferred names when both arrived and applied SIP server-location rules; the options supplied candidates, not proof of a trusted proxy or a completed call.

A lease could answer a narrower question than a phone call asked

The problem RFC 3319 addressed was easy to misstate. A SIP client might know the address written in a SIP URI and still need a local outbound proxy. A firewall, a local dialing plan, emergency or other local services could make that intermediary useful. Manual configuration was one answer; the RFC offered another: let DHCPv6 tell the client where candidate outbound proxies could be found.

The boundary is in the noun. The option identifies a server for outbound SIP requests. It does not describe the whole SIP service. RFC 3261 separates user agents, proxy servers, redirect servers and registrars. RFC 3319 uses “SIP server” specifically for the host running an outbound proxy. A list of those hosts cannot, by itself, show that a user registered, a destination was authorized, a SIP dialog completed, media was negotiated, or a call worked.

Two encodings, one preference procedure

RFC 3319 assigns option 21 to OPTION_SIP_SERVER_D, a domain-name list, and option 22 to OPTION_SIP_SERVER_A, an IPv6-address list. Both lists are ordered by preference. An implementation of the specification must support both. A client asks for either or both in DHCPv6's Option Request Option; the server's reply still depends on its configuration and what the client requested. Even when both are requested, the server may return only one and should favor the domain-name option.

If both lists arrive, the client should use the domain names first. Numeric addresses are a conditional fallback: the client may try them only when no name in the first list can be resolved or reached. That is more specific than “try every possible address.” A client does not immediately resolve every later name either. It follows the list in preference order and moves on when the preceding attempt fails, yields no transport the two sides share, or falls under a prohibition in client policy.

A name was an input to SIP location, not a replacement for it

The domain-name option feeds into the server-location behavior described by RFC 3263. Names in the list should refer to different NAPTR records rather than merely different A records. RFC 3319 notes that a single DHCP server can thereby indicate proxies operated by multiple providers. But the option does not replace NAPTR or SRV records: it supplies a starting set of domains, then the SIP location machinery and transport rules still matter.

This sequence makes the word “fallback” do real work. A later domain is not automatically a backup just because it appears in the packet. The client reaches it after a defined condition. A numeric IPv6 list is farther down the preference path when domain names were also provided. Client policy can also rule out a name. The DHCP list therefore carries both destination candidates and ordering, while the client retains decisions about resolution, transport and permissible use.

That is a useful control-plane division. The network can distribute local service choices without hard-coding one proxy into every client. Yet the response does not establish that a listed host answers, speaks a mutually usable transport, accepts this user's request, or can carry the rest of the session. “Configured as preferred” and “successfully used” are different observations.

Configuration is also a point where trust can be redirected

The security section makes the boundary consequential. If an adversary modifies a DHCP response or inserts a false one, a user agent can be steered toward a rogue SIP server. Such a server might intercept call requests or deny service. An altered answer could also omit hostnames that would have led to TLS-capable SIP servers, easing interception.

That is the RFC's threat model, not an incident report. It does not say an arbitrary received address is authentic, or that every configured name resolves to TLS. The option is part of a trust chain: a DHCP answer influences where an application next sends signaling. The chain still needs whatever protections, identity checks and policy the wider system requires. Finding a server is not authenticating it.

The old option remains visible in newer DHCPv6 records

The DHCPv6 specification has since moved on: RFC 9915 is the current general specification, superseding RFC 8415. Yet the IANA DHCPv6 Option Codes registry still records codes 21 and 22 under RFC 3319, and RFC 9243 later provides YANG configuration groupings for the two SIP server option forms. Those records show continued administrative and data-model reference. They do not measure operator use, client support, successful fallback or call completion.

RFC 3319's contribution was narrower and more interesting than “DHCP finds a phone server.” It formalized a ranked way for a client to discover a local outbound proxy, with a domain-name-first path and an address-list fallback. The final call remained outside that option: discovery could get signaling pointed somewhere; it could not certify what happened next.

Sources