draft-ietf-mmusic-rfc5245bis-00.txt   draft-ietf-mmusic-rfc5245bis-01.txt 
MMUSIC A. Keranen MMUSIC A. Keranen
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 5245 (if approved) J. Rosenberg Obsoletes: 5245 (if approved) J. Rosenberg
Intended status: Standards Track jdrosen.net Intended status: Standards Track jdrosen.net
Expires: January 16, 2014 July 15, 2013 Expires: July 19, 2014 January 15, 2014
Interactive Connectivity Establishment (ICE): A Protocol for Network Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-rfc5245bis-00 draft-ietf-mmusic-rfc5245bis-01
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia sessions established with (NAT) traversal for UDP-based multimedia sessions established with
the offer/answer model. This protocol is called Interactive the offer/answer model. This protocol is called Interactive
Connectivity Establishment (ICE). ICE makes use of the Session Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Utilities for NAT (STUN) protocol and its extension,
Traversal Using Relay NAT (TURN). ICE can be used by any protocol Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation utilizing the offer/answer model, such as the Session Initiation
Protocol (SIP). Protocol (SIP).
This document obsoletes RFC 5245. This document obsoletes RFC 5245.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on July 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 26
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 8
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 12 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 11
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 12
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 14 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . . 16 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15
2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 16 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 18
4.1. Full Implementation Requirements . . . . . . . . . . . . . 20 4.1. Full Implementation Requirements . . . . . . . . . . . . 19
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . . 20 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 22 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21
4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . . 23 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 23 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 24 Preferences . . . . . . . . . . . . . . . . . . . 23
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . . 25 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 24
4.2. Lite Implementation Requirements . . . . . . . . . . . . . 25 4.2. Lite Implementation Requirements . . . . . . . . . . . . 24
4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . . 26 4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 25
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 29 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . . 30 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29
5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 30 5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 29
5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 29
5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30 5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29
5.6.2. Computing Pair Priority and Ordering Pairs . . . . . . 33 5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 32
5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 32
5.6.4. Computing States . . . . . . . . . . . . . . . . . . . 33 5.6.4. Computing States . . . . . . . . . . . . . . . . . . 32
5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 35
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 37
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 37
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 38 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 37
6.3. Forming the Check List . . . . . . . . . . . . . . . . . . 38 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 37
6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . . 38 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 37
7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 38 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 37
7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . . 39 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 38
7.1.1. Creating Permissions for Relayed Candidates . . . . . 39 7.1.1. Creating Permissions for Relayed Candidates . . . . . 38
7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 39 7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 38
7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . . 39 7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 38
7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . . 40 7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 39
7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 40 7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 39
7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . . 40 7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 39
7.1.3. Processing the Response . . . . . . . . . . . . . . . 40 7.1.3. Processing the Response . . . . . . . . . . . . . . . 39
7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 41 7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 40
7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 41 7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 40
7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 42 7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 41
7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 42 7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 41
7.1.3.2.3. Updating Pair States . . . . . . . . . . . . . 43 7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 42
7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 44 7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 43
7.1.3.3. Check List and Timer State Updates . . . . . . . . 44 7.1.3.3. Check List and Timer State Updates . . . . . . . 43
7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . . 45 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 44
7.2.1. Additional Procedures for Full Implementations . . . . 46 7.2.1. Additional Procedures for Full Implementations . . . 45
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . . 46 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 45
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . . 47 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 46
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . . 47 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 46
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . . 48 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 47
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 48
7.2.2. Additional Procedures for Lite Implementations . . . . 49 7.2.2. Additional Procedures for Lite Implementations . . . 48
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 49
8.1. Procedures for Full Implementations . . . . . . . . . . . 50 8.1. Procedures for Full Implementations . . . . . . . . . . . 49
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . 50 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 49
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . . 50 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 49
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 50
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 50
8.2. Procedures for Lite Implementations . . . . . . . . . . . 53 8.2. Procedures for Lite Implementations . . . . . . . . . . . 52
8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . . 53 8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 52
8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . . 53 8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 52
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . . 54 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 53
8.3.1. Full Implementation Procedures . . . . . . . . . . . . 54 8.3.1. Full Implementation Procedures . . . . . . . . . . . 53
8.3.2. Lite Implementation Procedures . . . . . . . . . . . . 54 8.3.2. Lite Implementation Procedures . . . . . . . . . . . 53
9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 55 10. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 55 10.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 55
10.1.1. Procedures for Full Implementations . . . . . . . . . 55 10.1.1. Procedures for Full Implementations . . . . . . . . 55
10.1.2. Procedures for Lite Implementations . . . . . . . . . 56 10.1.2. Procedures for Lite Implementations . . . . . . . . 55
10.1.3. Procedures for All Implementations . . . . . . . . . . 56 10.1.3. Procedures for All Implementations . . . . . . . . . 56
10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 57 10.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 56
11. Extensibility Considerations . . . . . . . . . . . . . . . . . 57 11. Extensibility Considerations . . . . . . . . . . . . . . . . 56
12. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . . 58 12. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 57
12.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . . 58 12.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . 58
12.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . . 60 12.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 59
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
14. Security Considerations . . . . . . . . . . . . . . . . . . . 65 14. Security Considerations . . . . . . . . . . . . . . . . . . . 64
14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 66 14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 65
14.2. Attacks on Server Reflexive Address Gathering . . . . . . 68 14.2. Attacks on Server Reflexive Address Gathering . . . . . 67
14.3. Attacks on Relayed Candidate Gathering . . . . . . . . . . 69 14.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 68
14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 69 14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . 68
14.4.1. STUN Amplification Attack . . . . . . . . . . . . . . 69 14.4.1. STUN Amplification Attack . . . . . . . . . . . . . 69
15. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 70 15. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 69
15.1. New Attributes . . . . . . . . . . . . . . . . . . . . . . 70 15.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 69
15.2. New Error Response Codes . . . . . . . . . . . . . . . . . 71 15.2. New Error Response Codes . . . . . . . . . . . . . . . . 70
16. Operational Considerations . . . . . . . . . . . . . . . . . . 71 16. Operational Considerations . . . . . . . . . . . . . . . . . 70
16.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . . 71 16.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 70
16.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . . 71 16.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 71
16.2.1. STUN and TURN Server Capacity Planning . . . . . . . . 72 16.2.1. STUN and TURN Server Capacity Planning . . . . . . . 71
16.2.2. Gathering and Connectivity Checks . . . . . . . . . . 72 16.2.2. Gathering and Connectivity Checks . . . . . . . . . 71
16.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . 73 16.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 72
16.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . . 73 16.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 72
16.4. Troubleshooting and Performance Management . . . . . . . . 73 16.4. Troubleshooting and Performance Management . . . . . . . 72
16.5. Endpoint Configuration . . . . . . . . . . . . . . . . . . 74 16.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 73
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
17.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 74 17.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 73
17.2. STUN Error Responses . . . . . . . . . . . . . . . . . . . 74 17.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 73
18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 74 18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73
18.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 75 18.1. Problem Definition . . . . . . . . . . . . . . . . . . . 74
18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 75 18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 74
18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 76 18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 75
18.4. Requirements for a Long-Term Solution . . . . . . . . . . 77 18.4. Requirements for a Long-Term Solution . . . . . . . . . 76
18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 77 18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 76
19. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 77 19. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 76
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
21.1. Normative References . . . . . . . . . . . . . . . . . . . 78 21.1. Normative References . . . . . . . . . . . . . . . . . . 77
21.2. Informative References . . . . . . . . . . . . . . . . . . 78 21.2. Informative References . . . . . . . . . . . . . . . . . 77
Appendix A. Lite and Full Implementations . . . . . . . . . . . . 81
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 82 Appendix A. Lite and Full Implementations . . . . . . . . . . . 80
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 82 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 81
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . . 83 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 81
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 82
B.3. Purpose of the Related Address and Related Port B.3. Purpose of the Related Address and Related Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 85 Attributes . . . . . . . . . . . . . . . . . . . . . . . 84
B.4. Importance of the STUN Username . . . . . . . . . . . . . 85 B.4. Importance of the STUN Username . . . . . . . . . . . . . 84
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 86 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 85
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . . 87 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 86
B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 87 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 86
B.8. Why Are Binding Indications Used for Keepalives? . . . . . 88 B.8. Why Are Binding Indications Used for Keepalives? . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
RFC 3264 [RFC3264] defines a two-phase exchange of Session RFC 3264 [RFC3264] defines a two-phase exchange of Session
Description Protocol (SDP) messages [RFC4566] for the purposes of Description Protocol (SDP) messages [RFC4566] for the purposes of
establishment of multimedia sessions. This offer/answer mechanism is establishment of multimedia sessions. This offer/answer mechanism is
used by protocols such as the Session Initiation Protocol (SIP) used by protocols such as the Session Initiation Protocol (SIP)
[RFC3261]. [RFC3261].
Protocols using offer/answer are difficult to operate through Network Protocols using offer/answer are difficult to operate through Network
skipping to change at page 8, line 5 skipping to change at page 7, line 5
properties are also unknown. Agents L and R are capable of engaging properties are also unknown. Agents L and R are capable of engaging
in an offer/answer exchange, whose purpose is to set up a media in an offer/answer exchange, whose purpose is to set up a media
session between L and R. Typically, this exchange will occur through session between L and R. Typically, this exchange will occur through
a signaling (e.g., SIP) server. a signaling (e.g., SIP) server.
In addition to the agents, a signaling server and NATs, ICE is In addition to the agents, a signaling server and NATs, ICE is
typically used in concert with STUN or TURN servers in the network. typically used in concert with STUN or TURN servers in the network.
Each agent can have its own STUN or TURN server, or they can be the Each agent can have its own STUN or TURN server, or they can be the
same. same.
+---------+ +---------+
+--------+ |Signaling| +--------+ +--------+ |Signaling| +--------+
| STUN | |Server | | STUN | | STUN | |Server | | STUN |
| Server | +---------+ | Server | | Server | +---------+ | Server |
+--------+ / \ +--------+ +--------+ / \ +--------+
/ \ / \
/ \ / \
/ <- Signaling -> \ / <- Signaling -> \
/ \ / \
+--------+ +--------+ +--------+ +--------+
| NAT | | NAT | | NAT | | NAT |
+--------+ +--------+ +--------+ +--------+
/ \ / \
/ \ / \
+-------+ +-------+ +-------+ +-------+
| Agent | | Agent | | Agent | | Agent |
| L | | R | | L | | R |
+-------+ +-------+ +-------+ +-------+
Figure 1: ICE Deployment Scenario Figure 1: ICE Deployment Scenario
The basic idea behind ICE is as follows: each agent has a variety of The basic idea behind ICE is as follows: each agent has a variety of
candidate TRANSPORT ADDRESSES (combination of IP address and port for candidate TRANSPORT ADDRESSES (combination of IP address and port for
a particular transport protocol, which is always UDP in this a particular transport protocol, which is always UDP in this
specification) it could use to communicate with the other agent. specification) it could use to communicate with the other agent.
These might include: These might include:
o A transport address on a directly attached network interface o A transport address on a directly attached network interface
skipping to change at page 10, line 38 skipping to change at page 9, line 38
| | | |
| Agent | | Agent |
| | | |
+--------+ +--------+
Figure 2: Candidate Relationships Figure 2: Candidate Relationships
When the agent sends the TURN Allocate request from IP address and When the agent sends the TURN Allocate request from IP address and
port X:x, the NAT (assuming there is one) will create a binding port X:x, the NAT (assuming there is one) will create a binding
X1':x1', mapping this server reflexive candidate to the host X1':x1', mapping this server reflexive candidate to the host
candidate X:x. Outgoing packets sent from the host candidate will be candidate X:x. Outgoing packets sent from the host candidate will be
translated by the NAT to the server reflexive candidate. Incoming translated by the NAT to the server reflexive candidate. Incoming
packets sent to the server reflexive candidate will be translated by packets sent to the server reflexive candidate will be translated by
the NAT to the host candidate and forwarded to the agent. We call the NAT to the host candidate and forwarded to the agent. We call
the host candidate associated with a given server reflexive candidate the host candidate associated with a given server reflexive candidate
the BASE. the BASE.
Note: "Base" refers to the address an agent sends from for a Note: "Base" refers to the address an agent sends from for a
particular candidate. Thus, as a degenerate case host candidates particular candidate. Thus, as a degenerate case host candidates
also have a base, but it's the same as the host candidate. also have a base, but it's the same as the host candidate.
skipping to change at page 12, line 5 skipping to change at page 11, line 5
1. Sort the candidate pairs in priority order. 1. Sort the candidate pairs in priority order.
2. Send checks on each candidate pair in priority order. 2. Send checks on each candidate pair in priority order.
3. Acknowledge checks received from the other agent. 3. Acknowledge checks received from the other agent.
With both agents performing a check on a candidate pair, the result With both agents performing a check on a candidate pair, the result
is a 4-way handshake: is a 4-way handshake:
L R L R
- - - -
STUN request -> \ L's STUN request -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
Figure 3: Basic Connectivity Check Figure 3: Basic Connectivity Check
It is important to note that the STUN requests are sent to and from It is important to note that the STUN requests are sent to and from
the exact same IP addresses and ports that will be used for media the exact same IP addresses and ports that will be used for media
(e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/
RTCP using contents of the packets, rather than the port on which RTCP using contents of the packets, rather than the port on which
they are received. Fortunately, this demultiplexing is easy to do, they are received. Fortunately, this demultiplexing is easy to do,
especially for RTP and RTCP. especially for RTP and RTCP.
skipping to change at page 15, line 9 skipping to change at page 14, line 9
used for media amongst the ones that are valid. It can do this in used for media amongst the ones that are valid. It can do this in
one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION. one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION.
With regular nomination, the controlling agent lets the checks With regular nomination, the controlling agent lets the checks
continue until at least one valid candidate pair for each media continue until at least one valid candidate pair for each media
stream is found. Then, it picks amongst those that are valid, and stream is found. Then, it picks amongst those that are valid, and
sends a second STUN request on its NOMINATED candidate pair, but this sends a second STUN request on its NOMINATED candidate pair, but this
time with a flag set to tell the peer that this pair has been time with a flag set to tell the peer that this pair has been
nominated for use. This is shown in Figure 4. nominated for use. This is shown in Figure 4.
L R L R
- - - -
STUN request -> \ L's STUN request -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
STUN request + flag -> \ L's STUN request + flag -> \ L's
<- STUN response / check <- STUN response / check
Figure 4: Regular Nomination Figure 4: Regular Nomination
Once the STUN transaction with the flag completes, both sides cancel Once the STUN transaction with the flag completes, both sides cancel
any future checks for that media stream. ICE will now send media any future checks for that media stream. ICE will now send media
using this pair. The pair an ICE agent is using for media is called using this pair. The pair an ICE agent is using for media is called
the SELECTED PAIR. the SELECTED PAIR.
In aggressive nomination, the controlling agent puts the flag in In aggressive nomination, the controlling agent puts the flag in
every connectivity check STUN request it sends. This way, once the every connectivity check STUN request it sends. This way, once the
first check succeeds, ICE processing is complete for that media first check succeeds, ICE processing is complete for that media
stream and the controlling agent doesn't have to send a second STUN stream and the controlling agent doesn't have to send a second STUN
request. The selected pair will be the highest-priority valid pair request. The selected pair will be the highest-priority valid pair
whose check succeeded. Aggressive nomination is faster than regular whose check succeeded. Aggressive nomination is faster than regular
nomination, but gives less flexibility. Aggressive nomination is nomination, but gives less flexibility. Aggressive nomination is
shown in Figure 5. shown in Figure 5.
L R L R
- - - -
STUN request + flag -> \ L's STUN request + flag -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
Figure 5: Aggressive Nomination Figure 5: Aggressive Nomination
Once ICE is concluded, it can be restarted at any time for one or all Once ICE is concluded, it can be restarted at any time for one or all
of the media streams by either agent. This is done by sending an of the media streams by either agent. This is done by sending an
updated offer indicating a restart. updated offer indicating a restart.
2.7. Lite Implementations 2.7. Lite Implementations
In order for ICE to be used in a call, both agents need to support In order for ICE to be used in a call, both agents need to support
skipping to change at page 32, line 5 skipping to change at page 31, line 5
default candidates for a particular component is called, default candidates for a particular component is called,
unsurprisingly, the default candidate pair for that component. This unsurprisingly, the default candidate pair for that component. This
is the pair that would be used to transmit media if both agents had is the pair that would be used to transmit media if both agents had
not been ICE aware. not been ICE aware.
In order to aid understanding, Figure 6 shows the relationships In order to aid understanding, Figure 6 shows the relationships
between several key concepts -- transport addresses, candidates, between several key concepts -- transport addresses, candidates,
candidate pairs, and check lists, in addition to indicating the main candidate pairs, and check lists, in addition to indicating the main
properties of candidates and candidate pairs. properties of candidates and candidate pairs.
+------------------------------------------+ +------------------------------------------+
| | | |
| +---------------------+ | | +---------------------+ |
| |+----+ +----+ +----+ | +Type | | |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority | | || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation | | ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD | | |+----+ +----+ +----+ | +ComponentiD |
| | Transport | +RelatedAddr | | | Transport | +RelatedAddr |
| | Addr | | | | Addr | |
| +---------------------+ +Base | | +---------------------+ +Base |
| Candidate | | Candidate |
+------------------------------------------+ +------------------------------------------+
* * * *
* ************************************* * *************************************
* * * *
+-------------------------------+ +-------------------------------+
.| | .| |
| Local Remote | | Local Remote |
| +----+ +----+ +default? | | +----+ +----+ +default? |
| |Cand| |Cand| +valid? | | |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?| | +----+ +----+ +nominated?|
| +State | | +State |
| | | |
| | | |
| Candidate Pair | | Candidate Pair |
+-------------------------------+ +-------------------------------+
* * * *
* ************ * ************
* * * *
+------------------+ +------------------+
| Candidate Pair | | Candidate Pair |
+------------------+ +------------------+
+------------------+ +------------------+
| Candidate Pair | | Candidate Pair |
+------------------+ +------------------+
+------------------+ +------------------+
| Candidate Pair | | Candidate Pair |
+------------------+ +------------------+
Check Check
List List
Figure 6: Conceptual Diagram of a Check List Figure 6: Conceptual Diagram of a Check List
5.6.2. Computing Pair Priority and Ordering Pairs 5.6.2. Computing Pair Priority and Ordering Pairs
Once the pairs are formed, a candidate pair priority is computed. Once the pairs are formed, a candidate pair priority is computed.
Let G be the priority for the candidate provided by the controlling Let G be the priority for the candidate provided by the controlling
agent. Let D be the priority for the candidate provided by the agent. Let D be the priority for the candidate provided by the
controlled agent. The priority for a pair is computed as: controlled agent. The priority for a pair is computed as:
skipping to change at page 35, line 5 skipping to change at page 34, line 5
Failed: A check for this pair was already done and failed, either Failed: A check for this pair was already done and failed, either
never producing any response or producing an unrecoverable failure never producing any response or producing an unrecoverable failure
response. response.
Frozen: A check for this pair hasn't been performed, and it can't Frozen: A check for this pair hasn't been performed, and it can't
yet be performed until some other check succeeds, allowing this yet be performed until some other check succeeds, allowing this
pair to unfreeze and move into the Waiting state. pair to unfreeze and move into the Waiting state.
As ICE runs, the pairs will move between states as shown in Figure 7. As ICE runs, the pairs will move between states as shown in Figure 7.
+-----------+ +-----------+
| | | |
| | | |
| Frozen | | Frozen |
| | | |
| | | |
+-----------+ +-----------+
| |
|unfreeze |unfreeze
| |
V V
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
| | perform | | | | perform | |
| Waiting |-------->|In-Progress| | Waiting |-------->|In-Progress|
| | | | | | | |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
/ | / |
// | // |
// | // |
// | // |
/ | / |
// | // |
failure // |success failure // |success
// | // |
/ | / |
// | // |
// | // |
// | // |
V V V V
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
| | | | | | | |
| Failed | | Succeeded | | Failed | | Succeeded |
| | | | | | | |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 7: Pair State FSM Figure 7: Pair State FSM
The initial states for each pair in a check list are computed by The initial states for each pair in a check list are computed by
performing the following sequence of steps: performing the following sequence of steps:
1. The agent sets all of the pairs in each check list to the Frozen 1. The agent sets all of the pairs in each check list to the Frozen
state. state.
2. The agent examines the check list for the first media stream. 2. The agent examines the check list for the first media stream.
skipping to change at page 36, line 32 skipping to change at page 35, line 32
Running: In this state, ICE checks are still in progress for this Running: In this state, ICE checks are still in progress for this
media stream. media stream.
Completed: In this state, ICE checks have produced nominated pairs Completed: In this state, ICE checks have produced nominated pairs
for each component of the media stream. Consequently, ICE has for each component of the media stream. Consequently, ICE has
succeeded and media can be sent. succeeded and media can be sent.
Failed: In this state, the ICE checks have not completed Failed: In this state, the ICE checks have not completed
successfully for this media stream. successfully for this media stream.
When a check list is first constructed as the consequence of an When a check list is first constructed as the consequence of an offer
offer/answer exchange, it is placed in the Running state. /answer exchange, it is placed in the Running state.
ICE processing across all media streams also has a state associated ICE processing across all media streams also has a state associated
with it. This state is equal to Running while ICE processing is with it. This state is equal to Running while ICE processing is
under way. The state is Completed when ICE processing is complete under way. The state is Completed when ICE processing is complete
and Failed if it failed without success. Rules for transitioning and Failed if it failed without success. Rules for transitioning
between states are described below. between states are described below.
5.7. Scheduling Checks 5.7. Scheduling Checks
Checks are generated only by full implementations. Lite Checks are generated only by full implementations. Lite
skipping to change at page 51, line 27 skipping to change at page 50, line 27
its nominated flag set. When all components have a nominated pair in its nominated flag set. When all components have a nominated pair in
the valid list, media can begin to flow using the highest-priority the valid list, media can begin to flow using the highest-priority
nominated pair. However, because the agent included the USE- nominated pair. However, because the agent included the USE-
CANDIDATE attribute in all of its checks, another check may yet CANDIDATE attribute in all of its checks, another check may yet
complete, causing another valid pair to have its nominated flag set. complete, causing another valid pair to have its nominated flag set.
ICE always selects the highest-priority nominated candidate pair from ICE always selects the highest-priority nominated candidate pair from
the valid list as the one used for media. Consequently, the selected the valid list as the one used for media. Consequently, the selected
pair may actually change briefly as ICE checks complete, resulting in pair may actually change briefly as ICE checks complete, resulting in
a set of transient selections until it stabilizes. a set of transient selections until it stabilizes.
If certain connectivity check messages are lost, ICE agents using
aggressive nomination may end up with different views on the selected
candidate pair. In this case, if a security protocol that is able to
authenticate the communicating parties (e.g., DTLS) is used, the
controlled agent may receive valid secured traffic or handshake
initialization originating from the controlling agent on a candidate
pair that is different from the one the controlled agent considers as
the selected pair. If this happens, the controlled agent MUST
consider the pair with the secured traffic as the correct selected
pair. If such security protocol is not used, both agents SHOULD
continue sending connectivity check messages on the selected pair
even after a pair has already been selected for use. In order to
prevent the problem described here, at least one check from both
agents needs to fully succeed on the selected pair.
8.1.2. Updating States 8.1.2. Updating States
For both controlling and controlled agents, the state of ICE For both controlling and controlled agents, the state of ICE
processing depends on the presence of nominated candidate pairs in processing depends on the presence of nominated candidate pairs in
the valid list and on the state of the check list. Note that, at any the valid list and on the state of the check list. Note that, at any
time, more than one of the following cases can apply: time, more than one of the following cases can apply:
o If there are no nominated pairs in the valid list for a media o If there are no nominated pairs in the valid list for a media
stream and the state of the check list is Running, ICE processing stream and the state of the check list is Running, ICE processing
continues. continues.
skipping to change at page 66, line 13 skipping to change at page 65, line 20
offer or answer. offer or answer.
14.1. Attacks on Connectivity Checks 14.1. Attacks on Connectivity Checks
An attacker might attempt to disrupt the STUN connectivity checks. An attacker might attempt to disrupt the STUN connectivity checks.
Ultimately, all of these attacks fool an agent into thinking Ultimately, all of these attacks fool an agent into thinking
something incorrect about the results of the connectivity checks. something incorrect about the results of the connectivity checks.
The possible false conclusions an attacker can try and cause are: The possible false conclusions an attacker can try and cause are:
False Invalid: An attacker can fool a pair of agents into thinking a False Invalid: An attacker can fool a pair of agents into thinking a
candidate pair is invalid, when it isn't. This can be used to candidate pair is invalid, when it isn't. This can be used to
cause an agent to prefer a different candidate (such as one cause an agent to prefer a different candidate (such as one
injected by the attacker) or to disrupt a call by forcing all injected by the attacker) or to disrupt a call by forcing all
candidates to fail. candidates to fail.
False Valid: An attacker can fool a pair of agents into thinking a False Valid: An attacker can fool a pair of agents into thinking a
candidate pair is valid, when it isn't. This can cause an agent candidate pair is valid, when it isn't. This can cause an agent to
to proceed with a session, but then not be able to receive any proceed with a session, but then not be able to receive any media.
media.
False Peer Reflexive Candidate: An attacker can cause an agent to False Peer Reflexive Candidate: An attacker can cause an agent to
discover a new peer reflexive candidate, when it shouldn't have. discover a new peer reflexive candidate, when it shouldn't have.
This can be used to redirect media streams to a Denial-of-Service This can be used to redirect media streams to a Denial-of-Service
(DoS) target or to the attacker, for eavesdropping or other (DoS) target or to the attacker, for eavesdropping or other
purposes. purposes.
False Valid on False Candidate: An attacker has already convinced an False Valid on False Candidate: An attacker has already convinced an
agent that there is a candidate with an address that doesn't agent that there is a candidate with an address that doesn't
actually route to that agent (for example, by injecting a false actually route to that agent (for example, by injecting a false
skipping to change at page 74, line 35 skipping to change at page 73, line 40
0x0024 PRIORITY 0x0024 PRIORITY
0x0025 USE-CANDIDATE 0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED 0x8029 ICE-CONTROLLED
0x802A ICE-CONTROLLING 0x802A ICE-CONTROLLING
17.2. STUN Error Responses 17.2. STUN Error Responses
IANA has registered following STUN error response code: IANA has registered following STUN error response code:
487 Role Conflict: The client asserted an ICE role (controlling or 487 Role Conflict: The client asserted an ICE role (controlling or
controlled) that is in conflict with the role of the server. controlled) that is in conflict with the role of the server.
18. IAB Considerations 18. IAB Considerations
The IAB has studied the problem of "Unilateral Self-Address Fixing", The IAB has studied the problem of "Unilateral Self-Address Fixing",
which is the general process by which a agent attempts to determine which is the general process by which a agent attempts to determine
its address in another realm on the other side of a NAT through a its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [RFC3424]. ICE is an collaborative protocol reflection mechanism [RFC3424]. ICE is an
example of a protocol that performs this type of function. example of a protocol that performs this type of function.
Interestingly, the process for ICE is not unilateral, but bilateral, Interestingly, the process for ICE is not unilateral, but bilateral,
and the difference has a significant impact on the issues raised by and the difference has a significant impact on the issues raised by
skipping to change at page 78, line 41 skipping to change at page 77, line 44
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
21.2. Informative References 21.2. Informative References
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605, October
October 2003. 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
skipping to change at page 79, line 32 skipping to change at page 78, line 34
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC 3103, "Realm Specific IP: Protocol Specification", RFC 3103,
October 2001. October 2001.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition", RFC
RFC 4038, March 2005. 4038, March 2005.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session
Description Protocol (SDP) Alternative Network Address Description Protocol (SDP) Alternative Network Address
Types (ANAT) Semantics in the Session Initiation Protocol Types (ANAT) Semantics in the Session Initiation Protocol
(SIP)", RFC 4092, June 2005. (SIP)", RFC 4092, June 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
and E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets", BCP
BCP 5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP", draft-
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery", RFC
RFC 6080, March 2011. 6080, March 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[I-D.petithuguenin-mmusic-ice-sip-sdp] [I-D.petithuguenin-mmusic-ice-sip-sdp]
Petit-Huguenin, M. and A. Keraenen, "Using Interactive Petit-Huguenin, M. and A. Keranen, "Using Interactive
Connectivity Establishment (ICE) with Session Description Connectivity Establishment (ICE) with Session Description
Protocol (SDP) offer/answer and Session Initiation Protocol (SDP) offer/answer and Session Initiation
Protocol (SIP)", draft-petithuguenin-mmusic-ice-sip-sdp-00 Protocol (SIP)", draft-petithuguenin-mmusic-ice-sip-sdp-01
(work in progress), February 2013. (work in progress), February 2013.
Appendix A. Lite and Full Implementations Appendix A. Lite and Full Implementations
ICE allows for two types of implementations. A full implementation ICE allows for two types of implementations. A full implementation
supports the controlling and controlled roles in a session, and can supports the controlling and controlled roles in a session, and can
also perform address gathering. In contrast, a lite implementation also perform address gathering. In contrast, a lite implementation
is a minimalist implementation that does little but respond to STUN is a minimalist implementation that does little but respond to STUN
checks. checks.
 End of changes. 34 change blocks. 
278 lines changed or deleted 293 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/