IPv6 Transition in the Session Initiation Protocol (SIP)
updates
- rfc-3264 — An Offer/Answer Model with Session Description Protocol (SDP)
Extracted elements (22)
Gathering both IPv4 and IPv6 addresses in the initial ICE offer reduces session establishment time: because any answerer (IPv4-only or IPv6-only) will find at least one compatible address in the offer, no re-offer/re-answer due to address type mismatch is needed.
IPv6 user agents bear the greater burden during the IPv4-to-IPv6 transition: since IPv6 UAs are fewer and expected to be dual-stack anyway, it is more pragmatic for them to obtain IPv4 addresses (via STUN relays) than to mandate an IPv6 upgrade across the vastly larger IPv4-only installed base.
RFC 2543-only endpoints are likely unable to parse or regenerate IPv6 network identifiers in SIP headers because RFC 2543's ABNF did not include production rules for IPv6 addresses; inserting a dual-stack proxy does not guarantee successful signaling with such endpoints.
RFC 3261 endpoints, even when running on IPv4-only nodes, are able to parse and regenerate IPv6 network identifiers in SIP headers, so the Record-Route dual-header mechanism works with RFC 3261 endpoints regardless of their network type.
RFC 3263 server location combined with RFC 3484 address selection (via getaddrinfo()) produces an ordered list of IPv6/IPv4 destination addresses ranked by source/destination pair merits, but implementers must account for getaddrinfo() implementations that may place IPv6 global addresses above IPv4 addresses even when only link-local IPv6 is configured, introducing connection delays.
A SIP proxy that receives a request over IPv6 and relays it to a downstream endpoint over IPv4 (or vice versa) MUST be configured to Record-Route so that it remains in the signaling path for all subsequent requests.
An IPv6 node SHOULD be able to send and receive media using IPv4 addresses; if it cannot, it SHOULD support STUN relay usage (TURN for IPv6, RFC 6156) to indirectly exchange media over IPv4.
Domains SHOULD deploy dual-stack outbound proxy servers (or both IPv4-only and IPv6-only proxies), and there SHOULD exist both IPv6 and IPv4 DNS entries for those proxies so user agents can obtain the address most appropriate for their IP version.
Domains SHOULD implement appropriate discovery mechanisms (e.g., both DHCPv4 and DHCPv6 options for SIP servers) to provide user agents with the IPv4 and IPv6 addresses of their outbound proxy servers.
Each media description in an SDP answer MUST use the same network type (IP4 or IP6) as the corresponding media description in the offer. This normatively updates RFC 3264.
IPv4/IPv6 dual-stack user agents SHOULD gather both IPv4 and IPv6 candidate addresses via ICE procedures when generating offers, so that both IPv4-only and IPv6-only answerers can find a mutually acceptable address.
IPv6 implementations MUST use a domain name within the .invalid DNS top-level domain (rather than the IPv6 unspecified address ::) when they need to specify the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in an SDP offer. This updates RFC 3264.
IPv6-only or dual-stack clients MUST use getaddrinfo() (rather than the legacy gethostbyname()) to translate a target hostname to IP addresses, so that the RFC 3484 Source and Destination Address Selection algorithms are applied.
Proxies MUST follow the recommendations in Section 5 (interaction of RFC 3263 and RFC 3484) to determine the order in which to contact downstream servers when routing a request.
User agent clients MUST follow the ICE-based address-gathering procedures in Section 4.2 and MUST follow the server-ordering recommendations in Section 5 when routing a request.
When a proxy inserting itself between IPv4 and IPv6 networks uses an IP address (rather than an FQDN) in the Record-Route header, it MUST insert two Record-Route headers: one with its address compatible with the downstream server's network type and one with its address compatible with the upstream client's network type.
When obtaining relay addresses, user agents MAY use any mechanism but it is RECOMMENDED they support STUN relay usage (TURN, RFC 5766 / RFC 6156) consistent with ICE recommendations.
After ICE address gathering and answer generation, both user agents perform ICE connectivity checks, which help prevent flooding attacks and discover additional usable addresses in the presence of NATs.
ICE (RFC 5245) is used by SIP user agents to gather local and relay candidate addresses (IPv4 and IPv6) for inclusion in SDP offers and answers, enabling NAT traversal and IPv4/IPv6 interoperability for media streams.
When a dual-stack proxy relays a SIP request between an IPv4 client and an IPv6 server and uses IP addresses in Record-Route, it inserts two Record-Route headers: the first contains the proxy's IPv6 address (facing the downstream UAS) and the second contains the proxy's IPv4 address (facing the upstream UAC), ensuring each party has the correct proxy address for subsequent requests.
Including both IPv4 and IPv6 addresses in SDP makes a UAC more susceptible to denial-of-service attacks targeting multiple network interfaces simultaneously. UACs should protect the confidentiality and integrity of SIP messages (e.g., via the SIPS URI scheme or S/MIME as described in RFC 3261 Sections 26.2.2 and 23).
When HTTP Digest is used for SIP authentication, the UAC should ensure the quality-of-protection (qop) parameter also covers the SDP payload, so that an attacker cannot tamper with media addresses without detection.