Skip to main content

Locating SIP servers in a dual stack IP network
draft-johansson-sip-dual-stack-00

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
Additional resources
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]