idnits 2.17.1 draft-williams-peer-redirect-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2015) is 3098 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) == Missing Reference: 'PC' is mentioned on line 120, but not defined == Missing Reference: 'PA' is mentioned on line 126, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-tram-stunbis-04 ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-21) exists of draft-ietf-ice-trickle-00 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Williams 3 Internet-Draft Akamai 4 Intended status: Standards Track T. Reddy 5 Expires: May 5, 2016 Cisco 6 November 2, 2015 8 Peer-specific Redirection for Traversal Using Relays around NAT (TURN) 9 draft-williams-peer-redirect-04 11 Abstract 13 This specification describes a peer-specific redirection method that 14 allows the TURN server to redirect a client for the purpose of 15 improving communication with a specific peer without negatively 16 affecting communication with other peers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 5, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Redirection for Performance . . . . . . . . . . . . . . . 3 54 1.2. Redirection for Load Balancing . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Peer-specific Server Redirect Mechanism . . . . . . . . . . . 4 57 3.1. Forming an Allocate Request . . . . . . . . . . . . . . . 5 58 3.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5 59 3.3. Forming a CreatePermission or ChannelBind Request . . . . 5 60 3.4. Receiving a CreatePermission or ChannelBind Request . . . 6 61 3.5. Forming a Redirect Indication . . . . . . . . . . . . . . 7 62 3.6. Receiving a Redirect Indication . . . . . . . . . . . . . 8 63 4. ICE Interactions . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 5.1. Permission Flood . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Unsolicited or Invalid Redirect Indication . . . . . . . 10 67 5.3. Replayed Redirect Indication . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 12 74 A.1. Changes from version 03 to 04 . . . . . . . . . . . . . . 13 75 A.2. Changes from version 02 to 03 . . . . . . . . . . . . . . 13 76 A.3. Changes from version 01 to 02 . . . . . . . . . . . . . . 13 77 A.4. Changes from version 00 to 01 . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 A Traversal Using Relay around NAT (TURN) [RFC5766] service provider 83 may provide multiple candidate TURN servers for use by a host, but it 84 might not be possible to determine which candidate TURN server will 85 provide the best performance until both peers have been identified. 86 This could be true for a variety of reasons, including: 88 o Using the selected relay for a specific peer results in a sub- 89 optimal end-to-end Internet path. 91 o Load conditions on the selected relay have changed since the 92 allocation was established such that it cannot support the new 93 data flow. 95 At the same time, the above conditions might apply to one peer but 96 not another, such that it would be best to selectively use the 97 existing relay allocation for peers that will receive reasonable 98 performance and redirect data flows for other peers to an alternate 99 server. These scenarios are discussed in greater detail below. 101 The Session Traversal Utilities for NAT (STUN) protocol 102 [I-D.ietf-tram-stunbis] defines an ALTERNATE-SERVER mechanism with 103 which a server can redirect a client to another server by replying to 104 a request message with an error response with error code 300 (Try 105 Alternate). The TURN protocol describes error code 300 as one of the 106 possible error codes for an Allocate error response. 108 This specification describes an additional use of the ALTERNATE- 109 SERVER STUN attribute for TURN that allows the TURN server to 110 redirect a client for the purpose of improving communication with a 111 specific peer without negatively affecting communication with other 112 peers. 114 1.1. Redirection for Performance 116 Consider the following example: 118 Boston 119 Peer C 120 Chicago [PC] 121 Peer B / 122 TURN Relay A ----------[PB]-------------[TC] 123 San Francisco ----------/ TURN Relay C 124 [TA]----------/ New York 125 | 126 [PA] 127 Peer A 128 Los Angeles 130 When Peer B wishes to communicate with either Peer A or Peer C, it 131 performs a DNS lookup and discovers TURN Relay C, the nearest of the 132 candidate TURN servers. Peer B then sends a TURN Allocate request to 133 TURN Relay C to determine the reflexive and relay candidates to 134 offer. After the reflexive candidate has been chosen, Peer B sends a 135 ChannelBind request to TURN Relay C to establish a channel for 136 communication with the peer. If Peer C is the remote peer, the 137 existing allocation will perform reasonably well, but if Peer A is 138 the remote peer, the latency for relayed packets will be nearly twice 139 as long as if TURN Relay A had been selected as the relay candidate. 140 The problem is worse if Peer B wishes to communicate with both Peer A 141 and Peer C, since there is no single relay candidate that would 142 provide optimum performance for both peers. 144 If TURN Relay C and TURN Relay A are part of a common TURN service, 145 it would be possible for TURN Relay C to determine that TURN Relay A 146 will provide optimal service for communication between Peer B and 147 Peer A. This allows the TURN service to redirect just the data 148 channel between Peer A and Peer B to TURN relay A, thus providing 149 optimal performance for both relay channels. 151 The above example describes the problem in terms of physical 152 geography instead of network geography in order to help clarify the 153 discussion. However, readers should note that the problem of 154 selecting a relay server to achieve optimal end-to-end routing is 155 much more complicated than the above description suggests, requiring 156 a detailed real-time view of network connectivity characteristics and 157 the peering relationships between autonomous systems. A naive 158 approach based solely on the physical location of the hosts involved 159 is just as likely to produce negative results as positive ones. 161 That said, a relay service provider with a broadly distributed system 162 for actively monitoring network performance across the relevant parts 163 of the Internet could make use of the resulting data set to select 164 the optimal relay for each peer pair. 166 1.2. Redirection for Load Balancing 168 At the point when a relay allocation is first established, it can be 169 difficult to determine how much aggregate concurrent load could 170 eventually be associated with that allocation. The initiating peer 171 could attempt to use that allocation for any number of peer-to-peer 172 data flows over an extended period of time, during which time load 173 conditions on the relay could change substantially, such that quality 174 of service for already established flows would degrade if the relay 175 were to accept additional flows. 177 Under these conditions, a TURN service provider with multiple relay 178 hosts and distributed capacity could improve service quality by 179 redirecting data flows to a different host that has more available 180 capacity. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Peer-specific Server Redirect Mechanism 190 This specification describes a new STUN indication type, Redirect, 191 which is used by a TURN server to notify a TURN client when better 192 service could be available through an alternate TURN server. The 193 Redirect indication contains an ALTERNATE-SERVER attribute to provide 194 the address for the alternate TURN server. 196 This specification also defines two new comprehension-optional STUN 197 attributes: CHECK-ALTERNATE and XOR-OTHER-ADDRESS. The CHECK- 198 ALTERNATE attribute is used by the client to request that the server 199 perform peer-specific redirection. The XOR-OTHER-ADDRESS is used by 200 the client to provide an alternate peer address for location 201 identification in the event that the XOR-PEER-ADDRESS attribute in 202 the CreatePermission or ChannelBind request is not expected to 203 reliably serve this purpose. 205 3.1. Forming an Allocate Request 207 When forming an Allocate request, a TURN client includes a CHECK- 208 ALTERNATE STUN attribute to signal to the TURN server that peer- 209 specific redirection is both supported and desired. 211 When forming a CHECK-ALTERNATE attribute, the STUN Type is TBD-CA. 212 To maintain backward compatibility, this type is in the 213 comprehension-optional range, which means that an [RFC5766] compliant 214 TURN server can safely ignore it. 216 The CHECK-ALTERNATE attribute has no value part and thus the 217 attribute length field is 0. 219 3.2. Receiving an Allocate Request 221 When a server receives an Allocate request, it first processes the 222 request as per the TURN specification [RFC5766]. After determining 223 that a success response will be prepared, a TURN server that supports 224 peer-specific redirection checks for a CHECK-ALTERNATE attribute. If 225 one exists, the server stores this information as part of the 226 allocation state. There is no need for the server to indicate that 227 the attribute was accepted in the success response. 229 3.3. Forming a CreatePermission or ChannelBind Request 231 When sending a CreatePermission or a ChannelBind request, the XOR- 232 OTHER-ADDRESS STUN attribute allows the TURN client to provide an 233 alternate peer address that can be used by the server to identify the 234 network geographic location of the peer when performing the peer- 235 specific redirection check. Use of this attribute is only necessary 236 if the XOR-PEER-ADDRESS already contained in the CreatePermission or 237 ChannelBind request does not adequately serve this purpose, which 238 should only be true when both peers require a TURN relay for end-to- 239 end data flow. In this case, the TURN CreatePermission or 240 ChannelBind request will provide the peer's TURN relay address as the 241 XOR-PEER-ADDRESS value. If the RTT between the peer and its TURN 242 relay server is very small, the TURN relay address might still be an 243 appropriate address to use for the peer-specific redirection check. 244 As the RTT grows, the TURN relay address will become less suitable 245 for this purpose. For this reason, it is generally the case that the 246 peer's public address (i.e. its host or reflexive address) is a 247 better indication of its network geographic location than its TURN 248 relay address. 250 When forming an XOR-OTHER-ADDRESS attribute, the STUN Type is TBD- 251 XOA. To support backward compatibility, this type is in the 252 comprehension-optional range, which means that an [RFC5766] compliant 253 TURN server can safely ignore it. 255 The XOR-OTHER-ADDRESS value specifies an address and port suitable 256 for identification of the peer's network geographic location. It is 257 encoded in the same way as XOR-MAPPED-ADDRESS 258 [I-D.ietf-tram-stunbis]. 260 A CreatePermission request is allowed to contain multiple XOR-PEER- 261 ADDRESS attributes. When multiple peer addresses are provided in a 262 CreatePermission request, it would be difficult for the TURN server 263 to associate an XOR-OTHER-ADDRESS attribute with the correct XOR- 264 PEER-ADDRESS. For this reason, a TURN client MUST form a separate 265 CreatePermission request for an XOR-PEER-ADDRESS request when an XOR- 266 OTHER-ADDRESS attribute will be included in the request. 268 The XOR-OTHER-ADDRESS attribute SHOULD NOT be included in a request 269 if its value will be identical to the request's XOR-PEER-ADDRESS 270 attribute. Its value would be redundant and a waste of space in the 271 message. 273 3.4. Receiving a CreatePermission or ChannelBind Request 275 When a TURN server receives a CreatePermission or ChannelBind request 276 for an allocation that included the CHECK-ALTERNATE attribute, it 277 processes the request as per the TURN specification [RFC5766] plus 278 the specific rules mentioned here. 280 If an XOR-OTHER-ADDRESS attribute is present, the server validates 281 the number of XOR-PEER-ADDRESS attributes. If there is more than one 282 XOR-PEER-ADDRESS attribute in the request, the server MUST reject the 283 request with an error response using error code 400 (Bad Request). 284 If there is only one XOR-PEER-ADDRESS attribute, the request is 285 accepted and the value of the XOR-OTHER-ADDRESS attribute is stored 286 with the permission state for use when checking for an alternate 287 server. 289 The mechanism for deciding when and how to check for an alternate 290 server is implementation dependent. This activity could be timer 291 driven (e.g. check for an alternate server once every 120 seconds), 292 it could be event driven (e.g. check for an alternate server on every 293 permission or binding refresh), or another mechanism appropriate for 294 the internal implementation could be chosen. Likewise, the decision 295 of which specific address(es) to check for alternate servers is also 296 implementation dependent. A server could check for alternates for 297 all active permissions, it could check just for permissions that have 298 relayed non-ICE data, or another selection method appropriate for the 299 implementation could be chosen. 301 When checking for an alternate server for a permission where the XOR- 302 OTHER-ADDRESS attribute was provided, the server SHOULD use this 303 address for peer location identification. Otherwise, the server 304 SHOULD use the XOR-PEER-ADDRESS value. 306 The TURN client will retransmit a CreatePermission or ChannelBind 307 request if the response is not received. [I-D.ietf-tram-stunbis] 308 recommends that the retransmit timeout be greater than 500 ms, but 309 does not require this, so it is important to avoid unnecessary delays 310 in request processing. For this reason, the mechanism for driving 311 alternate server checks SHOULD be asynchronous relative to processing 312 of the associated CreatePermission or ChannelBind request and SHOULD 313 NOT delay transmission of the response message. 315 3.5. Forming a Redirect Indication 317 When an alternate server for a specific permission has been 318 identified, the server notifies the client using a Redirect 319 indication. The server MUST NOT send Redirect indications if the 320 client did not indicate support by including a CHECK-ALTERNATE 321 attribute in its Allocate request. 323 The codepoint for Redirect indication is TBD-RI. 325 A Redirect indication MUST contain a single ALTERNATE-SERVER 326 attribute to provide the address for the alternate server. The 327 message MAY contain one or more XOR-PEER-ADDRESS attributes to 328 indicate a subset of peer addresses for redirection. If all peer 329 addresses are to be redirected, no XOR-PEER-ADDRESS attribute is 330 required. The message MUST contain either a MESSAGE-INTEGRITY or 331 MESSAGE-INTEGRITY-SHA256 attribute (see Section 5 for an explanation 332 of the rationale). 334 Because this message codepoint is for indications only, the TURN 335 client will not send a success response, and the TURN server will 336 have no way to determine whether the message was received. For 337 improved reliability, the TURN server MAY retransmit the indication 338 multiple times, following the request retransmission semantics 339 described in [I-D.ietf-tram-stunbis]. Retransmission requirements 340 for indications might differ from those for requests, since requests 341 are only retransmitted if no response was received. For this reason, 342 an implementation that retransmits Redirect indications SHOULD 343 provide separate configuration settings to control the maximum number 344 of Redirect retransmissions and the minimum RTO. 346 3.6. Receiving a Redirect Indication 348 When a TURN client receives a Redirect indication, it checks that the 349 indication contains both an ALTERNATE-SERVER attribute and one of 350 either a MESSAGE-INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute 351 and discards it if it does not. If XOR-PEER-ADDRESS attributes are 352 present, it checks that all specified addresses are recognized peers 353 for the allocation and discards the indication if any addresses are 354 not recognized. Finally, it verifies the integrity attribute's value 355 and discards the message if that value is invalid. 357 After validating the message, the ALTERNATE-SERVER value and 358 associated peer addresses are delivered to the ICE implementation. 359 Interactions with ICE are described below (Section 4). 361 See Section 5 below for discussion of how the client should respond 362 when receiving a Redirect indication when redirection was not 363 requested. 365 4. ICE Interactions 367 With "Vanilla" ICE as defined in [RFC5245], candidate gathering is 368 complete before the offer/answer exchange. When a client using 369 standard ICE receives a valid Redirect indication, it first checks 370 whether it already has an active allocation on the specified server. 371 If not, it adds the new relay to its list of servers and forms an 372 allocation. This generates a new relayed candidate to be added to 373 the local ICE candidates list, which requires ICE restart. 375 With trickle ICE as defined in [I-D.ietf-ice-trickle], if the end-of- 376 candidates announcement has not yet been sent, it could be possible 377 to complete the TURN Allocate request and include the new relayed 378 candidate in the candidates list for the current ICE negotiation. 379 However, on some implementations, it could be true that candidate 380 gathering is already complete, even though the end-of-candidates 381 announcement hasn't been sent. In other words, a trickle ICE agent 382 might need to restart ICE in order to restart candidate gathering. 383 If the end-of-candidates announcement has already been sent, ICE 384 restart is necessary in order to add the new relayed candidate. 386 It is possible for a TURN relay to send multiple Redirect indications 387 on the same allocation within a short time frame, each for a 388 different set of peers. For example, consider the case of a remote 389 peer with two interfaces, one wifi and the other 4G on a different 390 Internet service provider. It is possible that the network geography 391 for each interface requires a different relay for best performance 392 and therefore a unique Redirect indication. After receiving a 393 Redirect indication that does not apply to all peers associated with 394 the allocation, it might be beneficial for the ICE agent to delay ICE 395 restart by a small interval in order to avoid restarting ICE multiple 396 times within a short time frame. However, selecting a good delay 397 interval could be difficult, since the time between indications could 398 vary due to packet loss and retransmission timeouts. 400 The authors have considered alternative Redirect indication formats 401 that would allow all concurrent redirects to be provided in a single 402 indication, which would avoid the above described issue. Feedback is 403 desired on the question of whether the problem of minimizing ICE 404 restarts is important enough to add greater complexity to the 405 building and parsing of Redirect indications. 407 5. Security Considerations 409 This section considers attacks that are possible in a TURN deployment 410 through the specified protocol extension, and discusses how they are 411 mitigated by mechanisms in the protocol or recommended practices in 412 the implementation. 414 The specified mechanism affects the use of TURN CreatePermission 415 request messages, ChannelBind request messages, and Redirect 416 indication messages. Each of these TURN message types requires a 417 STUN message integrity attribute (either MESSAGE-INTEGRITY or 418 MESSAGE-INTEGRITY-SHA256), which limits attacks that attempt to make 419 use of the specified mechanism to authenticated clients and servers. 421 5.1. Permission Flood 423 A compromised TURN client could send a large number of 424 CreatePermission or ChannelBind request messages with distinct peer 425 address values, which would drive increased load on the TURN server. 426 The mechanism described in this document does not make such an attack 427 more likely, though it could make it possible to increase the impact 428 of such an attack due to the additional load associated with 429 determining whether an alternate server should be used by the client. 430 The TURN server MAY be configured to disable or rate limit alternate 431 server checks under some conditions in order to limit the associated 432 load. The conditions under which it is appropriate for a TURN server 433 to ignore disable or rate limit such checks are implementation 434 dependent. 436 5.2. Unsolicited or Invalid Redirect Indication 438 A compromised TURN server could send Redirect indications for 439 allocations that did not include the CHECK-ALTERNATE attribute. For 440 a client that does not support this mechanism, receiving such 441 indications is no worse than receiving messages with any other 442 unrecognized message type. A client that recognizes the message type 443 MUST ignore Redirect indications for allocations where CHECK- 444 ALTERNATE was not specified, and in particular, to avoid unnecessary 445 authentication overhead, the client SHOULD drop such indications 446 before attempting to validate the message integrity attribute. 448 A compromised TURN server could send an invalid ALTERNATE-SERVER 449 attribute value in a Redirect indication message, where the value 450 refers to an unaffiliated TURN server to which the sending TURN 451 server is not allowed to redirect traffic. Such an attack is already 452 allowed by the use of Try Alternate errors in response to Allocate 453 request messages. Use of the ALTERNATE-SERVER attribute in the 454 context of peer-specific redirection does not make such an attack 455 more likely, though it could make it possible to increase the scale 456 of such an attack by allowing multiple ALTERNATE-SERVER attributes to 457 each client, one per requested permission or binding. A client 458 SHOULD ignore all future Redirect indications received from the TURN 459 server after an authentication failure with any server identified via 460 an ALTERNATE-SERVER attribute. A client MAY discontinue use of the 461 associated TURN allocation after an authentication failure with any 462 server identified via an ALTERNATE-SERVER attribute. 464 An external attacker could send an invalid ALTERNATE-SERVER attribute 465 value in a Redirect indication message. The client must have some 466 way to detect when this occurs, which is the purpose of including a 467 message integrity attribute in the Redirect indication. Without the 468 message integrity attribute, it would be possible for an attacker to 469 spoof a Redirect indication from the TURN server and drive the client 470 to attempt to connect to a bad relay server. 472 5.3. Replayed Redirect Indication 474 An in-path attacker could capture and replay Redirect indications. 475 If the client has been redirected again after the replayed Redirect 476 indication was received, the replay could drive the client to carry 477 out unnecessary work to establish a new allocation and restart ICE if 478 the results of the previous Redirect indication have since been 479 discarded. It could also drive unexpected load from the client to a 480 server that has since become overloaded, potentially degrading 481 performance for not only the target client but also all others now 482 connected to the alternate server. 484 Multiple potential mitigations for this attack exist. For example, a 485 client that maintains a complete list of all TURN servers used 486 throughout the life of the session could keep track of the 487 Transaction ID for each Redirect indication received, which would 488 allow the client to recognize and reject a replayed indication. 489 Alternatively, a client could rate-limit its responses to Redirect 490 indications, requiring a configurable interval to expire between 491 Redirect indications before accepting a new one. 493 The authors have also considered the option of adding a timestamp 494 attribute to the Redirect indication message. The timestamp could be 495 used to minimize the window of opportunity for a Redirect indication 496 replay attack. However, such use of timestamps is fragile in the 497 presence of potential clock skew problems between the client and the 498 server and so has not been included in the specification. 500 6. IANA Considerations 502 [Paragraphs below in braces should be removed by the RFC Editor upon 503 publication] 505 [The CHECK-ALTERNATE attribute requires that IANA allocate a value in 506 the "STUN Attributes Registry" from the comprehension-optional range 507 (0x8000-0xFFFF), to be replaced for TBD-CA throughout this document] 509 This document defines the CHECK-ALTERNATE STUN attribute, described 510 in Section 3.1. IANA has allocated the comprehension-optional 511 codepoint TBD-CA for this attribute. 513 [The XOR-OTHER-ADDRESS attribute requires that IANA allocate a value 514 in the "STUN Attributes Registry" from the comprehension-optional 515 range (0x8000-0xFFFF), to be replaced for TBD-XOA throughout this 516 document] 518 This document defines the XOR-OTHER-ADDRESS STUN attribute, described 519 in Section 3.3. IANA has allocated the comprehension-optional 520 codepoint TBD-XOA for this attribute. 522 [The Redirect indication codepoint requires that IANA allocate a 523 value in the "STUN Methods Registry", to be replace for TBD-RI 524 throughout this document.] 526 This document defines the Redirect indication method type, described 527 in Section 3.5. IANA has allocated the codepoint TBD-RI for this 528 method type. 530 7. Acknowledgements 532 Many thanks to J. Uberti for his suggestions regarding ICE 533 interactions. 535 8. References 537 8.1. Normative References 539 [I-D.ietf-tram-stunbis] 540 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 541 D., Mahy, R., and P. Matthews, "Session Traversal 542 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-04 543 (work in progress), March 2015. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 547 RFC2119, March 1997, 548 . 550 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 551 Relays around NAT (TURN): Relay Extensions to Session 552 Traversal Utilities for NAT (STUN)", RFC 5766, DOI 553 10.17487/RFC5766, April 2010, 554 . 556 8.2. Informative References 558 [I-D.ietf-ice-trickle] 559 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 560 "Trickle ICE: Incremental Provisioning of Candidates for 561 the Interactive Connectivity Establishment (ICE) 562 Protocol", draft-ietf-ice-trickle-00 (work in progress), 563 October 2015. 565 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 566 (ICE): A Protocol for Network Address Translator (NAT) 567 Traversal for Offer/Answer Protocols", RFC 5245, DOI 568 10.17487/RFC5245, April 2010, 569 . 571 Appendix A. Change History 573 [Note to RFC Editor: Please remove this section prior to 574 publication.] 576 A.1. Changes from version 03 to 04 578 Introduced Redirect indication to redefine the mechanism as push-like 579 notification. 581 Moved CHECK-ALTERNATE to Allocation request. 583 Added a short section on ICE interactions. 585 Changed STUN reference to STUNbis, since the doc now references 586 STUNbis content. Left other references as they are. 588 A.2. Changes from version 02 to 03 590 Minor copy-editing. 592 A.3. Changes from version 01 to 02 594 Add warning about the difference between physical geography and 595 network geography. 597 Add load balancing use case. 599 A.4. Changes from version 00 to 01 601 Expand discussion of when/how to use CHECK-ALTERNATE and XOR-OTHER- 602 ADDRESS. 604 Authors' Addresses 606 Brandon Williams 607 Akamai, Inc. 608 8 Cambridge Center 609 Cambridge, MA 02142 610 USA 612 Email: brandon.williams@akamai.com 614 Tirumaleswar Reddy 615 Cisco Systems, Inc. 616 Cessna Business Park, Varthur Hobli 617 Sarjapur Marathalli Outer Ring Road 618 Bangalore, Karnataka 560103 619 India 621 Email: tireddy@cisco.com