idnits 2.17.1 draft-ietf-tram-turn-server-discovery-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3204 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3596' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC7216' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'I-D.kist-alto-3pdisc' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC7286' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-14 -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Patil 3 Internet-Draft T. Reddy 4 Intended status: Standards Track D. Wing 5 Expires: January 21, 2016 Cisco 6 July 20, 2015 8 TURN Server Auto Discovery 9 draft-ietf-tram-turn-server-discovery-04 11 Abstract 13 Current Traversal Using Relays around NAT (TURN) server discovery 14 mechanisms are relatively static and limited to explicit 15 configuration. These are usually under the administrative control of 16 the application or TURN service provider, and not the enterprise, 17 ISP, or the network in which the client is located. Enterprises and 18 ISPs wishing to provide their own TURN servers need auto discovery 19 mechanisms that a TURN client could use with no or minimal 20 configuration. This document describes three such mechanisms for 21 TURN server discovery. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3 60 4. Discovery using Service Resolution . . . . . . . . . . . . . 4 61 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 4 62 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 64 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 66 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 68 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 69 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 9 74 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10 75 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 11.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 81 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 13 82 A.2. Change from draft-ietf-tram-turn-server-discovery-01 to 83 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 TURN [RFC5766] is a protocol that is often used to improve the 89 connectivity of Peer-to-Peer (P2P) applications (as defined in 90 section 2.7 of [RFC5128]). TURN allows a connection to be 91 established when one or both sides are incapable of a direct P2P 92 connection. It is an important building block for interactive, real- 93 time communication using audio, video, collaboration etc. 95 While TURN services are extensively used today, the means to auto 96 discover TURN servers do not exist. TURN clients are usually 97 explicitly configured with a well known TURN server. To allow TURN 98 applications to operate seamlessly across different types of networks 99 and encourage the use of TURN without the need for manual 100 configuration, it is important that there exists an auto discovery 101 mechanism for TURN services. Web Real-Time Communication (WebRTC) 102 [I-D.ietf-rtcweb-overview] usages and related extensions, which are 103 mostly based on web applications, need this immediately. 105 This document describes three discovery mechanisms. The reason for 106 providing multiple mechanisms is to maximize the opportunity for 107 discovery, based on the network in which the TURN client finds 108 itself. The three discovery mechanisms are: 110 o A resolution mechanism based on straightforward Naming Authority 111 Pointer (S-NAPTR) resource records in the Domain Name System 112 (DNS). [RFC5928] describes details on retrieving a list of server 113 transport addresses from DNS that can be used to create a TURN 114 allocation. 116 o DNS Service Discovery 118 o A mechanism based on anycast address for TURN. 120 In general, if a client wishes to communicate using one of its 121 interfaces using a specific IP address family, it SHOULD query the 122 TURN server(s) that has been discovered for that specific interface 123 and address family. How to select an interface and IP address 124 family, is out of the scope of this document. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Discovery Procedure 134 A TURN client that implements the auto discovery algorithm uses the 135 following mechanisms for discovery: 137 1. Local Configuration : Local or manual TURN configuration (i.e., 138 TURN servers configured at the system level) should be tried 139 first, as it may be an explicit preferred choice of a user. An 140 implementation MAY give the user an opportunity (e.g., by means 141 of configuration file options or menu items) to specify a TURN 142 server for every address family. 144 2. Service Resolution : The TURN client attempts to perform TURN 145 service resolution using the host's DNS domain. 147 3. DNS SD: DNS Service Discovery. 149 4. Anycast : Send TURN allocate request to the assigned TURN anycast 150 request for each combination of interface and address family. 152 Not all TURN servers may be discovered using NAPTR records or DNS SD; 153 Similarly, not all TURN servers may support anycast. For best 154 results, a client SHOULD implement all discovery mechanisms described 155 above. 157 The document does not prescribe a strict order that a client must 158 follow for discovery. An implementation may choose to perform steps 159 2,3 and 4 in parallel for discovery OR choose to follow any desired 160 order and stop the discovery procedure if a mechanism succeeds. 162 On hosts with more than one interface or address family (IPv4/v6), 163 the TURN server discovery procedure has to be performed for each 164 combination of interface and address family. A client MAY optionaly 165 choose to perform the discovery procedure only for a desired 166 interface/address combination if the client does not wish to discover 167 a TURN server for all combinations of interface and address family. 169 4. Discovery using Service Resolution 171 This mechanism is performed in two steps: 173 1. A DNS domain name is retrieved for each combination of interface 174 and address family. 176 2. Retrieved DNS domain names are then used for S-NAPTR lookups as 177 per [RFC5928]. Further DNS lookups may be necessary to determine 178 TURN server IP address(es). 180 4.1. Retrieving Domain Name 182 A client has to determine the domain in which it is located. The 183 following sections provide two possible mechanisms to learn the 184 domain name, but other means of retrieving domain names may be used, 185 which are outside the scope of this document e.g. local 186 configuration. 188 Implementations may allow the user to specify a default name that is 189 used if no specific name has been configured. 191 4.1.1. DHCP 193 DHCP can be used to determine the domain name related to an 194 interface's point of network attachment. Network operators may 195 provide the domain name to be used for service discovery within an 196 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define 197 DHCP IPv4 and IPv6 access network domain name options to identify a 198 domain name that is suitable for service discovery within the access 199 network. [RFC2132] defines the DHCP IPv4 domain name option; While 200 this option is less suitable, it may still be useful if the options 201 defined in [RFC5986] are not available. 203 For IPv6, the TURN server discovery procedure MUST try to retrieve 204 DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be 205 retrieved, the procedure fails for this interface. For IPv4, the 206 TURN server discovery procedure MUST try to retrieve DHCP option 213 207 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the 208 procedure SHOULD try to retrieve option 15 (Domain Name). If neither 209 option can be retrieved the procedure fails for this interface. If a 210 result can be retrieved it will be used as an input for S-NAPTR 211 resolution. 213 4.1.2. From own Identity 215 For a TURN client with an understanding of the protocol mechanics of 216 calling applications, the client may wish to extract the domain name 217 from its own identity i.e canonical identifier used to reach the 218 user. 220 Example 222 SIP : 'sip:alice@example.com' 223 JID : 'alice@example.com' 224 email : 'alice@example.com' 226 'example.com' is retrieved from the above examples. 228 The means to extract the domain name may be different based on the 229 type of identifier and is outside the scope of this document. 231 4.2. Resolution 233 Once the TURN discovery procedure has retrieved domain names, the 234 resolution mechanism described in [RFC5928] is followed. An S-NAPTR 235 lookup with 'RELAY' application service and the desired protocol tag 236 is made to obtain information necessary to connect to the 237 authoritative TURN server within the given domain. 239 In the example below, for domain 'example.net', the resolution 240 algorithm will result in IP address, port, and protocol tuples as 241 follows: 243 example.net. 244 IN NAPTR 100 10 "" RELAY:turn.udp "" example.net. 246 example.net. 247 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 249 _turn._udp.example.net. 250 IN SRV 0 0 3478 a.example.net. 252 a.example.net. 253 IN A 192.0.2.1 255 +-------+----------+------------+------+ 256 | Order | Protocol | IP address | Port | 257 +-------+----------+------------+------+ 258 | 1 | UDP | 192.0.2.1 | 3478 | 259 +-------+----------+------------+------+ 261 If no TURN-specific S-NAPTR records can be retrieved, the discovery 262 procedure fails for this domain name (and the corresponding interface 263 and IP protocol version). If more domain names are known, the 264 discovery procedure may perform the corresponding S-NAPTR lookups 265 immediately. However, before retrying a lookup that has failed, a 266 client MUST wait a time period that is appropriate for the 267 encountered error (NXDOMAIN, timeout, etc.). 269 5. DNS Service Discovery 271 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 272 (mDNS) [RFC6762] provide generic solutions for discovering services 273 available in a local network. DNS-SD/ mDNS define a set of naming 274 rules for certain DNS record types that they use for advertising and 275 discovering services. PTR records are used to enumerate service 276 instances of a given service type. A service instance name is mapped 277 to a host name and a port number using a SRV record. If a service 278 instance has more information to advertise than the host name and 279 port number contained in its SRV record, the additional information 280 is carried in a TXT record. 282 Section 4.1 of [RFC6763] specifies that a service instance name in 283 DNS-SD has the following structure: 285 . . 286 The portion specifies the DNS sub-domain where the service 287 instance is registered. It may be "local.", indicating the mDNS 288 local domain, or it may be a conventional domain name such as 289 "example.com.". The portion of the TURN service instance 290 name MUST be "_turnserver._udp", "_turnserver._tcp". 292 The portion is a DNS label, containing UTF-8-encoded text 293 [RFC5198], limited to 63 octets in length. It is meant to be a user- 294 friendly description of the service instance, suitable for a menu- 295 like user interface display. Thus it can contain any characters 296 including spaces, punctuation, and non-Latin characters as long as 297 they can be encoded in UTF-8. 299 For example, TURN server advertises the following DNS records : 301 _turnserver._udp.local. PTR example.com._turnserver._udp.local. 303 example.com._turnserver._udp.local. SRV 0 0 5030 example-turn- 304 server.local. 306 example-turn-server.local. A 192.168.1.2 308 In addition to the service instance name, IP address and the port 309 number, DNS-SD provides a way to publish other information pertinent 310 to the service being advertised. The additional data can be stored 311 as name/value attributes in a TXT record with the same name as the 312 SRV record for the service. Each name/value pair within the TXT 313 record is preceded by a single length byte, thereby limiting the 314 length of the pair to 255 bytes (See Section 6 of [RFC6763] and 315 Section 3.3.14 of [RFC1035] for details). 317 5.1. mDNS 319 A TURN client tries to discover the TURN servers being advertised in 320 the site by multicasting a PTR query "_turnserver._udp.local." or 321 "_turnserver._tcp.local" or the TURN server can send out gratuitous 322 multicast DNS answer packets whenever it starts up, wakes from sleep, 323 or detects a chance in network configuration. TURN clients receive 324 these gratuitous packet and cache the information contained in it. 326 +------+ +-------------+ 327 | TURN | | TURN Server | 328 |Client| | | 329 +------+ +-------------+ 330 | | 331 | PTR query "_turnserver._udp.local." | 332 |--------------------------------------------->| 333 | PTR reply | 334 |<---------------------------------------------| 335 | SRV query | 336 |--------------------------------------------->| 337 | SRV reply | 338 |<---------------------------------------------| 339 | A/AAAA query reply | 340 |--------------------------------------------->| 341 | TURN Request | 342 |--------------------------------------------->| 343 | TURN Response | 344 |<---------------------------------------------| 346 Figure 1: TURN Server Discovery using mDNS 348 6. Discovery using Anycast 350 IP anycast can also be used for TURN service discovery. A packet 351 sent to an anycast address is delivered to the "topologically 352 nearest" network interface with the anycast address. Using the TURN 353 anycast address, the only two things that need to be deployed in the 354 network are the two things that actually use TURN. 356 When a client requires TURN services, it sends a TURN allocate 357 request to the assigned anycast address. The TURN anycast server 358 responds with a 300 (Try Alternate) error as described in [RFC5766]; 359 The response contains the TURN unicast address in the ALTERNATE- 360 SERVER attribute. For subsequent communication with the TURN server, 361 the client uses the responding server's unicast address. This has to 362 be done because two packets addressed to an anycast address may reach 363 two different anycast servers. The client, thus, also needs to 364 ensure that the initial request fits in a single packet. An 365 implementation may choose to send out every new request to the 366 anycast address to learn the closest TURN server each time. 368 7. Deployment Considerations 369 7.1. Mobility and Changing IP addresses 371 A change of IP address on an interface may invalidate the result of 372 the TURN server discovery procedure. For instance, if the IP address 373 assigned to a mobile host changes due to host mobility, it may be 374 required to re-run the TURN server discovery procedure without 375 relying on earlier gained information. New requests should be made 376 to the newly learned TURN servers learned after TURN discovery re- 377 run. However, if an earlier learned TURN server is still accessible 378 using the new IP address, procedures described for mobility using 379 TURN defined in [I-D.wing-tram-turn-mobility] can be used for ongoing 380 streams. 382 8. IANA Considerations 384 8.1. Anycast 386 IANA should allocate an IPv4 and an IPv6 well-known TURN anycast 387 address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF 388 Protocol Assignments, as listed at 390 and 392 394 9. Security Considerations 396 In general, it is recommended that a TURN client authenticate with 397 the TURN server to identify a rouge server. [RFC7350] can be 398 potentially used by a client to validate a previously unknown server. 400 9.1. Service Resolution 402 The primary attack against the methods described in this document is 403 one that would lead to impersonation of a TURN server. An attacker 404 could attempt to compromise the S-NAPTR resolution. Security 405 considerations described in [RFC5928] are applicable here as well. 407 In addition to considerations related to S-NAPTR, it is important to 408 recognize that the output of this is entirely dependent on its input. 409 An attacker who can control the domain name can also control the 410 final result. Because more than one method can be used to determine 411 the domain name, a host implementation needs to consider attacks 412 against each of the methods that are used. 414 If DHCP is used, the integrity of DHCP options is limited by the 415 security of the channel over which they are provided. Physical 416 security and separation of DHCP messages from other packets are 417 commonplace methods that can reduce the possibility of attack within 418 an access network; alternatively, DHCP authentication [RFC3188] can 419 provide a degree of protection against modification. When using DHCP 420 discovery, clients are encouraged to use unicast DHCP INFORM queries 421 instead of broadcast queries which are more easily spoofed in 422 insecure networks. 424 9.2. DNS Service Discovery 426 Since DNS-SD is just a specification for how to name and use records 427 in the existing DNS system, it has no specific additional security 428 requirements over and above those that already apply to DNS queries 429 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 430 [RFC4033] should be used where the authenticity of information is 431 important. For DNS updates, secure updates [RFC2136][RFC3007] should 432 generally be used to control which clients have permission to update 433 DNS records. 435 For mDNS, in addition to what has been described above, a principal 436 security threat is a security threat inherent to IP multicast routing 437 and any application that runs on it. A rogue system can advertise 438 that it is a TURN server. Discovery of such rogue systems as TURN 439 servers, in itself, is not a security threat if there is a means for 440 the TURN client to authenticate and authorize the discovered TURN 441 servers. 443 9.3. Anycast 445 In a network without any TURN server that is aware of the TURN 446 anycast address, outgoing TURN requests could leak out onto the 447 external Internet, possibly revealing information. 449 Using an IANA-assigned well-known TURN anycast address enables border 450 gateways to block such outgoing packets. In the default-free zone, 451 routers should be configured to drop such packets. Such 452 configuration can occur naturally via BGP messages advertising that 453 no route exists to said address. 455 Sensitive clients that do not wish to leak information about their 456 presence can set an IP TTL on their TURN requests that limits how far 457 they can travel into the public Internet. 459 10. Acknowledgements 461 The authors would like to thank Simon Perrault, Paul Kyzivat, Troy 462 Shields, Eduardo Gueiros and Ted Hardie for their review and valuable 463 comments. Thanks to Adam Roach for his detailed review and 464 suggesting DNS Service Discovery as an additional discovery 465 mechanism. 467 11. References 469 11.1. Normative References 471 [RFC1035] Mockapetris, P., "Domain names - implementation and 472 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 473 November 1987, . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 481 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 482 . 484 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 485 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 486 RFC 2136, DOI 10.17487/RFC2136, April 1997, 487 . 489 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 490 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 491 . 493 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 494 "DNS Extensions to Support IP Version 6", RFC 3596, 495 DOI 10.17487/RFC3596, October 2003, 496 . 498 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 499 Rose, "DNS Security Introduction and Requirements", 500 RFC 4033, DOI 10.17487/RFC4033, March 2005, 501 . 503 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 504 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 505 . 507 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 508 Relays around NAT (TURN): Relay Extensions to Session 509 Traversal Utilities for NAT (STUN)", RFC 5766, 510 DOI 10.17487/RFC5766, April 2010, 511 . 513 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 514 (TURN) Resolution Mechanism", RFC 5928, 515 DOI 10.17487/RFC5928, August 2010, 516 . 518 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 519 Location Information Server (LIS)", RFC 5986, 520 DOI 10.17487/RFC5986, September 2010, 521 . 523 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 524 DOI 10.17487/RFC6762, February 2013, 525 . 527 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 528 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 529 . 531 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 532 (LIS) Discovery Using IP Addresses and Reverse DNS", 533 RFC 7216, DOI 10.17487/RFC7216, April 2014, 534 . 536 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 537 Layer Security (DTLS) as Transport for Session Traversal 538 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 539 August 2014, . 541 11.2. Informative References 543 [I-D.ietf-rtcweb-overview] 544 Alvestrand, H., "Overview: Real Time Protocols for 545 Browser-based Applications", draft-ietf-rtcweb-overview-14 546 (work in progress), June 2015. 548 [I-D.kist-alto-3pdisc] 549 Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party 550 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 551 (work in progress), January 2014. 553 [I-D.wing-tram-turn-mobility] 554 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 555 "Mobility with TURN", draft-wing-tram-turn-mobility-03 556 (work in progress), May 2015. 558 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 559 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 560 October 2001, . 562 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 563 Peer (P2P) Communication across Network Address 564 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 565 2008, . 567 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 568 H. Song, "Application-Layer Traffic Optimization (ALTO) 569 Server Discovery", RFC 7286, DOI 10.17487/RFC7286, 570 November 2014, . 572 Appendix A. Change History 574 [Note to RFC Editor: Please remove this section prior to 575 publication.] 577 A.1. Change from draft-patil-tram-serv-disc-00 to -01 579 o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new 580 means to obtain domain names 582 o New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc) 584 o 300 (Try Alternate) response for Anycast 586 A.2. Change from draft-ietf-tram-turn-server-discovery-01 to 02 588 o Removed sections that describe reverse IP lookup 590 o Added DNS Service Discovery as an additional discovery mechanism 592 Authors' Addresses 594 Prashanth Patil 595 Cisco Systems, Inc. 596 Bangalore 597 India 599 Email: praspati@cisco.com 601 Tirumaleswar Reddy 602 Cisco Systems, Inc. 603 Cessna Business Park, Varthur Hobli 604 Sarjapur Marathalli Outer Ring Road 605 Bangalore, Karnataka 560103 606 India 608 Email: tireddy@cisco.com 609 Dan Wing 610 Cisco Systems, Inc. 611 170 West Tasman Drive 612 San Jose, California 95134 613 USA 615 Email: dwing@cisco.com