draft-ietf-mmusic-rfc5245bis-03.txt   draft-ietf-mmusic-rfc5245bis-04.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: April 29, 2015 October 26, 2014 Expires: September 10, 2015 March 9, 2015
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-03 draft-ietf-mmusic-rfc5245bis-04
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 29, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 42 skipping to change at page 2, line 42
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 13
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 13
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 15
2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15 2.8. Usages of ICE . . . . . . . . . . . . . . . . . . . . . . 15
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19
4.1. Full Implementation Requirements . . . . . . . . . . . . 19 4.1. Full Implementation Requirements . . . . . . . . . . . . 19
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21 4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 22
4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23 Preferences . . . . . . . . . . . . . . . . . . . 24
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 24 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 25
4.2. Lite Implementation Requirements . . . . . . . . . . . . 25 4.2. Lite Implementation Requirements . . . . . . . . . . . . 25
4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 26 4.3. Encoding the Offer . . . . . . . . . . . . . . . . . . . 26
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30
5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 29 5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 30
5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 30
5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30 5.6.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 30
5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 33 5.6.2. Computing Pair Priority and Ordering Pairs . . . . . 33
5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 5.6.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33
5.6.4. Computing States . . . . . . . . . . . . . . . . . . 33 5.6.4. Computing States . . . . . . . . . . . . . . . . . . 33
5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 5.7. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 38 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 38
skipping to change at page 5, line 5 skipping to change at page 5, line 5
19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . 75
19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76
19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 76
19.4. Requirements for a Long-Term Solution . . . . . . . . . 77 19.4. Requirements for a Long-Term Solution . . . . . . . . . 77
19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 78 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 78
20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78 20. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 78
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
22.1. Normative References . . . . . . . . . . . . . . . . . . 79 22.1. Normative References . . . . . . . . . . . . . . . . . . 79
22.2. Informative References . . . . . . . . . . . . . . . . . 79 22.2. Informative References . . . . . . . . . . . . . . . . . 79
Appendix A. Lite and Full Implementations . . . . . . . . . . . 81 Appendix A. Lite and Full Implementations . . . . . . . . . . . 82
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 83 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 83
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84
B.3. Purpose of the Related Address and Related Port B.3. Purpose of the Related Address and Related Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . 86 Attributes . . . . . . . . . . . . . . . . . . . . . . . 86
B.4. Importance of the STUN Username . . . . . . . . . . . . . 86 B.4. Importance of the STUN Username . . . . . . . . . . . . . 86
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88
B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88
B.8. Why Are Binding Indications Used for Keepalives? . . . . 89 B.8. Why Are Binding Indications Used for Keepalives? . . . . 89
skipping to change at page 19, line 48 skipping to change at page 19, line 48
address that the host has, with the exceptions listed below. The address that the host has, with the exceptions listed below. The
agent obtains each candidate by binding to a UDP port on the specific agent obtains each candidate by binding to a UDP port on the specific
IP address. A host candidate (and indeed every candidate) is always IP address. A host candidate (and indeed every candidate) is always
associated with a specific component for which it is a candidate. associated with a specific component for which it is a candidate.
Each component has an ID assigned to it, called the component ID. Each component has an ID assigned to it, called the component ID.
For RTP-based media streams, the RTP itself has a component ID of 1, For RTP-based media streams, the RTP itself has a component ID of 1,
and RTCP a component ID of 2. If an agent is using RTCP, it MUST and RTCP a component ID of 2. If an agent is using RTCP, it MUST
obtain a candidate for it. If an agent is using both RTP and RTCP, obtain a candidate for it. If an agent is using both RTP and RTCP,
it would end up with 2*K host candidates if an agent has K IP it would end up with 2*K host candidates if an agent has K IP
addresses. For other than RTP-based streams, if multiple components addresses.
are needed, the component IDs SHOULD start with 1 and increase by 1
for each component. For other than RTP-based streams, use of multiple components is
discouraged since using them increases the complexity of ICE
processing. If multiple components are needed, the component IDs
SHOULD start with 1 and increase by 1 for each component.
The base for each host candidate is set to the candidate itself. The base for each host candidate is set to the candidate itself.
The host candidates are gathered from all IP addresses with the The host candidates are gathered from all IP addresses with the
following exceptions: following exceptions:
o Addresses from a loopback interface MUST NOT be included in the o Addresses from a loopback interface MUST NOT be included in the
candidate addresses. candidate addresses.
o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-
local unicast addresses [RFC3879] MUST NOT be included in the local unicast addresses [RFC3879] MUST NOT be included in the
address candidates. address candidates.
o IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered o IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered
candidates unless the application using ICE does not support IPv4 candidates unless the application using ICE does not support IPv4
(i.e., is an IPv6-only application [RFC4038]). (i.e., is an IPv6-only application [RFC4038]).
o If one or more host candidates corresponding to an IPv6 address
generated using a mechanism that prevents location tracking
[I-D.ietf-6man-ipv6-address-generation-privacy] are gathered, host
candidates corresponding to IPv6 addresses that do allow location
tracking, that are configured on the same interface, and are part
of the same network prefix MUST NOT be gathered; and host
candidates corresponding to IPv6 link-local addresses MUST NOT be
gathered.
4.1.1.2. Server Reflexive and Relayed Candidates 4.1.1.2. Server Reflexive and Relayed Candidates
Agents SHOULD obtain relayed candidates and SHOULD obtain server Agents SHOULD obtain relayed candidates and SHOULD obtain server
reflexive candidates. These requirements are at SHOULD strength to reflexive candidates. These requirements are at SHOULD strength to
allow for provider variation. Use of STUN and TURN servers may be allow for provider variation. Use of STUN and TURN servers may be
unnecessary in closed networks where agents are never connected to unnecessary in closed networks where agents are never connected to
the public Internet or to endpoints outside of the closed network. the public Internet or to endpoints outside of the closed network.
In such cases, a full implementation would be used for agents that In such cases, a full implementation would be used for agents that
are dual-stack or multihomed, to select a host candidate. Use of are dual-stack or multihomed, to select a host candidate. Use of
TURN servers is expensive, and when ICE is being used, they will only TURN servers is expensive, and when ICE is being used, they will only
skipping to change at page 78, line 52 skipping to change at page 78, line 52
the obsoleted RFC 3483 and using address preferences provided by the obsoleted RFC 3483 and using address preferences provided by
the host operating system is recommended. the host operating system is recommended.
o Candidate gathering rules regarding loopback addresses and IPv6 o Candidate gathering rules regarding loopback addresses and IPv6
addresses were clarified. addresses were clarified.
21. Acknowledgements 21. Acknowledgements
Most of the text in this document comes from the original ICE Most of the text in this document comes from the original ICE
specification, RFC 5245. The authors would like to thank everyone specification, RFC 5245. The authors would like to thank everyone
who has contributed to that document. who has contributed to that document. For additional contributions
to this revision of the specification we would like to thank Christer
Holmberg, Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon
Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin
Thomson, and Justin Uberti.
22. References 22. References
22.1. Normative References 22.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
skipping to change at page 81, line 44 skipping to change at page 81, line 51
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.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M. and A. Keranen, "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-ietf-mmusic-ice-sip-sdp-03 (work in Protocol (SIP)", draft-ietf-mmusic-ice-sip-sdp-04 (work in
progress), July 2014. progress), October 2014.
[I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-04 (work
in progress), February 2015.
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.
Because ICE requires both endpoints to support it in order to bring Because ICE requires both endpoints to support it in order to bring
 End of changes. 13 change blocks. 
17 lines changed or deleted 39 lines changed or added

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