idnits 2.17.1 draft-ietf-tram-turn-server-discovery-08.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 non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2016) is 2824 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) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 == Outdated reference: A later version (-02) exists of draft-ietf-rtcweb-return-01 == Outdated reference: A later version (-09) exists of draft-ietf-tram-turn-mobility-02 -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 7 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 27, 2017 Cisco 6 July 26, 2016 8 TURN Server Auto Discovery 9 draft-ietf-tram-turn-server-discovery-08 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 27, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . 5 62 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 64 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 7 66 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 68 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 69 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9 70 7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 11 75 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11 76 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 11.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 82 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14 83 A.2. Change from draft-ietf-tram-turn-server-discovery-01 to 84 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 TURN [RFC5766] is a protocol that is often used to improve the 90 connectivity of Peer-to-Peer (P2P) applications (as defined in 91 section 2.7 of [RFC5128]). TURN allows a connection to be 92 established when one or both sides are incapable of a direct P2P 93 connection. It is an important building block for interactive, real- 94 time communication using audio, video, collaboration etc. 96 While TURN services are extensively used today, the means to auto 97 discover TURN servers do not exist. TURN clients are usually 98 explicitly configured with a well known TURN server. To allow TURN 99 applications to operate seamlessly across different types of networks 100 and encourage the use of TURN without the need for manual 101 configuration, it is important that there exists an auto discovery 102 mechanism for TURN services. Web Real-Time Communication (WebRTC) 103 [I-D.ietf-rtcweb-overview] usages and related extensions, which are 104 mostly based on web applications, need this immediately. 106 This document describes three discovery mechanisms, so as to maximize 107 opportunity for discovery, based on the network in which the TURN 108 client finds 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 family 124 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", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 [RFC2119]. 133 3. Discovery Procedure 135 TURN clients, by default, discover TURN server(s) by means of local 136 or manual TURN configuration i.e., TURN servers configured at the 137 system level. For example, in case of Web Real-Time Communication 138 (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, 139 which are based on web applications, a Java Script specified TURN 140 server MUST be considered as local configuration. An implementation 141 MAY give the user an opportunity (e.g., by means of configuration 142 file options or menu items) to specify a TURN server for each address 143 family. A client can choose auto-discovery in the absence of local 144 configuration, if local configuration doesn't work or on top of local 145 configuration. This document does not offer a recommendation on 146 server selection. 148 A TURN client that implements the auto discovery algorithm, to 149 discover TURN servers in the attached network, uses the following 150 mechanisms for discovery: 152 1. Service Resolution : The TURN client attempts to perform TURN 153 service resolution using the host's DNS domain. 155 2. DNS SD: DNS Service Discovery. 157 3. Anycast : Send TURN allocate request to the assigned TURN anycast 158 request for each combination of interface and address family. 160 Not all TURN servers may be discovered using NAPTR records or DNS SD; 161 Similarly, not all TURN servers may support anycast. For best 162 results, a client SHOULD implement all discovery mechanisms described 163 above. 165 The document does not prescribe a strict order that a client must 166 follow for discovery. An implementation may choose to perform all 167 the above steps in parallel for discovery OR choose to follow any 168 desired order and stop the discovery procedure if a mechanism 169 succeeds. 171 On hosts with more than one interface or address family (IPv4/v6), 172 the TURN server discovery procedure has to be performed for each 173 combination of interface and address family. A client MAY optionally 174 choose to perform the discovery procedure only for a desired 175 interface/address combination if the client does not wish to discover 176 a TURN server for all combinations of interface and address family. 178 4. Discovery using Service Resolution 180 This mechanism is performed in two steps: 182 1. A DNS domain name is retrieved for each combination of interface 183 and address family. 185 2. Retrieved DNS domain names are then used for S-NAPTR lookups as 186 per [RFC5928]. Further DNS lookups may be necessary to determine 187 TURN server IP address(es). 189 4.1. Retrieving Domain Name 191 A client has to determine the domain in which it is located. The 192 following sections provide two possible mechanisms to learn the 193 domain name, but other means of retrieving domain names may be used, 194 which are outside the scope of this document e.g. local 195 configuration. 197 Implementations may allow the user to specify a default name that is 198 used if no specific name has been configured. 200 4.1.1. DHCP 202 DHCP can be used to determine the domain name related to an 203 interface's point of network attachment. Network operators may 204 provide the domain name to be used for service discovery within an 205 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define 206 DHCP IPv4 and IPv6 access network domain name options to identify a 207 domain name that is suitable for service discovery within the access 208 network. [RFC2132] defines the DHCP IPv4 domain name option; While 209 this option is less suitable, it may still be useful if the options 210 defined in [RFC5986] are not available. 212 For IPv6, the TURN server discovery procedure MUST try to retrieve 213 DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be 214 retrieved, the procedure fails for this interface. For IPv4, the 215 TURN server discovery procedure MUST try to retrieve DHCP option 213 216 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the 217 procedure SHOULD try to retrieve option 15 (Domain Name). If neither 218 option can be retrieved the procedure fails for this interface. If a 219 result can be retrieved it will be used as an input for S-NAPTR 220 resolution. 222 4.1.2. From own Identity 224 For a TURN client with an understanding of the protocol mechanics of 225 calling applications, the client may wish to extract the domain name 226 from its own identity i.e canonical identifier used to reach the 227 user. 229 Example 231 SIP : 'sip:alice@example.com' 232 JID : 'alice@example.com' 233 email : 'alice@example.com' 235 'example.com' is retrieved from the above examples. 237 The means to extract the domain name may be different based on the 238 type of identifier and is outside the scope of this document. 240 4.2. Resolution 242 Once the TURN discovery procedure has retrieved domain names, the 243 resolution mechanism described in [RFC5928] is followed. An S-NAPTR 244 lookup with 'RELAY' application service and the desired protocol tag 245 is made to obtain information necessary to connect to the 246 authoritative TURN server within the given domain. 248 In the example below, for domain 'example.net', the resolution 249 algorithm will result in IP address, port, and protocol tuples as 250 follows: 252 example.net. 253 IN NAPTR 100 10 "" RELAY:turn.udp "" example.net. 255 example.net. 256 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 258 _turn._udp.example.net. 259 IN SRV 0 0 3478 a.example.net. 261 a.example.net. 262 IN A 192.0.2.1 263 IN AAAA 2001:db8:8:4::2 265 +-------+----------+------------------+------+ 266 | Order | Protocol | IP address | Port | 267 +-------+----------+------------------+------+ 268 | 1 | UDP | 192.0.2.1 | 3478 | 269 +-------+----------+------------------+------+ 270 | 2 | UDP | 2001:db8:8:4::2 | 3478 | 271 +-------+----------+------------------+------+ 273 If no TURN-specific S-NAPTR records can be retrieved, the discovery 274 procedure fails for this domain name (and the corresponding interface 275 and IP protocol version). If more domain names are known, the 276 discovery procedure may perform the corresponding S-NAPTR lookups 277 immediately. However, before retrying a lookup that has failed, a 278 client MUST wait a time period that is appropriate for the 279 encountered error (NXDOMAIN, timeout, etc.). 281 5. DNS Service Discovery 283 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 284 (mDNS) [RFC6762] provide generic solutions for discovering services 285 available in a local network. DNS-SD/ mDNS define a set of naming 286 rules for certain DNS record types that they use for advertising and 287 discovering services. PTR records are used to enumerate service 288 instances of a given service type. A service instance name is mapped 289 to a host name and a port number using a SRV record. If a service 290 instance has more information to advertise than the host name and 291 port number contained in its SRV record, the additional information 292 is carried in a TXT record. 294 Section 4.1 of [RFC6763] specifies that a service instance name in 295 DNS-SD has the following structure: 297 . . 299 The portion specifies the DNS sub-domain where the service 300 instance is registered. It may be "local.", indicating the mDNS 301 local domain, or it may be a conventional domain name such as 302 "example.com.". The portion of the TURN service instance 303 name MUST be "_turnserver._udp", "_turnserver._tcp". 305 The portion is a DNS label, containing UTF-8-encoded text 306 [RFC5198], limited to 63 octets in length. It is meant to be a user- 307 friendly description of the service instance, suitable for a menu- 308 like user interface display. Thus it can contain any characters 309 including spaces, punctuation, and non-Latin characters as long as 310 they can be encoded in UTF-8. 312 For example, TURN server advertises the following DNS records : 314 _turnserver._udp.local. PTR example.com._turnserver._udp.local. 316 example.com._turnserver._udp.local. SRV 0 0 5030 example-turn- 317 server.local. 319 example-turn-server.local. A 198.51.100.2 321 example-turn-server.local. AAAA 2001:db8:8:4::2 323 In addition to the service instance name, IP address and the port 324 number, DNS-SD provides a way to publish other information pertinent 325 to the service being advertised. The additional data can be stored 326 as name/value attributes in a TXT record with the same name as the 327 SRV record for the service. Each name/value pair within the TXT 328 record is preceded by a single length byte, thereby limiting the 329 length of the pair to 255 bytes (See Section 6 of [RFC6763] and 330 Section 3.3.14 of [RFC1035] for details). 332 5.1. mDNS 334 A TURN client tries to discover the TURN servers being advertised in 335 the site by multicasting a PTR query "_turnserver._udp.local." or 336 "_turnserver._tcp.local" or the TURN server can send out gratuitous 337 multicast DNS answer packets whenever it starts up, wakes from sleep, 338 or detects a chance in network configuration. TURN clients receive 339 these gratuitous packet and cache the information contained in it. 341 +------+ +-------------+ 342 | TURN | | TURN Server | 343 |Client| | | 344 +------+ +-------------+ 345 | | 346 | PTR query "_turnserver._udp.local." | 347 |--------------------------------------------->| 348 | PTR reply | 349 |<---------------------------------------------| 350 | SRV query | 351 |--------------------------------------------->| 352 | SRV reply | 353 |<---------------------------------------------| 354 | A/AAAA query reply | 355 |--------------------------------------------->| 356 | TURN Request | 357 |--------------------------------------------->| 358 | TURN Response | 359 |<---------------------------------------------| 361 Figure 1: TURN Server Discovery using mDNS 363 6. Discovery using Anycast 365 IP anycast can also be used for TURN service discovery. A packet 366 sent to an anycast address is delivered to the "topologically 367 nearest" network interface with the anycast address. Using the TURN 368 anycast address, the only two things that need to be deployed in the 369 network are the two things that actually use TURN. 371 When a client requires TURN services, it sends a TURN allocate 372 request to the assigned anycast address. The TURN anycast server 373 responds with a 300 (Try Alternate) error as described in [RFC5766]; 374 The response contains the TURN unicast address in the ALTERNATE- 375 SERVER attribute. For subsequent communication with the TURN server, 376 the client uses the responding server's unicast address. This has to 377 be done because two packets addressed to an anycast address may reach 378 two different anycast servers. The client, thus, also needs to 379 ensure that the initial request fits in a single packet. An 380 implementation may choose to send out every new request to the 381 anycast address to learn the closest TURN server each time. 383 7. Deployment Considerations 385 7.1. Mobility and Changing IP addresses 387 A change of IP address on an interface may invalidate the result of 388 the TURN server discovery procedure. For instance, if the IP address 389 assigned to a mobile host changes due to host mobility, it may be 390 required to re-run the TURN server discovery procedure without 391 relying on earlier gained information. New requests should be made 392 to the newly learned TURN servers learned after TURN discovery re- 393 run. However, if an earlier learned TURN server is still accessible 394 using the new IP address, procedures described for mobility using 395 TURN defined in [I-D.ietf-tram-turn-mobility] can be used for ongoing 396 streams. 398 7.2. Recursively Encapsulated TURN 400 WebRTC endpoints SHOULD treat any TURN server discovered through the 401 mechanims described in this specification as an enterprise/gateway 402 server, in accordance with Recursively Encapsulated TURN 403 [I-D.ietf-rtcweb-return]. 405 8. IANA Considerations 407 8.1. Anycast 409 IANA should allocate an IPv4 and an IPv6 well-known TURN anycast 410 address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF 411 Protocol Assignments, as listed at 413 and 415 417 9. Security Considerations 419 Use of STUN authentication is OPTIONAL for TURN servers provided by 420 the local network or by the access network. A network provided TURN 421 server MAY be configured to accept Allocation requests without STUN 422 authentication, and a TURN client MAY be configured to accept 423 Allocation success responses without STUN authentication from a 424 network provided TURN server. In order to protect against man-in- 425 the-middle attacks when accepting a TURN allocation response without 426 STUN authentication, it is RECOMMENDED that the TURN client use one 427 of the following techniques with (D)TLS to validate the TURN server: 429 o For certificate-based authentication, a pre-populated trust anchor 430 store [RFC6024] allows a TURN client to perform path validation 431 for the server certificate obtained during the (D)TLS handshake. 432 If the client used a domain name to discover the TURN server, that 433 domain name also provides a mechanism for validation of the TURN 434 server. The client MUST use the rules and guidelines given in 435 section 6 of [RFC6125] to validate the TURN server identity. 437 o For TURN servers that don't have a certificate trust chain (e.g., 438 because they are on a home network or a corporate network), a 439 configured list of TURN servers can contain the Subject Public Key 440 Info (SPKI) fingerprint of the TURN servers. The public key is 441 used for the same reasons HTTP pinning [RFC7469] uses the public 442 key. 444 o Raw public key-based authentication, as defined in [RFC7250], 445 could also be used to authenticate a TURN server. 447 An auto-discovered TURN server is considered to be only as trusted as 448 the path between the client and the TURN server. In order to safely 449 use auto-discovered TURN servers for sessions with 'strict privacy' 450 requirements, the user needs to be able to define privacy criteria 451 (e.g. a trusted list of servers, networks, or domains) that are 452 considered acceptable for such traffic. Any discovered TURN server 453 outside the criteria is considered untrusted and is not used for 454 privacy sensitive communication. 456 In some auto-discovery scenarios, it might not be possible for the 457 TURN client to use (D)TLS authentication to validate the TURN server. 458 However, fall-back to clear text in such cases could leave the TURN 459 client open to on-path injection of spoofed TURN messages. For this 460 reason, it is beneficial for the TURN client to make use of 461 'opportunistic privacy', analogous to SMTP opportunistic encryption 462 [RFC7435], where one does not require privacy but one desires privacy 463 when possible. In this scenario, a TURN client attempts (D)TLS with 464 authentication and encryption, falling back to encryption-only if the 465 TURN server cannot be authenticated via (D)TLS. If the TURN server 466 does not support unauthenticated (D)TLS, it could fall back to clear 467 text, but fallback to clear text is NOT RECOMMENDED because it makes 468 the client more susceptible to man-in-the-middle attacks and on-path 469 packet injection. A TURN client SHOULD fall-back to encryption-only 470 (D)TLS when (D)TLS authentication is not available in order to 471 protect against on-path attackers who might attempt to inject fake 472 TURN messages. 474 9.1. Service Resolution 476 The primary attack against the methods described in this document is 477 one that would lead to impersonation of a TURN server. An attacker 478 could attempt to compromise the S-NAPTR resolution. Security 479 considerations described in [RFC5928] are applicable here as well. 481 In addition to considerations related to S-NAPTR, it is important to 482 recognize that the output of this is entirely dependent on its input. 483 An attacker who can control the domain name can also control the 484 final result. Because more than one method can be used to determine 485 the domain name, a host implementation needs to consider attacks 486 against each of the methods that are used. 488 If DHCP is used, the integrity of DHCP options is limited by the 489 security of the channel over which they are provided. Physical 490 security and separation of DHCP messages from other packets are 491 commonplace methods that can reduce the possibility of attack within 492 an access network; alternatively, DHCP authentication [RFC3188] can 493 provide a degree of protection against modification. When using DHCP 494 discovery, clients are encouraged to use unicast DHCP INFORM queries 495 instead of broadcast queries which are more easily spoofed in 496 insecure networks. 498 9.2. DNS Service Discovery 500 Since DNS-SD is just a specification for how to name and use records 501 in the existing DNS system, it has no specific additional security 502 requirements over and above those that already apply to DNS queries 503 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 504 [RFC4033] should be used where the authenticity of information is 505 important. For DNS updates, secure updates [RFC2136][RFC3007] should 506 generally be used to control which clients have permission to update 507 DNS records. 509 For mDNS, in addition to what has been described above, a principal 510 security threat is a security threat inherent to IP multicast routing 511 and any application that runs on it. A rogue system can advertise 512 that it is a TURN server. Discovery of such rogue systems as TURN 513 servers, in itself, is not a security threat if there is a means for 514 the TURN client to authenticate and authorize the discovered TURN 515 servers. 517 9.3. Anycast 519 In a network without any TURN server that is aware of the TURN 520 anycast address, outgoing TURN requests could leak out onto the 521 external Internet, possibly revealing information. 523 Using an IANA-assigned well-known TURN anycast address enables border 524 gateways to block such outgoing packets. In the default-free zone, 525 routers should be configured to drop such packets. Such 526 configuration can occur naturally via BGP messages advertising that 527 no route exists to said address. 529 Sensitive clients that do not wish to leak information about their 530 presence can set an IP TTL on their TURN requests that limits how far 531 they can travel into the public Internet. 533 10. Acknowledgements 535 The authors would like to thank Simon Perrault, Paul Kyzivat, Troy 536 Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl and 537 Brandon Williams for their review and valuable comments. Thanks to 538 Adam Roach for his detailed review and suggesting DNS Service 539 Discovery as an additional discovery mechanism. 541 11. References 543 11.1. Normative References 545 [RFC1035] Mockapetris, P., "Domain names - implementation and 546 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 547 November 1987, . 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 555 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 556 . 558 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 559 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 560 RFC 2136, DOI 10.17487/RFC2136, April 1997, 561 . 563 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 564 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 565 . 567 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 568 Rose, "DNS Security Introduction and Requirements", 569 RFC 4033, DOI 10.17487/RFC4033, March 2005, 570 . 572 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 573 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 574 . 576 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 577 Relays around NAT (TURN): Relay Extensions to Session 578 Traversal Utilities for NAT (STUN)", RFC 5766, 579 DOI 10.17487/RFC5766, April 2010, 580 . 582 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 583 (TURN) Resolution Mechanism", RFC 5928, 584 DOI 10.17487/RFC5928, August 2010, 585 . 587 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 588 Location Information Server (LIS)", RFC 5986, 589 DOI 10.17487/RFC5986, September 2010, 590 . 592 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 593 DOI 10.17487/RFC6762, February 2013, 594 . 596 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 597 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 598 . 600 11.2. Informative References 602 [I-D.ietf-rtcweb-overview] 603 Alvestrand, H., "Overview: Real Time Protocols for 604 Browser-based Applications", draft-ietf-rtcweb-overview-15 605 (work in progress), January 2016. 607 [I-D.ietf-rtcweb-return] 608 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 609 (RETURN) for Connectivity and Privacy in WebRTC", draft- 610 ietf-rtcweb-return-01 (work in progress), January 2016. 612 [I-D.ietf-tram-turn-mobility] 613 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 614 "Mobility with TURN", draft-ietf-tram-turn-mobility-02 615 (work in progress), April 2016. 617 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 618 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 619 October 2001, . 621 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 622 Peer (P2P) Communication across Network Address 623 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 624 2008, . 626 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 627 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 628 2010, . 630 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 631 Verification of Domain-Based Application Service Identity 632 within Internet Public Key Infrastructure Using X.509 633 (PKIX) Certificates in the Context of Transport Layer 634 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 635 2011, . 637 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 638 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 639 Transport Layer Security (TLS) and Datagram Transport 640 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 641 June 2014, . 643 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 644 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 645 December 2014, . 647 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 648 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 649 2015, . 651 Appendix A. Change History 653 [Note to RFC Editor: Please remove this section prior to 654 publication.] 656 A.1. Change from draft-patil-tram-serv-disc-00 to -01 658 o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new 659 means to obtain domain names 661 o New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc) 663 o 300 (Try Alternate) response for Anycast 665 A.2. Change from draft-ietf-tram-turn-server-discovery-01 to 02 667 o Removed sections that describe reverse IP lookup 669 o Added DNS Service Discovery as an additional discovery mechanism 671 Authors' Addresses 673 Prashanth Patil 674 Cisco Systems, Inc. 675 Bangalore 676 India 678 Email: praspati@cisco.com 680 Tirumaleswar Reddy 681 Cisco Systems, Inc. 682 Cessna Business Park, Varthur Hobli 683 Sarjapur Marathalli Outer Ring Road 684 Bangalore, Karnataka 560103 685 India 687 Email: tireddy@cisco.com 689 Dan Wing 690 Cisco Systems, Inc. 691 170 West Tasman Drive 692 San Jose, California 95134 693 USA 695 Email: dwing@cisco.com