idnits 2.17.1 draft-martinsen-tram-ssoda-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 17, 2014) is 3693 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) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Uberti 5 Expires: September 18, 2014 Google 6 O. Moskalenko 7 public project rfc5766-turn-server 8 March 17, 2014 10 Single SOcket Dual Allocation with TURN 11 draft-martinsen-tram-ssoda-00 13 Abstract 15 This draft describes a simple method for allocating one IPv4 and one 16 IPv6 relay address from a single ALLOCATE request to the TURN server. 17 This saves local ports on the client, reduces the number of 18 candidates gathered by the client, and reduces the number of messages 19 sent between the client and the TURN server. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Creating an Allocation . . . . . . . . . . . . . . . . . . . 3 63 2.1. Sending an Allocate Request . . . . . . . . . . . . . . . 3 64 2.2. Receiving an Allocate Request . . . . . . . . . . . . . . 3 65 2.3. Receiving an Allocate Success Response . . . . . . . . . 4 66 2.4. Receiving an Allocate Error Response . . . . . . . . . . 5 67 3. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 5 68 3.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 5 69 3.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 70 3.3. CreatePermission . . . . . . . . . . . . . . . . . . . . 6 71 3.3.1. Sending a CreatePermission Request . . . . . . . . . 6 72 3.3.2. Receiving a CreatePermission Request . . . . . . . . 6 73 4. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 The main motivation for this draft is to reduce the number of local 81 ports on the client, reduce the number of candidates gathered during 82 the discovery process, and reduce the number of messages that need to 83 be exchanged to allocate the relay addresses needed for ICE. 85 Reducing the number of local ports is important as it saves resources 86 at three places in the network. First, the number of open ports on 87 the client is reduced, leading to fewer host candidates. Secondly, 88 with fewer local host ports there will be fewer NAT bindings for the 89 NAT to keep track of, and fewer server reflexive candidates. Lastly, 90 with a single 5-tuple in use, it reduces the number of open ports the 91 TURN server needs to open on the interface towards the client 92 (Private side). As ports are a scarce resource (16-bit number) 93 preserving them on the NAT and a the TURN server can make large scale 94 deployments easier. 96 2. Creating an Allocation 98 The behavior specified here affects the processing defined in 99 Section 6 of [RFC5766] and Section 4 of [RFC6156]. 101 2.1. Sending an Allocate Request 103 A client that wishes to obtain one IPv6 and one IPv4 by sending one 104 Allocate request MUST include two REQUESTED-ADDRESS-FAMILY 105 attributes, one for each address family, in the Allocate request that 106 it sends to the TURN server. The order of the REQUESTED-ADDRESS- 107 FAMILY is arbitrary, because the server either understands SSODA 108 (then the order does not matter) or the server does not understand 109 SSODA (then the server bahavior is undefined - it may return a 400 110 error, or it may take the first attribute, or it may take the last 111 attribute). Multiple candidates of the same family are not 112 supported; the client MUST NOT include more than one REQUESTED- 113 ADDRESS-FAMILY attribute for a given address family. The mechanism 114 to formulate an Allocate request is described in Section 6.1 of 115 [RFC5766]. 117 Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an 118 Allocate request that contains a RESERVATION-TOKEN or an EVEN-PORT 119 attributes. The SSODA mechanism is not available when using the odd/ 120 even port allocation scheme. 122 2.2. Receiving an Allocate Request 124 Once a server has verified that the request is authenticated and has 125 not been tampered with, the TURN server processes the Allocate 126 request following the rules in [RFC5766] and [RFC6156].. Only one 127 REQUESTED-ADDRESS-FAMILY attribute with the same family value is 128 allowed in the request. If two attributes with the same family value 129 exist the server MUST return 400 Bad Request error. 131 If no REQUESTED-ADDRESS-FAMILY attributes are present, the server 132 MUST treat this as if the request contained a single REQUESTED- 133 ADDRESS-FAMILY specifying the IPv4 address family. 135 If the server can successfully process the request, it allocates a 136 relay address for each of the REQUESTED-ADDRESS-FAMILY attributes 137 present in the Allocate request. The allocated relay addresses are 138 returned in separate XOR-RELAYED-ADDRESS attributes in the Allocate 139 response message. The ordering of the XOR-RELAYED-ADDRESS attributes 140 in the response is arbitrary. 142 If the server cannot satisfy the request at all, because none of the 143 specified address families are supported, the server MUST return a 144 440 error code, as indicated in [RFC6156]. 146 If the server cannot satisfy the request at all, because the server 147 could not allocate any of the specified addresses, the server MUST 148 return a 508 (Insufficient Capacity) error code as indicated in 149 [RFC5766]. 151 If some of the requested address could be allocated, but some could 152 not, either because the requested address family is not supported, or 153 the server currently lacks capacity, the server MUST indicate this 154 partial success by returning an Allocate Success Response that 155 contains XOR-RELAYED-ADDRESS attributes for the addresses that were 156 successfully allocated, as well as XOR-RELAYED-ADDRESS with ANY 157 addresses (that is, IPv4 address 0.0.0.0:0 or IPv6 address [::0]:0) 158 corresponding to the address families that could not be allocated. 159 This will notify the client that the desired REQUESTED-ADDRESS-FAMILY 160 was understood, but could not be allocated. A success response with 161 ANY addresses MUST NOT be returned if all allocation requests cannot 162 be satisfied; instead, an error response should be returned, as 163 indicated above. 165 This somewhat unusual pattern of partial success is used to avoid the 166 need for an additional roundtrip when the client just wants whatever 167 address families the TURN server supports. 169 Note that while allocating multiple address families at the same time 170 is supported, doing this sequentially is not. The server MUST reject 171 any attempt to "add" an address family to an existing allocation with 172 a 437 (Allocation Mismatch) error code. 174 [OPEN ISSUE 1: do we need to include REQUESTED-ADDRESS-FAMILY 175 attribute(s) with failed address family (or families) to help the 176 client to recognize whether this is an "old" non-SSODA server or a 177 "new" SSODA-supporting server ?] 179 [OPEN ISSUE 2: do we have to consider a particular ordering of 180 REQUESTED-ADDRESS-FAMILY and REQUESTED-ADDRESS-FAMILY attributes in 181 the ALLOCATE request and response ? Can attribute ordering provide 182 some benefits in this case ?] 184 2.3. Receiving an Allocate Success Response 186 This section describes how the client must react on receiving a 187 response to the dual allocation request. If the client is not using 188 dual allocation, then the behavior is the same as the rules in 189 [RFC5766] and in [RFC6156]. 191 If the client receives an Allocate Success Response containing a non- 192 ANY (ANY as defined above) XOR-RELAYED-ADDRESS attribute for each of 193 the REQUESTED-ADDRESS-FAMILY attributes in the Allocate request sent 194 by the client, the client knows that the TURN server supports 195 multiple address family allocation over a single socket. All relay 196 addresses can now be used by the client. 198 If the Allocate response contains both usable XOR-RELAYED-ADDRESS 199 attributes as well as ANY XOR-RELAYED-ADDRESS attributes, then the 200 client knows that the TURN server "understands" dual allocation SSODA 201 request, but the server either does not support one of the requested 202 address families or cannot currently allocate an address of that 203 family. The allocated non-ANY address can be used, but the client 204 SHOULD NOT try to allocate any of the unsupported families on a 205 different 5-tuple. 207 If the Allocate Response contains only one XOR-RELAYED-ADDRESS 208 attribute, then the client knows that the TURN server does not 209 support SSODA. The client can retry the missing address family 210 allocations on new 5-tuples, if desired. Subsequent Allocate 211 requests towards the same TURN server SHOULD NOT include multiple 212 REQUESTED-ADDRESS-FAMILY attributes. 214 2.4. Receiving an Allocate Error Response 216 When doing dual allocation, if the client receives an Allocate error 217 response with the 440 (Unsupported Address Family) error code, then 218 the client knows that the TURN server does not support any of the 219 desired address families, or might be a non-SSODA server that 220 misinterpreted the included REQUESTED-ADDRESS-FAMILY attributes in 221 the Allocate request. The client SHOULD retry its IPv4 request on 222 the same 5-tuple, with no REQUESTED-ADDRESS-FAMILY attribute, and MAY 223 retry other address families on different local ports, by sending an 224 Allocate request with only one REQUESTED-ADDRESS-FAMILY attribute. 226 3. Refreshing an Allocation 228 The behavior specified here affects the processing defined in 229 Section 7 of [RFC5766] and Section 5 of [RFC6156]. This section MUST 230 only be used if the client has verified that the TURN server supports 231 SSODA during the allocation creation described in Section 2.1. 232 Otherwise, revert back to RFC 5766 or RFC 6156 behaviour. 234 3.1. Sending a Refresh Request 236 To perform an allocation refresh, the client generates a Refresh 237 Request as described in Section 7.1 of [RFC5766]. When refreshing a 238 dual allocation, the client SHOULD include one or more REQUESTED- 239 ADDRESS-FAMILY attributes describing the the family types that should 240 be refreshed; the client MUST only include family types that it 241 previously allocated and has not yet deleted. When refreshing a 242 (single) allocation on a server that does not not support SSODA, 243 REQUESTED-ADDRESS-FAMILY should be omitted, for backwards 244 compatibility. 246 This process can also be used to delete an allocation of a specific 247 address type, by setting the lifetime of that refresh request to 0. 248 It is possible to delete one or more allocations depending on how 249 many REQUESTED-ADDRESS-FAMILY attributes are included. Deleting a 250 single allocation destroys any permissions or channels associated 251 with that particular allocation; it MUST NOT affect any permissions 252 or channels associated with allocations for other address families. 254 3.2. Receiving a Refresh Request 256 The server refreshes the allocated address families that match the 257 supplied REQUESTED-ADDRESS-FAMILY values. If any of the values in 258 the request do not match a currently allocated address, the server 259 MUST respond with a 437 (Allocation Mismatch) error. [OPEN ISSUE: 260 discuss whether this is the right error code for the situation] If no 261 REQUESTED-ADDRESS-FAMILY is present, the request should be treated as 262 applying to all current allocations, for backward compatibility. 264 The server MUST then refresh or delete the specified allocations, and 265 return a Refresh Success Response. 267 3.3. CreatePermission 269 The behavior specified here affects the processing defined in 270 Section 9 of [RFC5766] and Section 6 of [RFC6156] 272 3.3.1. Sending a CreatePermission Request 274 The client MUST only include XOR-PEER-ADDRESS attributes with 275 addresses that match an address family of one of the currently 276 allocated addresses. 278 3.3.2. Receiving a CreatePermission Request 280 If an XOR-PEER-ADDRESS attribute contains an address of an address 281 family different than that any of the relayed transport addresses 282 allocated, the server MUST generate an error response with the 443 283 (Peer Address Family Mismatch) response code, which is defined in 284 Section 6.2.1 of [RFC6156]. 286 4. Channels 288 The session channels setup process follows the same rules as in 289 [RFC5766] and in [RFC6156]; the client is allowed to set up multiple 290 channels within the same 5-tuple session. However, when using SSODA 291 and dual allocation, the peer addresses of those channels may be of 292 different families. Thus, a single 5-tuple session may create 293 several IPv4 channels and several IPv6 channels. 295 5. Acknowledgements 297 Authors would like to thank Simon Perreault for providing ideas 298 direction and insight. 300 6. Normative References 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 306 Relays around NAT (TURN): Relay Extensions to Session 307 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 309 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 310 Using Relays around NAT (TURN) Extension for IPv6", RFC 311 6156, April 2011. 313 Authors' Addresses 315 Paal-Erik Martinsen 316 Cisco Systems, Inc. 317 Philip Pedersens vei 20 318 Lysaker, Akershus 1366 319 Norway 321 Email: palmarti@cisco.com 323 Justin Uberti 324 Google 325 Kirkland, WA 326 USA 328 Email: justin@uberti.name 329 Oleg Moskalenko 330 public project rfc5766-turn-server 331 Walnut Creek, CA 332 USA 334 Email: mom040267@gmail.com 335 URI: https://code.google.com/p/rfc5766-turn-server/