Update on Candidate Address Selection for Interactive Connectivity Establishment (ICE)
draft-keranen-mmusic-ice-address-selection-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Ari Keränen  , Jari Arkko 
Last updated 2012-03-05
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized 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)
Network Working Group                                         A. Keranen
Internet-Draft                                                  J. Arkko
Updates: 5245, 6544 (if approved)                               Ericsson
Intended status: Standards Track                           March 5, 2012
Expires: September 6, 2012

               Update on Candidate Address Selection for
              Interactive Connectivity Establishment (ICE)
             draft-keranen-mmusic-ice-address-selection-00

Abstract

   This document revisits the rules on how candidate addresses are
   selected and combined when the Interactive Connectivity Establishment
   (ICE) NAT traversal method is used.  This document updates RFCs 5245
   and 6544.

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 6, 2012.

Copyright Notice

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

Keranen & Arkko         Expires September 6, 2012               [Page 1]
Internet-Draft     Candidate Address Selection for ICE        March 2012

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Changes to Candidate Address Selection  . . . . . . . . . . . . 3
   4.  Negotiating Address Selection Scheme  . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Keranen & Arkko         Expires September 6, 2012               [Page 2]
Internet-Draft     Candidate Address Selection for ICE        March 2012

1.  Introduction

   When Interactive Connectivity Establishment (ICE) [RFC5245]
   [I-D.ietf-mmusic-ice-tcp] is used for NAT traversal, both endpoints
   gather multiple IP addresses and ports, also called candidate
   addresses, and test for connectivity between them.  One of the
   principles of ICE is to gather all possible candidate addresses and
   pair them with all the addresses of the peer in order to test all
   combinations and get high probability for successful NAT traversal.

   A prioritization formula is used by ICE so that most preferred
   address pairs are tested first, and if a sufficiently good pair is
   discovered, the tests can be stopped.  Addresses obtained from local
   network interfaces, called host candidates, are recommended as high-
   priority ones to be tested first since if they work, they provide
   usually the best path between the two hosts.  With IPv4 this approach
   works well since interfaces usually have just a single unicast IP
   address.  However, with IPv6 addressing architecture [RFC4291]
   interfaces commonly have multiple addresses: global, link-local,
   Unique Local (ULA) [RFC4193], etc.

   The ICE specification recommends to use the rules defined in
   [RFC3484] as part of the prioritization formula for IPv6 candidates,
   but does not give much further advice on how to handle different kind
   of IPv6 addresses.  However, if all different kind of IPv6 addresses
   are paired with each other, some of the combinations will never work
   and may unnecessarily delay the completion of the ICE process.

   This document updates the ICE rules defined in [RFC5245] and
   [I-D.ietf-mmusic-ice-tcp] on how candidate addresses are selected and
Show full document text