draft-ietf-mmusic-rfc5245bis-04.txt   draft-ietf-mmusic-rfc5245bis-05.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: September 10, 2015 March 9, 2015 Expires: March 13, 2016 September 10, 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
draft-ietf-mmusic-rfc5245bis-04 draft-ietf-mmusic-rfc5245bis-05
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. This protocol is called
the offer/answer model. This protocol is called Interactive Interactive Connectivity Establishment (ICE). ICE makes use of the
Connectivity Establishment (ICE). ICE makes use of the Session Session Traversal Utilities for NAT (STUN) protocol and its
Traversal Utilities for NAT (STUN) protocol and its extension, extension, Traversal Using Relay NAT (TURN).
Traversal Using Relay NAT (TURN). ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation
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 September 10, 2015. This Internet-Draft will expire on March 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 44 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 23
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 24 Preferences . . . . . . . . . . . . . . . . . . . 24
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . 29
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 29 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 30
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30
5.5. Encoding the Answer . . . . . . . . . . . . . . . . . . . 30 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
skipping to change at page 5, line 5 skipping to change at page 4, line 50
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 . . . . . . . . . . . 82 Appendix A. Lite and Full Implementations . . . . . . . . . . . 83
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 83 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 84
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 83 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 84
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 84 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 85
B.3. Purpose of the Related Address and Related Port B.3. Purpose of the Related Address and Related Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . 86 Attributes . . . . . . . . . . . . . . . . . . . . . . . 87
B.4. Importance of the STUN Username . . . . . . . . . . . . . 86 B.4. Importance of the STUN Username . . . . . . . . . . . . . 88
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 87 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 89
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 88 B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 89
B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 88 B.7. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 90
B.8. Why Are Binding Indications Used for Keepalives? . . . . 89 B.8. Why Are Binding Indications Used for Keepalives? . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
RFC 3264 [RFC3264] defines a two-phase exchange of Session Protocols establishing multimedia sessions between peers typically
Description Protocol (SDP) messages [RFC4566] for the purposes of involve exchanging IP addresses and ports for the media sources and
establishment of multimedia sessions. This offer/answer mechanism is sinks. However this poses challenges when operated through Network
used by protocols such as the Session Initiation Protocol (SIP) Address Translators (NATs) [RFC3235]. These protocols also seek to
[RFC3261].
Protocols using offer/answer are difficult to operate through Network
Address Translators (NATs). Because their purpose is to establish a
flow of media packets, they tend to carry the IP addresses and ports
of media sources and sinks within their messages, which is known to
be problematic through NAT [RFC3235]. The protocols also seek to
create a media flow directly between participants, so that there is create a media flow directly between participants, so that there is
no application layer intermediary between them. This is done to no application layer intermediary between them. This is done to
reduce media latency, decrease packet loss, and reduce the reduce media latency, decrease packet loss, and reduce the
operational costs of deploying the application. However, this is operational costs of deploying the application. However, this is
difficult to accomplish through NAT. A full treatment of the reasons difficult to accomplish through NAT. A full treatment of the reasons
for this is beyond the scope of this specification. for this is beyond the scope of this specification.
Numerous solutions have been defined for allowing these protocols to Numerous solutions have been defined for allowing these protocols to
operate through NAT. These include Application Layer Gateways operate through NAT. These include Application Layer Gateways
(ALGs), the Middlebox Control Protocol [RFC3303], the original Simple (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple
skipping to change at page 22, line 7 skipping to change at page 22, line 7
rejected because the server lacks resources to fulfill it, the agent rejected because the server lacks resources to fulfill it, the agent
SHOULD instead send a Binding request to obtain a server reflexive SHOULD instead send a Binding request to obtain a server reflexive
candidate. A Binding response will provide the agent with only a candidate. A Binding response will provide the agent with only a
server reflexive candidate (also obtained from the mapped address). server reflexive candidate (also obtained from the mapped address).
The base of the server reflexive candidate is the host candidate from The base of the server reflexive candidate is the host candidate from
which the Allocate or Binding request was sent. The base of a which the Allocate or Binding request was sent. The base of a
relayed candidate is that candidate itself. If a relayed candidate relayed candidate is that candidate itself. If a relayed candidate
is identical to a host candidate (which can happen in rare cases), is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded. the relayed candidate MUST be discarded.
If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146]
and DNS64 [RFC6147] technologies, it may gather also IPv4 server
reflexive and/or relayed candidates from IPv4-only STUN or TURN
servers. IPv6-only agents SHOULD also utilize IPv6 prefix discovery
[RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and
generate server reflexive candidates for each IPv6-only interface
accordingly. The NAT64 server reflexive candidates are prioritized
like IPv4 server reflexive candidates.
4.1.1.3. Computing Foundations 4.1.1.3. Computing Foundations
Finally, the agent assigns each candidate a foundation. The Finally, the agent assigns each candidate a foundation. The
foundation is an identifier, scoped within a session. Two candidates foundation is an identifier, scoped within a session. Two candidates
MUST have the same foundation ID when all of the following are true: MUST have the same foundation ID when all of the following are true:
o they are of the same type (host, relayed, server reflexive, or o they are of the same type (host, relayed, server reflexive, or
peer reflexive) peer reflexive)
o their bases have the same IP address (the ports can be different) o their bases have the same IP address (the ports can be different)
skipping to change at page 79, line 7 skipping to change at page 79, line 7
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. For additional contributions who has contributed to that document. For additional contributions
to this revision of the specification we would like to thank Christer to this revision of the specification we would like to thank Christer
Holmberg, Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon Holmberg, Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon
Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin
Thomson, and Justin Uberti. Thomson, Justin Uberti, and Suhas Nandakumar.
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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
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,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., 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, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
22.2. Informative References 22.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, October in Session Description Protocol (SDP)", RFC 3605,
2003. DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[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. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[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, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[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. DOI 10.17487/RFC3489, March 2003,
<http://www.rfc-editor.org/info/rfc3489>.
[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,
DOI 10.17487/RFC3235, January 2002,
<http://www.rfc-editor.org/info/rfc3235>.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, DOI 10.17487/RFC3303, August 2002,
<http://www.rfc-editor.org/info/rfc3303>.
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001. "Realm Specific IP: Framework", RFC 3102,
DOI 10.17487/RFC3102, October 2001,
<http://www.rfc-editor.org/info/rfc3102>.
[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. DOI 10.17487/RFC3103, October 2001,
<http://www.rfc-editor.org/info/rfc3103>.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
Self-Address Fixing (UNSAF) Across Network Address UNilateral Self-Address Fixing (UNSAF) Across Network
Translation", RFC 3424, November 2002. Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[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", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[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, DOI 10.17487/RFC3056, February
2001, <http://www.rfc-editor.org/info/rfc3056>.
[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, DOI 10.17487/RFC3389,
September 2002, <http://www.rfc-editor.org/info/rfc3389>.
[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, DOI 10.17487/RFC3879, September
2004, <http://www.rfc-editor.org/info/rfc3879>.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and
Castro, "Application Aspects of IPv6 Transition", RFC E. Castro, "Application Aspects of IPv6 Transition",
4038, March 2005. RFC 4038, DOI 10.17487/RFC4038, March 2005,
<http://www.rfc-editor.org/info/rfc4038>.
[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,
DOI 10.17487/RFC4091, June 2005,
<http://www.rfc-editor.org/info/rfc4091>.
[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, DOI 10.17487/RFC4092, June 2005,
<http://www.rfc-editor.org/info/rfc4092>.
[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, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[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, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[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, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", BCP and E. Lear, "Address Allocation for Private Internets",
5, RFC 1918, February 1996. BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, Translation (NAT) Behavioral Requirements for Unicast
RFC 4787, January 2007. UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", draft- Andreasen, F., "A No-Op Payload Format for RTP", 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,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[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, DOI 10.17487/RFC4103, June 2005,
<http://www.rfc-editor.org/info/rfc4103>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Ed., 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, DOI 10.17487/RFC5382, October 2008,
<http://www.rfc-editor.org/info/rfc5382>.
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session [RFC6080] Petrie, D. and S. Channabasappa, Ed., "A Framework for
Initiation Protocol User Agent Profile Delivery", RFC Session Initiation Protocol User Agent Profile Delivery",
6080, March 2011. RFC 6080, DOI 10.17487/RFC6080, March 2011,
<http://www.rfc-editor.org/info/rfc6080>.
[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, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<http://www.rfc-editor.org/info/rfc6147>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>.
[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., Keranen, A., and S. Nandakumar, "Using
Connectivity Establishment (ICE) with Session Description Interactive Connectivity Establishment (ICE) with Session
Protocol (SDP) offer/answer and Session Initiation Description Protocol (SDP) offer/answer and Session
Protocol (SIP)", draft-ietf-mmusic-ice-sip-sdp-04 (work in Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
progress), October 2014. sdp-06 (work in progress), September 2015.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-04 (work draft-ietf-6man-ipv6-address-generation-privacy-07 (work
in progress), February 2015. in progress), June 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. 47 change blocks. 
91 lines changed or deleted 144 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/