Locating SIP servers in a dual stack IP network
draft-johansson-sip-dual-stack-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
---|---|---|---|
Authors | Olle E. Johansson , Gonzalo Salgueiro | ||
Last updated | 2013-06-24 | ||
Replaced by | draft-ietf-sipcore-dns-dual-stack, RFC 7984 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-johansson-sip-dual-stack-00
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 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Johansson & Salgueiro Expires December 26, 2013 [Page 1] Internet-Draft Locating SIP servers dual stack June 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions Used in This Document . . . . . . 2 3. A dual stack SIP ua should look up both A and AAAA records . 3 4. Indicating address family preference in SRV . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 8.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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). 2. Terminology and Conventions Used in This Document Johansson & Salgueiro Expires December 26, 2013 [Page 2] Internet-Draft Locating SIP servers dual stack June 2013 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. IPv4-only UA/UAC/UAS: An IPv4-only UA/UAC/UAS supports SIP signaling and media only on the IPv4 network. It does not understand IPv6 addresses. IPv6-only UA/UAC/UAS: An IPv6-only UA/UAC/UAS supports SIP signaling and media only on the IPv6 network. It does not understand IPv4 addresses. IPv4/IPv6 UA/UAC/UAS: A UA/UAC/UAS that supports SIP signaling and media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known (and will be referred to in this document) as a "dual-stack" [RFC4213] UA/UAC/UAS. 3. A dual stack SIP ua should look up both A and AAAA records RFC 3263[RFC3263] section 4.2. states "If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. " 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. 4. Indicating address family preference in SRV Johansson & Salgueiro Expires December 26, 2013 [Page 3] Internet-Draft Locating SIP servers dual stack June 2013 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. 5. Security Considerations 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. 6. IANA Considerations This document does not require actions by IANA. 7. Acknowledgements 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. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Johansson & Salgueiro Expires December 26, 2013 [Page 4] Internet-Draft Locating SIP servers dual stack June 2013 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009. [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. Authors' Addresses Olle E. Johansson Edvina AB Runbovaegen 10 Sollentuna SE-192 48 SE Email: oej@edvina.net Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: gsalguei@cisco.com Johansson & Salgueiro Expires December 26, 2013 [Page 5]