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.

Table of Contents

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

1. 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].

2. 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 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.

3. 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

4. IANA Considerations

None.

5. 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.

6. Acknowledgements

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

7. Normative References

Authors' Addresses