MMUSIC                                                          T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                            P. Martinsen
Expires: June 12, 2014                                             Cisco
                                                       December 09, 2013


                    Happy Eyeballs Extension for ICE
                draft-reddy-mmusic-ice-happy-eyeballs-04

Abstract

   This document provides guidelines on how to make ICE [RFC5245]
   conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths
   exists.

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 June 12, 2014.

Copyright Notice

   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.




Reddy, et al.             Expires June 12, 2014                 [Page 1]

 
Internet-Draft           Happy Eyeballs for ICE            December 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2
   2.  Improving ICE Dual-stack Fairness . . . . . . . . . . . . . .   2
   3.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

.  Introduction

   There is a need to introduce more fairness in the handling of
   connectivity checks in dual-stack IPv4/IPv6 ICE scenarios.
   Section 4.1.2.1 of ICE [RFC5245] points to [RFC3484] for prioritizing
   among the different IP families.  [RFC3484] is obsoleted by [RFC6724]
   but following the recommendations from the updated RFC will still
   lead to prioritization of IPv6 over IPv4 with the same candidate
   type.  There can be a lot of ICE candidates belonging to one address
   family which results in user-noticable setup delays if the path for
   that address family is broken.

   To avoid such user-noticable delays when the IPv6 path or IPv4 path
   is broken, this specification encourages earlier checking of the
   other address family.  Greater IP address family fairness into ICE
   connectivity checks will lead to more sustained IPv6 deployment (so
   users will no longer have an incentive to disable IPv6), which incurs
   only a small penalty for the IPv4 connectivity checks.

1.1.  Notational Conventions

   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 [RFC2119].

   This document uses terminology defined in [RFC5245].

.  Improving ICE Dual-stack Fairness

   Candidates SHOULD be prioritized such that a long sequence of
   candidates belonging to the same address family be interleaved with
   candidates from the alternate IP family.  For example, promoting IPv4
   candidates in the presence of many IPv6 addresses such that an IPv4
   address candidate is always present after a small sequence of IPv6
   addresses.  This makes ICE connectivity checks more responsive to
   failures of an address family by reordering the candidates such that



Reddy, et al.             Expires June 12, 2014                 [Page 2]

 
Internet-Draft           Happy Eyeballs for ICE            December 2013


   IPv6 and IPv4 candidates get a fair chance during connectivity
   checks.

   An ICE agent can choose an algorithm or a technique of its choice to
   promote IPv4 candidates.

.  Compatibility

   ICE [RFC5245] section 4.1.2 states that the formula in section
   4.1.2.1 SHOULD be used.  Failing to do so may lead to ICE taking
   longer to converge as the checklist no longer will be coordinated.
   Therefore responsiveness of ICE candidate checks are improved when
   both sides support Happy-Eyeballs, both sides have the same number of
   candidate pairs, and both sides use the same Happy Eyeballs promotion
   algorithm.

   If each ICE agent uses a different algorithm to promote IPv4
   candidates, ICE connectivity checks will be as responsive as the
   least aggressive algorithm.  This is because the MAX/MIN candiate-
   pair logic ensures that for a particular agent, a lower-priority
   candidate is never used (for media) until all higher-priority
   candidates have been tried.

   If only one ICE agent supports Happy-Eyeballs, there is potentially
   no change in pacing of ICE connectivity checks and the situation is
   no worse than what exists today

.  IANA Considerations

   None.

.  Security Considerations

   STUN connectivity check using MAC computed during key exchanged in
   the signaling channel provides message integrity and data origin
   authentication as described in section 2.5 of [RFC5245] apply to this
   use.

.  Acknowledgements

   Authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba,
   Martin Thomson and Jonathan Lennox for their comments and review.









Reddy, et al.             Expires June 12, 2014                 [Page 3]

 
Internet-Draft           Happy Eyeballs for ICE            December 2013


.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

Authors' Addresses

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com


   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore
   India

   Email: praspati@cisco.com


   Paal-Erik Martinsen
   Cisco Systems, Inc.
   Philip Pedersens vei 22
   Lysaker, Akershus  1325
   Norway

   Email: palmarti@cisco.com





Reddy, et al.             Expires June 12, 2014                 [Page 4]