draft-ietf-tram-turn-server-discovery-05.txt   draft-ietf-tram-turn-server-discovery-06.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: April 10, 2016 Cisco Expires: July 9, 2016 Cisco
October 8, 2015 January 6, 2016
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-05 draft-ietf-tram-turn-server-discovery-06
Abstract Abstract
Current Traversal Using Relays around NAT (TURN) server discovery Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control of configuration. These are usually under the administrative control of
the application or TURN service provider, and not the enterprise, the application or TURN service provider, and not the enterprise,
ISP, or the network in which the client is located. Enterprises and ISP, or the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal mechanisms that a TURN client could use with no or minimal
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 10, 2016. This Internet-Draft will expire on July 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 25 skipping to change at page 2, line 25
4. Discovery using Service Resolution . . . . . . . . . . . . . 4 4. Discovery using Service Resolution . . . . . . . . . . . . . 4
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 4 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 4
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 10 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 10
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14
A.2. Change from draft-ietf-tram-turn-server-discovery-01 to A.2. Change from draft-ietf-tram-turn-server-discovery-01 to
02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
TURN [RFC5766] is a protocol that is often used to improve the TURN [RFC5766] is a protocol that is often used to improve the
connectivity of Peer-to-Peer (P2P) applications (as defined in connectivity of Peer-to-Peer (P2P) applications (as defined in
section 2.7 of [RFC5128]). TURN allows a connection to be section 2.7 of [RFC5128]). TURN allows a connection to be
skipping to change at page 3, line 29 skipping to change at page 3, line 32
transport addresses from DNS that can be used to create a TURN transport addresses from DNS that can be used to create a TURN
allocation. allocation.
o DNS Service Discovery o DNS Service Discovery
o A mechanism based on anycast address for TURN. o A mechanism based on anycast address for TURN.
In general, if a client wishes to communicate using one of its In general, if a client wishes to communicate using one of its
interfaces using a specific IP address family, it SHOULD query the interfaces using a specific IP address family, it SHOULD query the
TURN server(s) that has been discovered for that specific interface TURN server(s) that has been discovered for that specific interface
and address family. How to select an interface and IP address and address family. How to select an interface and IP address family
family, is out of the scope of this document. is out of the scope of this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Discovery Procedure 3. Discovery Procedure
A TURN client that implements the auto discovery algorithm uses the A TURN client that implements the auto discovery algorithm uses the
skipping to change at page 7, line 24 skipping to change at page 7, line 30
including spaces, punctuation, and non-Latin characters as long as including spaces, punctuation, and non-Latin characters as long as
they can be encoded in UTF-8. they can be encoded in UTF-8.
For example, TURN server advertises the following DNS records : For example, TURN server advertises the following DNS records :
_turnserver._udp.local. PTR example.com._turnserver._udp.local. _turnserver._udp.local. PTR example.com._turnserver._udp.local.
example.com._turnserver._udp.local. SRV 0 0 5030 example-turn- example.com._turnserver._udp.local. SRV 0 0 5030 example-turn-
server.local. server.local.
example-turn-server.local. A 192.168.1.2 example-turn-server.local. A 198.51.100.2
In addition to the service instance name, IP address and the port In addition to the service instance name, IP address and the port
number, DNS-SD provides a way to publish other information pertinent number, DNS-SD provides a way to publish other information pertinent
to the service being advertised. The additional data can be stored to the service being advertised. The additional data can be stored
as name/value attributes in a TXT record with the same name as the as name/value attributes in a TXT record with the same name as the
SRV record for the service. Each name/value pair within the TXT SRV record for the service. Each name/value pair within the TXT
record is preceded by a single length byte, thereby limiting the record is preceded by a single length byte, thereby limiting the
length of the pair to 255 bytes (See Section 6 of [RFC6763] and length of the pair to 255 bytes (See Section 6 of [RFC6763] and
Section 3.3.14 of [RFC1035] for details). Section 3.3.14 of [RFC1035] for details).
skipping to change at page 9, line 14 skipping to change at page 9, line 14
7.1. Mobility and Changing IP addresses 7.1. Mobility and Changing IP addresses
A change of IP address on an interface may invalidate the result of A change of IP address on an interface may invalidate the result of
the TURN server discovery procedure. For instance, if the IP address the TURN server discovery procedure. For instance, if the IP address
assigned to a mobile host changes due to host mobility, it may be assigned to a mobile host changes due to host mobility, it may be
required to re-run the TURN server discovery procedure without required to re-run the TURN server discovery procedure without
relying on earlier gained information. New requests should be made relying on earlier gained information. New requests should be made
to the newly learned TURN servers learned after TURN discovery re- to the newly learned TURN servers learned after TURN discovery re-
run. However, if an earlier learned TURN server is still accessible run. However, if an earlier learned TURN server is still accessible
using the new IP address, procedures described for mobility using using the new IP address, procedures described for mobility using
TURN defined in [I-D.wing-tram-turn-mobility] can be used for ongoing TURN defined in [I-D.ietf-tram-turn-mobility] can be used for ongoing
streams. streams.
7.2. Recursively Encapsulated TURN
A TURN client could attempt to discover multiple TURN servers so as
to use recursively encapsulated TURN, as described in
[I-D.ietf-rtcweb-return], to route traffic through multiple TURN
servers for privacy.
8. IANA Considerations 8. IANA Considerations
8.1. Anycast 8.1. Anycast
IANA should allocate an IPv4 and an IPv6 well-known TURN anycast IANA should allocate an IPv4 and an IPv6 well-known TURN anycast
address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF
Protocol Assignments, as listed at Protocol Assignments, as listed at
<http://www.iana.org/assignments/iana-ipv4-special-registry/> and <http://www.iana.org/assignments/iana-ipv4-special-registry/> and
skipping to change at page 11, line 32 skipping to change at page 11, line 43
configuration can occur naturally via BGP messages advertising that configuration can occur naturally via BGP messages advertising that
no route exists to said address. no route exists to said address.
Sensitive clients that do not wish to leak information about their Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their TURN requests that limits how far presence can set an IP TTL on their TURN requests that limits how far
they can travel into the public Internet. they can travel into the public Internet.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Simon Perrault, Paul Kyzivat, Troy The authors would like to thank Simon Perrault, Paul Kyzivat, Troy
Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba and Karl Stahl Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl and
for their review and valuable comments. Thanks to Adam Roach for his Brandon Williams for their review and valuable comments. Thanks to
detailed review and suggesting DNS Service Discovery as an additional Adam Roach for his detailed review and suggesting DNS Service
discovery mechanism. Discovery as an additional discovery mechanism.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 5 skipping to change at page 13, line 20
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-14 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), June 2015. (work in progress), June 2015.
[I-D.wing-tram-turn-mobility] [I-D.ietf-rtcweb-return]
Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN
(RETURN) for Connectivity and Privacy in WebRTC", draft-
ietf-rtcweb-return-00 (work in progress), May 2015.
[I-D.ietf-tram-turn-mobility]
Wing, D., Patil, P., Reddy, T., and P. Martinsen, Wing, D., Patil, P., Reddy, T., and P. Martinsen,
"Mobility with TURN", draft-wing-tram-turn-mobility-03 "Mobility with TURN", draft-ietf-tram-turn-mobility-00
(work in progress), May 2015. (work in progress), November 2015.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188,
October 2001, <http://www.rfc-editor.org/info/rfc3188>. October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
 End of changes. 15 change blocks. 
21 lines changed or deleted 33 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/