draft-ietf-tram-turn-server-discovery-03.txt   draft-ietf-tram-turn-server-discovery-04.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: November 21, 2015 Cisco Expires: January 21, 2016 Cisco
May 20, 2015 July 20, 2015
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-03 draft-ietf-tram-turn-server-discovery-04
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 November 21, 2015. This Internet-Draft will expire on January 21, 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 35 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . . . . 9 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 9
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 12 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
established when one or both sides are incapable of a direct P2P established when one or both sides are incapable of a direct P2P
connection. It is an important building block for interactive, real- connection. It is an important building block for interactive, real-
time communication using audio, video, collaboration etc. time communication using audio, video, collaboration etc.
While TURN services are extensively used today, the means to auto While TURN services are extensively used today, the means to auto
discover TURN servers do not exist. TURN clients are usually discover TURN servers do not exist. TURN clients are usually
explicitly configured with a well known TURN server. To allow TURN explicitly configured with a well known TURN server. To allow TURN
applications operate seamlessly across different types of networks applications to operate seamlessly across different types of networks
and encourage the use of TURN without the need for manual and encourage the use of TURN without the need for manual
configuration, it is important that there exists an auto discovery configuration, it is important that there exists an auto discovery
mechanism for TURN services. Web Real-Time Communication (WebRTC) mechanism for TURN services. Web Real-Time Communication (WebRTC)
[I-D.ietf-rtcweb-overview] usages and related extensions, which are [I-D.ietf-rtcweb-overview] usages and related extensions, which are
mostly based on web applications, need this immediately. mostly based on web applications, need this immediately.
This document describes three discovery mechanisms. The reason for This document describes three discovery mechanisms. The reason for
providing multiple mechanisms is to maximize the opportunity for providing multiple mechanisms is to maximize the opportunity for
discovery, based on the network in which the TURN client finds discovery, based on the network in which the TURN client finds
itself. The three discovery mechanisms are: itself. The three discovery mechanisms are:
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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
following mechanisms for discovery: following mechanisms for discovery:
1. Local Configuration : If local or manual configuration exists, 1. Local Configuration : Local or manual TURN configuration (i.e.,
they should be tried first, as it may be an explicit preferred TURN servers configured at the system level) should be tried
choice of a user. An implementation MAY give the user an first, as it may be an explicit preferred choice of a user. An
opportunity (e.g., by means of configuration file options or menu implementation MAY give the user an opportunity (e.g., by means
items) to specify a TURN server for every address family. of configuration file options or menu items) to specify a TURN
server for every address family.
2. Service Resolution : The TURN client attempts to perform TURN 2. Service Resolution : The TURN client attempts to perform TURN
service resolution using the host's DNS domain. service resolution using the host's DNS domain.
3. DNS SD: DNS Service Discovery. 3. DNS SD: DNS Service Discovery.
4. Anycast : Send TURN allocate request to the assigned TURN anycast 4. Anycast : Send TURN allocate request to the assigned TURN anycast
request for each combination of interface and address family. request for each combination of interface and address family.
Not all TURN servers may be discovered using NAPTR records or DNS SD; Not all TURN servers may be discovered using NAPTR records or DNS SD;
Similarly, not all TURN servers may support anycast. For best Similarly, not all TURN servers may support anycast. For best
results, a client MUST implement all discovery mechanisms described results, a client SHOULD implement all discovery mechanisms described
above. above.
The document does not prescribe a strict order that a client must The document does not prescribe a strict order that a client must
follow for discovery. An implementation may choose to perform steps follow for discovery. An implementation may choose to perform steps
2,3 and 4 in parallel for discovery OR choose to follow any desired 2,3 and 4 in parallel for discovery OR choose to follow any desired
order and stop the discovery procedure if a mechanism succeeds. order and stop the discovery procedure if a mechanism succeeds.
On hosts with more than one interface or address family (IPv4/v6), On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be performed for each the TURN server discovery procedure has to be performed for each
combination of interface and address family. A client MAY optionaly combination of interface and address family. A client MAY optionaly
skipping to change at page 5, line 10 skipping to change at page 5, line 10
configuration. configuration.
Implementations may allow the user to specify a default name that is Implementations may allow the user to specify a default name that is
used if no specific name has been configured. used if no specific name has been configured.
4.1.1. DHCP 4.1.1. DHCP
DHCP can be used to determine the domain name related to an DHCP can be used to determine the domain name related to an
interface's point of network attachment. Network operators may interface's point of network attachment. Network operators may
provide the domain name to be used for service discovery within an provide the domain name to be used for service discovery within an
access network using DHCP. [RFC5986] defines DHCP IPv4 and IPv6 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define
access network domain name options to identify a domain name that is DHCP IPv4 and IPv6 access network domain name options to identify a
suitable for service discovery within the access network. [RFC2132] domain name that is suitable for service discovery within the access
defines the DHCP IPv4 domain name option. While this option is less network. [RFC2132] defines the DHCP IPv4 domain name option; While
suitable, it still may be useful if the option defined in [RFC5986] this option is less suitable, it may still be useful if the options
is not available. defined in [RFC5986] are not available.
For IPv6, the TURN server discovery procedure MUST try to retrieve For IPv6, the TURN server discovery procedure MUST try to retrieve
DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be
retrieved, the procedure fails for this interface. For IPv4, the retrieved, the procedure fails for this interface. For IPv4, the
TURN server discovery procedure MUST try to retrieve DHCP option 213 TURN server discovery procedure MUST try to retrieve DHCP option 213
(OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the
procedure SHOULD try to retrieve option 15 (Domain Name). If neither procedure SHOULD try to retrieve option 15 (Domain Name). If neither
option can be retrieved the procedure fails for this interface. If a option can be retrieved the procedure fails for this interface. If a
result can be retrieved it will be used as an input for S-NAPTR result can be retrieved it will be used as an input for S-NAPTR
resolution. resolution.
4.1.2. From own Identity 4.1.2. From own Identity
A TURN client could also wish to extract the domain name from its own For a TURN client with an understanding of the protocol mechanics of
identity i.e canonical identifier used to reach the user. calling applications, the client may wish to extract the domain name
from its own identity i.e canonical identifier used to reach the
user.
Example Example
SIP : 'sip:alice@example.com' SIP : 'sip:alice@example.com'
JID : 'alice@example.com' JID : 'alice@example.com'
email : 'alice@example.com' email : 'alice@example.com'
'example.com' is retrieved from the above examples. 'example.com' is retrieved from the above examples.
The means to extract the domain name may be different based on the The means to extract the domain name may be different based on the
skipping to change at page 7, line 10 skipping to change at page 7, line 10
Section 4.1 of [RFC6763] specifies that a service instance name in Section 4.1 of [RFC6763] specifies that a service instance name in
DNS-SD has the following structure: DNS-SD has the following structure:
<Instance> . <Service> . <Domain> <Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service The <Domain> portion specifies the DNS sub-domain where the service
instance is registered. It may be "local.", indicating the mDNS instance is registered. It may be "local.", indicating the mDNS
local domain, or it may be a conventional domain name such as local domain, or it may be a conventional domain name such as
"example.com.". The <Service> portion of the TURN service instance "example.com.". The <Service> portion of the TURN service instance
name MUST be "_turnserver._udp", "_turnserver._tcp". name MUST be "_turnserver._udp", "_turnserver._tcp".
The <Instance> portion is a DNS label, containing UTF-8-encoded text, The <Instance> portion is a DNS label, containing UTF-8-encoded text
limited to 63 octets in length. It is meant to be a user-friendly [RFC5198], limited to 63 octets in length. It is meant to be a user-
description of the service instance, suitable for a menu-like user friendly description of the service instance, suitable for a menu-
interface display. Thus it can contain any characters including like user interface display. Thus it can contain any characters
spaces, punctuation, and non-Latin characters as long as they can be including spaces, punctuation, and non-Latin characters as long as
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 192.168.1.2
skipping to change at page 8, line 29 skipping to change at page 8, line 29
|--------------------------------------------->| |--------------------------------------------->|
| TURN Request | | TURN Request |
|--------------------------------------------->| |--------------------------------------------->|
| TURN Response | | TURN Response |
|<---------------------------------------------| |<---------------------------------------------|
Figure 1: TURN Server Discovery using mDNS Figure 1: TURN Server Discovery using mDNS
6. Discovery using Anycast 6. Discovery using Anycast
IP anycast is an elegant solution for TURN service discovery. A IP anycast can also be used for TURN service discovery. A packet
packet sent to an anycast address is delivered to the "topologically sent to an anycast address is delivered to the "topologically
nearest" network interface with the anycast address. Using the TURN nearest" network interface with the anycast address. Using the TURN
anycast address, the only two things that need to be deployed in the anycast address, the only two things that need to be deployed in the
network are the two things that actually use TURN. network are the two things that actually use TURN.
When a client requires TURN services, it sends a TURN allocate When a client requires TURN services, it sends a TURN allocate
request to the assigned anycast address. The TURN anycast server request to the assigned anycast address. The TURN anycast server
responds with a 300 (Try Alternate) error as described in [RFC5766]; responds with a 300 (Try Alternate) error as described in [RFC5766];
The response contains the TURN unicast address in the ALTERNATE- The response contains the TURN unicast address in the ALTERNATE-
SERVER attribute. For subsequent communication with the TURN server, SERVER attribute. For subsequent communication with the TURN server,
the client uses the responding server's unicast address. This has to the client uses the responding server's unicast address. This has to
skipping to change at page 10, line 49 skipping to change at page 10, line 49
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 and Eduardo Gueiros for their review and valuable comments. Shields, Eduardo Gueiros and Ted Hardie for their review and valuable
Thanks to Adam Roach for his detailed review and suggesting DNS comments. Thanks to Adam Roach for his detailed review and
Service Discovery as an additional discovery mechanism. suggesting DNS Service 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, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>.
[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>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, August 2010. (TURN) Resolution Mechanism", RFC 5928,
DOI 10.17487/RFC5928, August 2010,
<http://www.rfc-editor.org/info/rfc5928>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September Location Information Server (LIS)", RFC 5986,
2010. DOI 10.17487/RFC5986, September 2010,
<http://www.rfc-editor.org/info/rfc5986>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server [RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS", RFC (LIS) Discovery Using IP Addresses and Reverse DNS",
7216, April 2014. RFC 7216, DOI 10.17487/RFC7216, April 2014,
<http://www.rfc-editor.org/info/rfc7216>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, August 2014. Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>.
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-13 Browser-based Applications", draft-ietf-rtcweb-overview-14
(work in progress), November 2014. (work in progress), June 2015.
[I-D.kist-alto-3pdisc] [I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014. (work in progress), January 2014.
[I-D.wing-tram-turn-mobility] [I-D.wing-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-wing-tram-turn-mobility-03
(work in progress), May 2015. (work in progress), May 2015.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, October 2001. Uniform Resource Names", RFC 3188, DOI 10.17487/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, March 2008. Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO) H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, November 2014. Server Discovery", RFC 7286, DOI 10.17487/RFC7286,
November 2014, <http://www.rfc-editor.org/info/rfc7286>.
Appendix A. Change History Appendix A. Change History
[Note to RFC Editor: Please remove this section prior to [Note to RFC Editor: Please remove this section prior to
publication.] publication.]
A.1. Change from draft-patil-tram-serv-disc-00 to -01 A.1. Change from draft-patil-tram-serv-disc-00 to -01
o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new
means to obtain domain names means to obtain domain names
 End of changes. 31 change blocks. 
55 lines changed or deleted 83 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/