Happy Earballs: Success with Dual-Stack SIP
draft-worley-sip-happy-earballs-01

Document Type Active Internet-Draft (individual)
Last updated 2017-03-02
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SIPCORE                                                        D. Worley
Internet-Draft                                                   Ariadne
Intended status: Standards Track                           March 2, 2017
Expires: September 3, 2017

              Happy Earballs: Success with Dual-Stack SIP
                   draft-worley-sip-happy-earballs-01

Abstract

   TBD: The Session Initiation Protocol (SIP) supports multiple
   transports running both over IPv4 and IPv6 protocols.  In more and
   more cases, a SIP user agent (UA) is connected to network interfaces
   with multiple address families.  In these cases sending a message
   from a dual stack client to a dual stack server may suffer from the
   issues described in [RFC6555] ("Happy Eyeballs"): the UA attempts to
   send the message using IPv6, but IPv6 connectivity is not working to
   the server.  This can cause significant delays in the process of
   sending the message to the server.  This negatively affects the
   user's experience.

   TBD: This document builds on [RFC6555] by modifying the procedures
   specified in [RFC3263] and related specifications to require that a
   client ensure that communication targets are accessible before
   sending messages to them, to allow a client to contact targets out of
   the order required by other specifications, and to require a client
   to properly distribute the message load among targets over time.

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 September 3, 2017.

Worley                  Expires September 3, 2017               [Page 1]
Internet-Draft               Happy Earballs                   March 2017

Copyright Notice

   Copyright (c) 2017 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Structure of This Document  . . . . . . . . . . . . . . . . .   8
     3.1.  Scope of Applicability  . . . . . . . . . . . . . . . . .   9
   4.  Baseline Procedures . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Target Ordering . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Priority Nodes  . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Unordered Nodes . . . . . . . . . . . . . . . . . . . . .  14
     4.4.  Combinations of Prioritization and Unordered Nodes  . . .  14
     4.5.  Load-Balancing Nodes  . . . . . . . . . . . . . . . . . .  17
   5.  Primary Procedure Modifications . . . . . . . . . . . . . . .  18
     5.1.  Permitted to Reorder Targets  . . . . . . . . . . . . . .  18
     5.2.  Must Preserve Traffic Distribution  . . . . . . . . . . .  18
   6.  Additional Requirements . . . . . . . . . . . . . . . . . . .  19
     6.1.  Address Family Preference . . . . . . . . . . . . . . . .  19
     6.2.  Address Selection . . . . . . . . . . . . . . . . . . . .  20
     6.3.  Vias  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.4.  DNS Caching . . . . . . . . . . . . . . . . . . . . . . .  21
     6.5.  Unused Flows  . . . . . . . . . . . . . . . . . . . . . .  21
     6.6.  Debugging and Troubleshooting . . . . . . . . . . . . . .  22
   7.  Consequences of the New Requirements  . . . . . . . . . . . .  22
   8.  Generic Algorithm . . . . . . . . . . . . . . . . . . . . . .  26
     8.1.  Policies and Implementor Latitude . . . . . . . . . . . .  27
     8.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  28
       8.2.1.  Two Unordered Targets, Both Cached  . . . . . . . . .  28
Show full document text