| Dispatch | O. Johansson |
| Internet-Draft | Edvina AB |
| Intended status: Standards Track | G. Salgueiro |
| Expires: December 26, 2013 | Cisco Systems |
| June 24, 2013 |
Locating SIP servers in a dual stack IP network
draft-johansson-sip-dual-stack-00
RFC 3263 defines how a SIP implementation given an URL should locate the next hop SIP server using DNS. The RFC repeatedly states that the implementation should look up IPv4 or IPv6 addresses, which is not a good solution considering the issues that lead to the development of Happy Eyeballs (RFC XXX). This document corrects this behaviour for dual stack SIP implementations so that an implementation so that an implementation should look up both IPv4 and IPv6 addresses. This way, the implementation can find the best network flow and have a greater chance in success in reaching the service.
This document also clarifies DNS SRV usage for single stack clients.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The SIP core RFCs was written with support for IPv4 and IPv6 in mind, but did not handle the migration phase where many servers and client implementations will run on dual stack hosts. During this phase one of the networks may run over a tunnel, starting with IPv6 over IPv4 and likely ending with IPv4 over IPv6. The use of automatically configured non-working tunnels lead to the development of the Happy Eyeballs RFC that has been implemented in many web browsers.
RFC 6157[RFC6157] focus on handling media in a dual stack network path between two SIP user agents. This doesn't solve the signalling issues that can occur, when trying to find the best network path to the next hop SIP server.
This document changes RFC 3263[RFC3263] so that a dual stack client must look up both A and AAAA records in DNS, and then select the best way to set up a network flow. How to do that is out of scope of this document (see Happy Eyeballs, RFC 6555[RFC6555] for more information about issues with setting up dual stack network flows).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 3261 [RFC3261] defines additional terms used in this document that are specific to the SIP domain such as "proxy"; "registrar"; "redirect server"; "user agent server" or "UAS"; "user agent client" or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; "server transaction".
This document uses the term "SIP Server" that is defined to include the following SIP entities: user agent server, registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server.
This document also uses the following terminology to make clear distinction between SIP entities supporting only IPv4, only IPv6 or supporting both IPv4 and IPv6.
RFC 3263[RFC3263] section 4.2. states
This has been proven to be the wrong solution for a dual stack client. A client that has support for both IPv4 and IPv6 SHOULD lookup both an A and an AAAA record and add the addresses to the list of IP addresses to be contacted. This is a normative update to RFC 3263.
A service may use DNS SRV records to indicate preference for an address family. This way, a server with a high-latency and low-capacity IPv4 tunnel may indicate a preference for being contacted using IPv6. A server that wishes to do this can use the lowest SRV priority to publish hostnames that only resolve in IPv6 and the next priority with host names that resolve into both address families.
Note that single stack clients needs to be prepared for SRV record sets that doesn't resolve into an address in the address family used by the client. In this case, the client should go to the next priority and try these host names.
This document changes lookup of SRV given host names to IP addresses. The scenarios discussed in this document do not introduce any new security threats. The specific security vulnerabilities, attacks, threat models of the various protocols discussed in this document (SIP, DNS, SRV records, etc.) are well documented in their respective documents.
This document does not require actions by IANA.
The author would like to acknowledge the support and contribution of the SIP Forum IPv6 Working Group. This document is based on a lot of tests and discussions at SIPit events, organized by the SIP Forum.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |