Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network
updates
- rfc-3263 — Session Initiation Protocol (SIP): Locating SIP Servers
Extracted elements (14)
A server wishing to indicate address family preference can use DNS SRV priority: publishing host names that resolve only in IPv6 at the lowest (preferred) SRV priority and host names that resolve in both address families at the next priority, allowing high-latency IPv4-tunnel servers to prefer IPv6 contact.
The major ordering of destination addresses is determined by SRV priority and weight (per RFC 2782), while the minor ordering among addresses from a single SRV target is determined by RFC 6724. Addresses from different SRV targets are never interleaved, even when SRV records share the same priority.
This document updates RFC 3263 DNS lookup procedures in preparation for forthcoming Happy Eyeballs specifications for SIP, because looking up only 'A or AAAA records' (not both) adds significant connection delay for dual-stack clients and degrades user experience.
Unlike HTTP, SIP cannot 'race' simultaneous connection attempts across IPv4 and IPv6 without risk of duplicate requests propagating through the SIP network, because a sender cannot test a route in a non-state-changing way. This prevents direct application of the Happy Eyeballs algorithm to SIP.
The getaddrinfo() function is the typical implementation vehicle for RFC 6724 address selection, translating a target DNS name into an ordered list of IPv4 and/or IPv6 addresses. This function should be invoked per SRV target, not across the full address set.
This document clarifies the interaction between RFC 3263 SIP server location, RFC 6157 IPv6 transition in SIP, and RFC 6724 default address selection: RFC 6724 ordering applies per single SRV target, with RFC 2782 SRV priority/weight governing ordering across targets.
A dual-stack client MUST be prepared for the existence of DNS resource records containing addresses in families that it does not support; such records MUST be ignored as unusable.
A dual-stack SIP client SHOULD look up address records for all address families it supports for a domain name and add the resulting addresses to the list of IP addresses to be contacted.
If two copies of the same SIP request arrive at the destination client, the client SHOULD reject the second with a response code of 482 (Loop Detected), optionally including a reason phrase such as 'Merged Request'.
Special-purpose host names that resolve in only one address family SHOULD be used only as targets of SRV records for an aggregate host name that ultimately resolves to addresses in all families supported by the client.
The destination address selection algorithm defined in RFC 6724 MUST be applied to the address records for a single SRV record's target DNS name; it MUST NOT reorder addresses derived from different SRV records.
DNS SRV records for SIP may be used to indicate address family preference by assigning lower priority values to SRV records whose targets resolve only in the preferred address family (e.g., IPv6-only targets at priority 10, dual-stack targets at priority 20).
The term 'address records' in this document encompasses all DNS record types that translate a domain name into addresses within any supported address family, including A records (IPv4) and AAAA records (IPv6), and any future address-family record types.
The two new normative DNS procedures introduced here—contacting additional target addresses and/or contacting them in a different order than RFC 3263 prescribes—introduce no new security considerations, since it has always been assumed a client may contact any DNS-listed target for a URI.