idnits 2.17.1 draft-takeda-symmetric-nat-traversal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 24 instances 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TRY' on line 689 -- Looks like a reference, but probably isn't: 'FROM' on line 488 -- Looks like a reference, but probably isn't: 'TO' on line 488 -- Looks like a reference, but probably isn't: 'MAPPED-ADDRESS' on line 689 -- Looks like a reference, but probably isn't: 'NAT' on line 340 -- Looks like a reference, but probably isn't: 'Host' on line 340 == Unused Reference: '3' is defined on line 980, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 983, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 986, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 989, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 993, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-00 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-00 ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MIDCOM WG 3 Internet Draft Y.Takeda 4 draft-takeda-symmetric-nat-traversal-00.txt Panasonic Communications 5 Category: Informational Research Laboratory 7 Symmetric NAT Traversal using STUN 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026 except that the right to produce derivative 15 works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 It is generally known that the binding acquisition for symmetric NATs 36 with STUN (Simple Traversal of UDP through NATs) protocol will not 37 yield a usable address for traversing symmetric NAT. The use of 38 symmetric RTP allows you to accompolish symmetric NAT traversal only 39 in situations where the other end is open to the Internet, or has a 40 full-cone or a restricted-cone NAT. This document proposes an 41 analytical method for symmetric NATs to obtain more detailed 42 characteristics of the symmetric NAT using STUN, and describes how we 43 can establish a peer-to-peer UDP connection even in situations where 44 NATs (including symmetric NATs) are present at both ends. 46 1 Introduction 48 STUN is a useful tool to discover the presence and characteristics of 49 Network Address Translators (NATs). (It does not support 'traversal' 50 by itself.) It is generally known that the binding acquisition for 51 symmetric NATs, with STUN, will not yield a usable address, and in 52 cases that the other end also has a port restricted-cone NAT or 53 symmetric NAT, there is no possible way to traverse these NATs. 55 We have discovered in our NAT characteristics research, that the 56 number of symmetric NATs deployed in the market is significant even 57 in the residential market. This is a significant issue, especially 58 for service providers or manufacturers who are seriously looking for 59 a solution to the actual NAT issues they have. 61 TURN (Traversal Using Relay NAT)[2] has been proposed to complement 62 the limitation of STUN, however, this type of solution requires a 63 relay server somewhere on the public network, which is an additional 64 cost for service providers. It is important that service providers 65 reduce the amount of server deployments as much as possible. 67 This document proposes an analytical method for symmetric NATs to 68 obtain more detailed characteristics of symmetric NATs using STUN, 69 and describes how we can establish a peer-to-peer UDP connection even 70 in situations where the NATs (including symmetric NATs) are present 71 at both ends. The operation is based upon a prediction of a set of IP 72 address and port that a symmetric NAT will allocate. However, the 73 discovery processes proposed in this document, using STUN, produce a 74 fairly good success rate of symmetric NAT traversal. As a result, it 75 will significantly reduce the requirement for relay servers. 77 This document does not provide any specific protocol, nor a proposal 78 for any modifications to current STUN protocol. In order to 79 incorporate the method described in this document into existing 80 protocols (e.g. SDP), those protocols will need to be modified. It 81 is expected that this method be appropriately examined in this public 82 community to yield improvements and as motivation for applying it to 83 both old and new protocols. 85 2 Terminology 87 NAT - Network Address Translation 88 RTP - Real-time Transfer Protocol 89 SDP - Session Description Protocol 90 STUN - Simple Traversal of UDP through NATs 91 TURN - Traversal Using Relay NATs 92 UDP - User Datagram Protocol 94 3 Network Configuration 96 The assumption in this document is based upon what is shown in Figure 97 3.1, in that there are one or more NATs at both endpoints(EP-a and 98 EP-b) that wish to communicate to each other directly through the 99 NATs. In order to get information about the NATs, each endpoint uses 100 a STUN server located on the public network. 102 STUN Server 103 +-----+ 104 NAT NAT | | NAT NAT 105 +-+ +-+ +--+--+ +-+ +-+ 106 +----+ | | | | | | | | | +----+ 107 |EP-a|---+ +...+ +---((Public Network))---+ +...+ +---|EP-b| 108 +----+ | | | | | | | | +----+ 109 +-+ +-+ +-+ +-+ 111 Figure 3.1 Network Configuration 113 4 NAT Behavior Analogy 115 An analogy is provided here to aid in the explanation of how the 116 various NATs operate. It is assumed that readers of this document are 117 familiar with STUN protocol[1] and have a good understanding of NAT 118 behaviors. 120 The analogy is presented in terms of a doorman to a building 121 (corresponding to a private network) in which a tenant (an endpoint 122 device) is present. A NAT acts just like a wall of the building. 123 Until the tenant sends a packet to the outside, there are no doors on 124 the wall of the building. When the tenant in the building sends a 125 packet, a door on the wall will be created with a doorman. The NAT 126 behavior can be characterized in different ways depending on the 127 doorman's role and the rules that created the door. 129 Full-cone NAT: 131 A door will be created when a tenant(endpoint) in a building 132 sends a packet for the first time. In the case of a full-cone 133 NAT, the doorman standing at the door checks if each packet 134 trying to come in is visiting the tenant who created this door. 135 The doorman, however, does not check where each packet 136 originates. 138 Restricted-cone NAT: 140 A door will be created when a tenant(endpoint) in a building 141 sends an invitation letter (a packet) for the first time to 142 another building. In this case, the doorman will check if each 143 person (packet) trying to come in is visiting the tenant who 144 created this door. The doorman also checks if visitors came from 145 the building that received the invitation letter from the 146 tenant. 148 Port restricted-cone NAT: 150 A door will be created when a tenant(endpoint) in a building 151 sends an invitation letter (a packet) for the first time to a 152 tenant in another building. The doorman will check if each 153 person trying to enter is visiting the tenant who created the 154 door. The doorman also checks if they have received the 155 invitation letter from the tenant. 157 Symmetric NAT: 159 A door will be created every time when a tenant(endpoint) in a 160 building sends an invitation letter (a packet) to a new tenant 161 in another building. The doorman will check if each one trying 162 to come in is visiting the tenant who created the door. The 163 doorman also checks if they have received the invitation letter 164 sent from him through this door. 166 What makes NAT traversal difficult with symmetric NAT is the 167 door creation rule. In other (non-symmetric) cases, the same 168 door will be used whenever the same tenant in a building sends 169 an invitation packet to a different destination. In symmetric 170 NAT , a new door will be always created every time the tenant in 171 the building sends an invitation packet. Therefore, when you 172 want to talk to Mr.A and Mr.B at the same time, for example, the 173 door to let Mr.A enter is always different from the one to let 174 Mr.B enter. With STUN, the tenant sends an invitation packet to 175 the STUN server (binding request) and the STUN server sends back 176 a reply with the location of the door (MAPPED-ADDRESS) used to 177 send the invitation, so that the tenant will know which door on 178 the NAT can be used for other parties to enter. However, if the 179 NAT is symmetric, the door obtained from the STUN server is not 180 the same as the door that will be used for other parties to 181 enter. 183 In this analogy, a 'tenant' is used to represent a local UDP port. 184 It should be noted that several tenants comprise a 'company'. The IP 185 address represents a company in the 'building'. To recap, each 186 building (LAN behind a NAT) has multiple companies (IP addresses) 187 made up of many tentants (UDP ports). The trick to traverse NAT with 188 UDP is to utilize the 'invitation letter (packet)". This will create 189 a door for visitors outside the building to come in. The invitation 190 packet is not necessarily a 'special' invitation packet. The first 191 part of data transmission works as an invitation because it creates a 192 door and a doorman as a result. STUN protocol provides us with a way 193 to ascertain the doorman's role and the door creation rule. 195 5 NAT Combination Classification & Current Approach 197 The following chart shows combinations of NATs at each endpoint with 198 the current NAT type definitions in STUN. The combinations are 199 classified into 4 groups: Class I, II, III and IV. 201 +----------+-----+-----+-----+-----+-----+ 202 |\ EP-R| | | | | | 203 | -------- |Open | F | P | PR | SYM | 204 |EP-S \| | | | | | 205 |----------+-----+-----+-----+-----+-----+ 206 | Open | | | | 207 |----------+ | | | 208 | F | | |(III)| 209 |----------+( I )| ( II ) | | 210 | P | | | | 211 |----------+ | +-----+ 212 | PR | | | | 213 |----------+ | +-----+ | 214 | SYM | | | (IV) | 215 +----------+-----------------+-----------+ 216 Note: 217 EP-S: Sending endpoint. 218 EP-R: Receiving endpoint. 219 (In full-duplex, both EP-a and EP-b in Figure 3.1 220 will have both EP-S and EP-R) 221 Open: Open to public network (no NAT) 222 F : Full-cone NAT 223 R : Restricted-cone NAT 224 PR : Port restricted-cone NAT 225 SYM : Symmetric NAT 227 Figure 5.1 NAT Combination Classification 229 Class I is a case in which the receiver does not have a NAT. There is 230 no actual NAT issue here because receiver side has no NAT and has a 231 routable IP address to receive packets. 233 Class II is a case in which the receiver has a non-symmetric NAT and 234 the sender has no NAT or any type of NATs except the case in which 235 the receiver has a port restricted symmetric NAT and sender has a 236 symmetric NAT. In order to traverse the NAT in this case, the 237 receiver sends an invitation packet to the sender so that the doorman 238 will not block any packets sent from the receiver of the invitation 239 packet. 241 Class III involves a symmetric NAT at the receiver. There is a full- 242 cone or restricted-cone NAT at the sender side. The problem in this 243 case is that STUN is not able to provide a valid MAPPED-ADDRESS of 244 the symmetric NAT for EP-S to send packet. EP-S can send an 245 invitation packet to the MAPPED-ADDRESS on EP-R side NAT. This will 246 cause an existing allocated port on EP-S side NAT to accept incoming 247 packets sent from the MAPPED-ADDRESS on the EP-R side NAT. EP-R will 248 also send an invitation packet to EP-S and the EP-S can record the 249 source IP address and port number of the received packet to send 250 packets back to the recorded address/port. This source address 251 recording technique is known as "symmetric RTP"[3],[4]. 253 Class IV is the case that this document addresses. The problem here 254 is that STUN is not able to provide a valid MAPPED-ADDRESS for the 255 symmetric NAT. Therefore, the other endpoint cannot send an 256 invitation packet to the symmetric NAT. As a result, the symmetric 257 RTP solution is not applicable here either. A key solution to this 258 class IV traversal is to do further analysis on the symmetric NAT and 259 make the invalid MAPPED-ADDRESS useful. The details are described in 260 the following sections. 262 6 More About Symmetric NAT Behavior 264 6.1 Port Allocation Behavior 266 A symmetric NAT allocates different mapping (MAPPED-ADDRESS) when a 267 new request is sent to a different destination, although it is sent 268 from the same internal IP address and port. In the non-symmetric 269 case, the same MAPPED-ADDRESS is always used. The following is a 270 typical example of the port assignment behavior of the symmetric NAT. 271 In this example, 4 packets (TRY-1 thru -4) are sent to a different 272 destination from the same internal IP address and port. TRY-1 and 2 273 send a packet to different port numbers of the same IP address. TRY-3 274 and -4 do so but to a different IP address from the one in TRY-1 and 275 -2. 277 [TRY] [FROM] [TO] [MAPPED-ADDRESS] 278 1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152 279 2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49153 (49152+1) 280 3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49154 (49153+1) 281 4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49155 (49154+1) 283 The symmetric NAT allocates a new MAPPED-ADDRESS, however the 284 increment size of its port number, called 'delta p', is, in most 285 cases constant. In the example above, the delta p value is '+1'. It 286 is known that delta p takes on another value other than '+1', as in 287 the example below. 289 [TRY] [FROM] [TO] [MAPPED-ADDRESS] 290 1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152 291 2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49154 (49152+2) 292 3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49156 (49154+2) 293 4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49158 (49156+2) 295 With regard to port allocation behavior, since the symmetric NAT 296 shown above allocates a new MAPPED-ADDRESS every time a packet is 297 sent to a different IP address or port, this allocation behavior is 298 called 'port sensitive' allocation. 300 It is also known that there is another type of port allocation 301 behavior as follows. 303 [TRY] [FROM] [TO] [MAPPED-ADDRESS] 304 1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152 305 2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49152 306 3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49153 (49152+1) 307 4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49153 308 5 192.168.1.2:4136 65.12.66.12:3478 67.105.12.10:49154 (49153+1) 309 6 192.168.1.2:4136 65.12.66.12:3479 67.105.12.10:49154 310 7 192.168.1.2:4136 65.12.66.13:3478 67.105.12.10:49155 (49154+1) 311 8 192.168.1.2:4136 65.12.66.13:3479 67.105.12.10:49155 313 This symmetric NAT behaves, in terms of port allocation rule, like a 314 cone (non-symmetric) NAT when packets are sent to different ports of 315 the same IP address. But when the packets are sent to the different 316 IP addresses for the first time, it will assign a new MAPPED-ADDRESS. 318 This port allocation rule is called 'address sensitive' allocation. 319 Even in this case the port increment size, delta p, is likely to be 320 constant. 322 The consistency of delta p is very important in order to traverse 323 symmetric NAT. If an IP device behind a symmetric NAT knows the 324 value of delta p and its consistency, the IP device can predict the 325 next port number to be assigned by the symmetric NAT from the MAPPED- 326 ADDRESS. The prediction, however, can fail. 328 One of the scenarios for prediction failure would be that another PC 329 behind the same symmetric NAT created a new binding during the 330 prediction process. Specifically, if there are multiple network 331 applications running behind the same symmetric NAT, ap1 and ap2 shown 332 in Figure 6.1 for example, ap1 first obtains a MAPPED-ADDRESS from 333 STUN server (t0). Right after, ap2 starts talking to a remote host 334 with UDP that causes another binding creation on the NAT (t1). The 335 ap1 makes a prediction from the obtained MAPPED-ADDRESS but the 336 predicted port number has just been taken by ap2. Eventually, ap1 337 sends a packet to a remote host (at t2) but the allocated port by the 338 NAT for this transmission is not the one that the ap1 has predicted. 340 [ap1] [ap2] [NAT] [STUN Server] [Host] [Host] 341 | | | | | | 342 | | t0| Binding Request | | | 343 +-------------+------------------>| | | 344 | | | | | | 345 | | | MAPPED-ADDRESS | | | 346 |<------------+-------------------+ | | 347 | | | | | | 348 | | t1| Packet sent | | | 349 | +------+------------------------------------->| 350 | | | | | | 351 | | t2| Packet sent | | | 352 +-------------+------------------------------>| | 353 | | | | | | 355 Figure 6.1 Prediction Failure Case A 357 The critical time period for the correct prediction is between t0 and 358 t2. Prediction failure rate is determined by binding occurrence 359 probability by another application behind the same NAT during the 360 time period. Success rate can be maximized by minimizing the length 361 of the time period. 363 Typically, a symmetric NAT allocates a port for a new binding from a 364 specific range of ports. (e.g. 0xC000 - 0xCFFF) In most cases, the 365 allocation starts from the beginning of the port range and when it 366 hits the bottom of the range, it will start over from the beginning. 368 This port assignment method of NAT is called "incremental 369 allocation". With the incremental allocation, there usually is a 370 table that keeps the status of each port in the NAT. The table has a 371 status flag that shows whether or not the associated port is in use. 372 The symmetric NAT, when a new binding is being created, looks for the 373 next available port number by looking at the status flag. If it is in 374 use, it will skip the port and look at the next port. If the 375 prediction is made right before the skip occurs, the prediction will 376 fail. This may happen if there are a number of IP devices connected 377 behind the same NAT and noticeable amounts of UDP transactions are 378 being made. 380 In contrast to the incremental allocation, there is another 381 allocation method, called "queued resource allocation". In this 382 method, a predetermined range of port numbers are stored in a queue 383 (FIFO) in an orderly fashion at the initial phase. When a binding 384 occurs, a port number will be read from the queue to be allocated for 385 the binding. After the binding is released, the port number will be 386 returned back into the queue. Since the length of the binding life- 387 time varies, the order of the returned port numbers will not be 388 continuous. That means, the order of the port numbers in the queue 389 will be shuffled gradually and start losing continuity, which makes 390 port prediction very difficult. 392 Here is a summary for possible reasons for port prediction failure: 394 (a) Another binding occurrence between t0 and t2. 395 (b) Hit the bottom of the port range. (incremental allocation) 396 (c) High UDP usage in the local network. 397 (d) Random port allocation (typically with queued resource allocation) 399 In order to prevent port prediction failure, the following solutions 400 can be taken: 402 - Minimize the time length between t0 and t1. - for (a) 403 - Implement a retry process. - for (a), (b), (c) 404 - Multiple port prediction. (see 8.4) - for (a), (b), (c) 406 There is no practical solution for (d) at this moment. There might be 407 a way to recover the port number continuity in the queue by 408 manipulating allocation and release timings of the bindings of the 409 NAT, however, it might have other disruptive factors caused by the 410 non-norm NAT world. 412 6.2 Incoming Packet Filtering 413 Another factor that characterizes symmetric NAT behavior is the 414 incoming packet filter type. Once a MAPPED-ADDRESS is allocated on 415 the symmetric NAT for an internal device, the allocated port will 416 accept incoming packets sent from an IP address and port to where the 417 device has previously sent packets. There can be a symmetric NAT that 418 accepts incoming packets sent from other external endpoints, just 419 like a full-cone NAT or a restricted-cone NAT, in terms of incoming 420 packet filtering. 422 The current STUN discovery process assumes that a symmetric NAT does 423 not route incoming packets sent from other IP addresses and/or ports 424 other than one to which an internal device previously sent a packet. 425 In fact, with the STUN discovery process, a symmetric NAT that 426 accepts packets from other IP addresses will result in a full-cone 427 NAT. 429 The sensitivity, in terms of the incoming packet filter, to a source 430 IP address and port number of the incoming packet needs to be 431 evaluated as well as the port allocation rule. If the incoming 432 packets are examined by the sender's IP address and port number, this 433 is called 'port sensitive' filtering. If the packets are examined by 434 the sender's IP address only, it is called, 'address sensitive' 435 filtering. 437 6.3 NAT Characteristics Classification 439 As discussed in section 6.1 and 6.2, symmetric behavior can be 440 characterized with two parameters as follows: 442 (1) Port Allocation Rule (door creation rule) 443 (2) Incoming Packet Filter (doorman's role) 445 These parameters can be applied to non-symmetric NATs, as well. The 446 following chart shows all the possible NAT characteristics evaluated 447 with the two parameters mentioned above. 449 Table 6.3.1 NAT Characteristics Classification 450 +----------------------+-----------------------------------+ 451 | | Incoming Packet Filter | 452 | |-----------------------------------| 453 | | No Filter | AS Filter | PS Filter | 454 +----------+-----------+-----------+-----------+-----------+ 455 | | Cone | Full-cone |Restricted-|Port restr-| 456 | Port | | |cone |icted-cone | 457 |Allocation|-----------+-----------+-----------+-----------| 458 | Rule | AS | Symmetric | Symmetric | Symmetric | 459 | | Symmetric | (a) | (b) | (c) | 460 | |-----------+-----------+-----------+-----------| 461 | | PS | Symmetric | Symmetric | Symmetric | 462 | | Symmetric | (d) | (e) | (f) | 463 +----------------------+-----------------------------------+ 464 (NOTE) AS: Address Sensitive, PS: Port Sensitive 466 All the non-symmetric NATs are categorized as 'cone' NAT. There are 467 three types of cone NATs corresponding to the three incoming packet 468 filter types. 470 The other six NAT types are members of a symmetric NAT defined in 471 STUN except Symmetric (a) and symmetric (d). These symmetric types 472 are classified as a full-cone NAT. It is assumed in the current STUN 473 process that if a packet is received in Test II, it determines that 474 the NAT is full-cone without evaluating its port allocation rule. The 475 details of this issue are discussed in section 6.5. 477 In order to detect the six types of symmetric NATs shown in this 478 table, current STUN message definition and its server can be used as 479 is. This symmetric NAT discovery process is described in section 7. 481 6.4 Exceptional Behavior 483 A symmetric NAT has exceptional behavior on port allocation that 484 might help NAT traversal. The symmetric NAT allocates a port as well 485 as typical symmetric NAT behaviors but this symmetric NAT allocates 486 the same port number as its local port number. 488 [TRY] [FROM] [TO] [MAPPED-ADDRESS] 489 1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:4136 490 2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49152 491 3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49153 492 4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49154 493 5 192.168.1.2:4137 65.12.66.10:3478 67.105.12.10:4137 494 6 192.168.1.2:4137 65.12.66.10:3479 67.105.12.10:49155 495 7 192.168.1.2:4137 65.12.66.11:3478 67.105.12.10:49156 496 8 192.168.1.2:4137 65.12.66.11:3479 67.105.12.10:49157 498 If a device behind this type of NAT knows its behavior, the device 499 will be able to detect that the port number to be allocated by this 500 symmetric NAT will have the same port number as the local port bound 501 in a UDP socket of the device. In this case, once the device detects 502 the type of NAT, it will not perform the binding request to the STUN 503 server and use the local port as a global one with a previously 504 obtained global IP address from the STUN server. 506 6.5 Symmetric (a) and (d) and Full-cone NAT 508 Symmetric (a) and (d) are types of symmetric NAT, but they behave 509 like a full-cone NAT in terms of the incoming packet filtering. STUN 510 discovery process with these types of NAT results in full-cone, which 511 is fine but it might have a problem if the device (e.g. EP-a) behind 512 the NAT needs to send a packet to the other endpoint (EP-b). 514 After obtaining a MAPPED-ADDRESS, EP-a tells EP-b the MAPPED-ADDRESS 515 so that EP-b can send packets to EP-a via the MAPPED-ADDRESS. If EP-a 516 wants to send a packet to EP-b, the packet transmission will cause a 517 new port allocation on the NAT because the NAT is actually a 518 symmetric NAT. Then EP-b will receive a packet from the new port. EP- 519 b believes that it is sending packets to the MAPPED-ADDRESS to talk 520 to EP-a, but the packet is coming from a different port than the 521 MAPPED-ADDRESS. This might cause some confusion in EP-b. 523 7 NAT Characteristics Discovery using STUN 525 Current STUN message format and test definitions are used as is in 526 order to detect the NAT types defined in Table 6.3.1. 528 Test I: The client sends a STUN Binding Request to a server, 529 without any flags set in the CHANGE-REQUEST attribute, and without 530 the RESPONSE-ADDRESS attribute. This causes the server to send the 531 response back to the address and port that the request came from. 533 Test II: The client sends a Binding Request with both the "change 534 IP" and "change port" flags from the CHANGE-REQUEST attribute set. 536 Test III: The client sends a Binding Request with only the "change 537 port" flag set. 539 It does not require any modification to STUN server, either. The only 540 difference is the discovery process flow as described in the 541 following sections. 543 7.1 Incoming Packet Filter Type Discovery 545 The client begins by initiating Test I. If this test yields no 546 response, the client knows right away that it is not capable of UDP 547 connectivity. If the test produces a response, the client examines 548 the MAPPED-ADDRESS attribute. If this address and port are the same 549 as the local IP address and port of the socket used to send the 550 request, the client knows that it is not "natted". The client then 551 executes Test II. 553 If a response is received during the Test II, the client knows that 554 it has open access to the Internet (or, at least, its behind a 555 firewall that behaves like a full-cone NAT, but without the 556 translation). If no response is received, the client knows its behind 557 a symmetric UDP firewall. 559 In the event that the IP address and port of the socket did not match 560 the MAPPED-ADDRESS attribute in the response to Test I, the client 561 knows that it is behind a NAT. 563 Specifically, the process up until this point is considered the NAT 564 presence discovery process. The following process covers the incoming 565 packet filter type discovery that is performed only in situations 566 where the client is behind one or more NATs. 568 The client performs Test II. If a response is received, the client 569 knows that the NAT that the client is behind has no port filter. If 570 no response is received, the client performs Test III. If a response 571 is received, the client is behind a NAT that has an address sensitive 572 filter. If no response is received, the NAT has a port sensitive 573 filter. 575 +--------+ 576 | Test | 577 | I | 578 +--------+ 579 | 580 | 581 V 582 /\ /\ 583 N / \ Y / \ Y +--------+ 584 UDP <-------/Resp\--------->/ IP \------------->| Test | 585 Blocked \ ? / \Same/ | II | 586 \ / \? / +--------+ 587 \/ \/ | 588 | N | 589 | V 590 V /\ 591 +--------+ Sym. N / \ 592 | Test | UDP <---/Resp\ 593 | II | Firewall \ ? / 594 +--------+ \ / 595 | \/ 596 V |Y 597 /\ | 598 +--------+ N / \ V 599 | Test |<------- /Resp\ Open 600 | III | \ ? / Internet 601 +--------+ \ / 602 | \/ 603 | |Y 604 | | 605 | +--> No Filter 606 V 607 /\ 608 / \ Y 609 /Resp\-----------------> Address Sensitive Filter 610 \ ? / 611 \ / 612 \/ 613 |N 614 | 615 +-------------------> Port Sensitive Filter 617 Figure 7.1 Incoming Filter Type Discovery Process Flow 619 7.2 Port Allocation Rule Discovery 621 The port allocation rule discovery process is performed only in 622 situations where the device is found "natted" with a previous NAT 623 presence discovery process. The port allocation rule discovery 624 process uses only Test I, but applies it to different combinations of 625 IP addresses and ports in order to figure out the port allocation 626 characteristics of the NAT. A STUN server uses 2 different IP 627 addresses (Da and Ca) as shown in Table 7.1 and 2 different ports (Dp 628 and Cp). This is the minimal set required to discover the allocation 629 rule. 631 Table 7.1 Test I Destinations for Port Allocation Discovery Process 632 +---------------------------------+ 633 | | Destinations | 634 | |-------------------------| 635 | | IP Address | Port | 636 |-------+------------+------------| 637 | TRY-1 | Da | Dp | <= STUN client obtains 638 |-------+------------+------------| Ca and Cp in CHANGED-ADDRESS 639 | TRY-2 | Da | Cp | attribute in the response. 640 |-------+------------+------------| 641 | TRY-3 | Ca | Dp | 642 |-------+------------+------------| 643 | TRY-4 | Ca | Cp | 644 +---------------------------------+ 646 Test I is performed 4 times (TRY-1 through TRY-4) per local port. 647 Destinations to which the TRY-1 through TRY-4 are performed are shown 648 in Table 7.1. This process can be done with the same local port that 649 is used in the previous NAT discovery process. Since TRY-1 has 650 already been done in Test I, it can be skipped and testing can begin 651 from TRY-2. The client will obtain 4 MAPPED-ADDRESSes from the 652 responses. The 4 MAPPED-ADDRESSes are analyzed to determine the port 653 allocation rule, the delta p value, and to evaluate consistency. 655 To look for consistency, the process can be performed multiple times, 656 however, each test should be done from a different local port which 657 does not have a NAT binding associated with it. 659 The port allocation rule will be determined by looking at the port 660 numbers obtained from MAPPED-ADDRESSes. If all port numbers are 661 incremented at each test, the port allocation rule is 'Port 662 Sensitive'. 664 If the port increment size from TRY-1 and TRY-2, and the ones from 665 TRY-3 and TRY-4 are always 0, but the incremental size between the 666 ones from TRY-2 and TRY-3 are not 0, the port allocation rule is 667 'Address Sensitive'. 669 The delta p value will be determined as follows: 671 Cone NAT: 673 If all port numbers of the obtained MAPPED-ADDRESSes are the same, 674 the NAT is a 'Cone NAT'. 676 Address sensitive allocation: 678 The delta p is equal to a port increment size between TRY-2 and 679 TRY-3. If the process is re-done one more time from another local 680 port (TRY-5 to TRY-8 as shown in Figure 7.2), delta p should also 681 equal to the port increment sizes between TRY-4 and TRY-5 and 682 between TRY-6 and TRY-7. 684 Port sensitive allocation: 686 The delta p is the difference between adjoining port numbers of 687 MAPPED-ADDRESSes obatained from testing (TRY-[N+1] and TRY-[N]). 689 [TRY] [MAPPED-ADDRESS] 690 1 67.105.12.10:49152 691 2 67.105.12.10:49152 (+0)----+ 692 3 67.105.12.10:49154 (+2)--+ | 693 4 67.105.12.10:49154 (+0)--|-+ 694 5 67.105.12.10:49156 (+2)--+ | 695 6 67.105.12.10:49156 (+0)--|-+ 696 7 67.105.12.10:49158 (+2)--+ | 697 8 67.105.12.10:49158 (+0)--|-+ 698 | +-> always 0: 'Address Sensitive' 699 +---> consistently 2: Delta p = 2 701 Figure 7.2 Allocation Discovery Result: Address Sensitive 703 Figure 7.2 shows the result of the allocation discovery process with 704 a NAT that has an address sensitive allocation rule. TRY-5 through 705 TRY-8 are performed from a different local port than the one used in 706 TRY-1 through TRY-4. 708 In situations that the internal device could not find the consistency 709 with the port increment size for delta p determination, the 710 application needs to have an algorithm to determine the delta p value 711 based on statistical observation, or to decide to give up obtaining a 712 valid delta p. The device should be able to determine whether or not 713 it is address sensitive or port sensitive. The device still has a 714 chance to traverse the NAT if the NAT combination class is III as 715 described in section 5. 717 8 Traversing Symmetric NAT 719 This section describes how the symmetric NAT traversal (specifically, 720 class IV traversal) is accomplished. To aid in this explanation, the 721 following network configuration is used. 723 STUN Server 724 +-----+ 725 NAT-S | | NAT-R 726 +-+ +--+--+ +-+ 727 +----+ | | | | | +----+ 728 |EP-S|-----+ +-----((Public Network))-----+ +-----|EP-R| 729 +----+ | | | | +----+ 730 +-+ +-+ 732 Figure 8.1 Network Configuration 734 There are two endpoints EP-S and EP-R, for example, that are located 735 behind different NATs (NAT-S and NAT-R, respectively) and EP-R wants 736 to receive UDP packets from EP-S. 738 Both EP-S and EP-R have performed NAT discovery processes and know 739 the following attributes of the NAT obtained from the discovery 740 processes described in the previous sections. 742 o Incoming Packet Filter Type 743 o Port Allocation Rule 744 o Delta p 746 8.1 Information To Be Exchanged 748 Incoming packet filter type attribute is used to determine whether or 749 not an endpoint device needs to send an invitation packet. This 750 attribute is not necessary for the other endpoint and need not be 751 exchanged. 753 When it comes to sending packets (including invitation packets), the 754 endpoint needs to know the destination address for the packets. If 755 the port allocation rule of the other endpoint is a symmetric type, 756 the endpoint needs either to record the source port number of an 757 incoming packet or to predict a port number that the symmetric NAT 758 will assign, with a MAPPED-ADDRESS obtained from the other endpoint. 760 The following items are the required information to be exchanged 761 between the endpoints (EP-S and EP-R) in order to traverse NAT 762 (including the class IV case). 764 o MAPPED-ADDRESS (from Binding Request with STUN server) 765 o Port Allocation Rule 766 o Delta p (required if port allocation rule is either address 767 sensitive or port sensitive) 769 8.2 EP-R Behavior 771 Soon after the information exchange is complete EP-R decides, using 772 the obtained information, the following items with regard to an 773 invitation packet transmission. 775 (1) If an invitation packet needs to be sent. 776 (2) Requirement for its repetition. 778 (1) is to be decided with port allocation rule of EP-S and incoming 779 packet filter type of EP-R as shown in Table 8.1. 781 Table 8.1 Invitation Packet Determination Chart for EP-R 782 +----------------------+-----------------------------------+ 783 | | NAT-R Incoming Packet Filter Type | 784 | |-----------------------------------| 785 | | No | Address | Port | 786 | | Filter | Sensitive | Sensitive | 787 +----------+-----------+-----------+-----------+-----------+ 788 | | Open | | | 789 | NAT-S |-----------+ + YES | 790 | Port | Cone | | | 791 |Allocation|-----------+ NO +-----------+-----------| 792 | Rule | Address | | | | 793 | | Sensitive | | YES | YES | 794 | |-----------+ + (*1) + (*2) | 795 | | Port | | | | 796 | | Sensitive | | | | 797 +----------------------+-----------------------------------+ 799 (*1) in Table 8.1 is the case that EP-R mentioned in Figure 8.1 has a 800 NAT that has an address sensitive filter. Although NAT-S is a 801 symmetric NAT (the port shown in MAPPED-ADDRESS is invalid), EP-R can 802 send a packet to any port of the IP address in the MAPPED-ADDRESS. 803 This can be done because the NAT-R's incoming packet filter is not 804 sensitive to its source port. 806 (*2) If NAT-R has a port sensitive filter and NAT-S is a symmetric 807 NAT, EP-R needs to predict a specific port that will be allocated by 808 NAT-S later on so that EP-R can send the invitation packet to the 809 port. 811 The invitation packet is required to be sent repeatedly in case the 812 other endpoint (EP-S shown in Figure 8.1) needs to capture the 813 invitation packet to record its source port to which EP-S can send 814 packets afterwards. 816 The reason for the repetition is that when the first invitation 817 packet is sent from EP-R, NAT-S might not be ready to route the 818 packet to EP-S because EP-S hasn't sent an invitation packet yet. 819 Since EP-S needs to capture the packet to record its source port 820 number, EP-R has to make sure that EP-S receives the invitation 821 packet. 823 The condition that EP-R is required to send invitation packets 824 repeatedly is when NAT-R follows either address sensitive allocation 825 rule or port sensitive allocation rule. 827 The retransmission should stop when EP-R starts to receive packets 828 from EP-S successfully, or a time-out event set up for error handling 829 occurred. 831 NOTE: Even if NAT-R has no filter, EP-R has to send the invitation 832 packets repeatedly because the purpose of the invitation packet in 833 this case is not only for opening the filter on NAT-R for the 834 destination but also for informing EP-S of the source port number 835 allocated by NAT-R. 837 8.3 EP-S Behavior 839 Soon after the information exchange is complete, EP-S decides, with 840 the obtained information, the following items with regard to 841 invitation packet transmission: 843 (1) If an invitation packet needs to be sent. 844 (2) If source port recording is required. 846 EP-S only needs to send an invitation packet to EP-R when source port 847 recording is required and NAT-S has either address sensitive filter 848 or port sensitive filter (Table 8.2). By sending an invitation 849 packet, it opens up the filter (door) at NAT-S to NAT-R so that the 850 invitation packet coming from EP-R will be received at EP-S. 852 Source port recording is required if and only if NAT-S has either 853 address sensitive allocation rule or port sensitive allocation rule. 855 Table 8.2 Invitation Packet Determination Chart for EP-S 856 +----------------------+-----------------------------------+ 857 | | NAT-S Incoming Packet Filter Type | 858 | |-----------------------------------| 859 | | No | Address | Port | 860 | | Filter | Sensitive | Sensitive | 861 +----------+-----------+-----------+-----------+-----------+ 862 | | Open | | | 863 | NAT-R |-----------+ + YES | 864 | Port | Cone | | | 865 |Allocation|-----------+ NO +-----------+-----------| 866 | Rule | Address | | | | 867 | | Sensitive | | YES | YES | 868 | |-----------+ + (*3) + (*4) | 869 | | Port | | | | 870 | | Sensitive | | | | 871 +----------------------+-----------------------------------+ 873 (*3) in Table 8.2 is the case in which EP-S mentioned in Figure 8.1 874 has a NAT that has an address sensitive filter. Although NAT-R is a 875 symmetric NAT (the port shown in MAPPED-ADDRESS is invalid), EP-S can 876 send a packet to any port of the IP address in the MAPPED-ADDRESS. 877 This can be done because the incoming packet filter for NAT-S is not 878 sensitive to its source port. 880 (*4) If NAT-S has a port sensitive filter and NAT-R is a symmetric 881 NAT, EP-S needs to predict a specific port that will be allocated by 882 NAT-R later on so that EP-S can send the invitation packet to the 883 port. 885 8.4 Increasing Prediction Success Rate 887 In order to increase success rate of the port prediction for 888 symmetric NATs, invitation packets can be sent to multiple 889 destinations that are possible next ports to be allocated by 890 symmetric NATs. 892 For example, NAT-R has a port sensitive filter and a port sensitive 893 allocation rule. NAT-S has a port sensitive filter and an address 894 allocation rule. In this case, source port recording is required. In 895 order for EP-S to capture an invitation packet from EP-R, EP-S sends 896 an invitation packet to a predicted port on NAT-R. The prediction is 897 typically made by adding delta p to the port number of the MAPPED- 898 ADDRESS obtained from EP-R earlier. 900 As mentioned in section 6.1, a symmetric NAT might not allocate the 901 predicted port number because the port might be in use and skipped to 902 the next one (+2 * delta p). For that reason, EP-S can send 903 invitation packets not only to +delta p, but also to the next 904 possible ports such as +2*delta p, +3*delta p,...as shown below. 906 NAT-S _____ MAPPED- ____ NAT-R 907 +------+ / ADDRESS \ +------+ 908 | |/ \| | 909 | 4000 @ @ 6000 | 910 EP-S | | +1*delta p | | EP-R 911 +--+ | 4001 @-+------------------->x 6002 | +--+ 912 | | | | \ +2*delta p | | | | 913 | +----| | +----------------->x 6004 +----+ | 914 | | | | \ +3*delta p | | | | 915 +--+ | | +--------------->x 6006 | +--+ 916 | | \ +4*delta p | | 917 | | -------------->x 6008 | 918 | | | | 919 +------+ +------+ 920 - PS filter - PS filter 921 - AS allocation - PS allocation 922 - delta p = 1 - delta p = 2 924 Figure 8.2 Invitation Packets To Multiple Predicted Ports 926 Sending invitation packets to multiple predicted ports is possible 927 because NAT-S will not create a new port each time it sends an 928 invitation packet to NAT-R. This means that if NAT-S is a port 929 restricted-cone NAT, the method will still work. 931 If NAT-S has a port sensitive allocation rule and a port sensitive 932 filter, this additional invitation packet does not help increase the 933 success rate. Each time EP-S sends an invitation packet to a 934 different port, EP-S allocates another port. The whole purpose of 935 sending invitation packets to multiple ports on NAT-R is to have one 936 specific port accept incoming packets from the multiple ports on NAT- 937 R. New allocations on NAT-S defeat this purpose. 939 In Figure 8.3, EP-S is sending an invitation packet to multiple ports 940 on NAT-R, assuming that when EP-R sends an invitation packet to NAT- 941 S, NAT-R will allocate one of these ports (6000 through 6008) for the 942 packet. If NAT-R allocated 6004 when EP-R sends an invitation packet 943 to 4001 on NAT-S, for example, as NAT-S has port sensitive filter and 944 4001 never sent a packet to 6004, it blocks the incoming packet. 946 NAT-S _____ MAPPED- ____ NAT-R 947 +------+ / ADDRESS \ +------+ 948 | |/ \| | 949 | 4000 @ @ 6000 | 950 EP-S | | +1*delta p | | EP-R 951 +--+ | 4001 @--------------------->x 6002 | +--+ 952 | | | | +2*delta p | | | | 953 | @----| 4002 @--------------------->x 6004 +----@ | 954 | | | | +3*delta p | | | | 955 +--+ | 4003 @--------------------->x 6006 | +--+ 956 | | +4*delta p | | 957 | 4004 @--------------------->x 6008 | 958 | | | | 959 +------+ +------+ 960 - PS filter - PS filter 961 - PS allocation - PS allocation 962 - delta p = 1 - delta p = 2 964 Figure 8.3 Invitation Packets To Multiple Predicted Ports 966 The benefit of knowing which allocation rule (address sensitive or 967 port sensitive) a symmetric NAT has is that the discovery of the 968 address sensitive allocation rule will increase the success rate of 969 the port prediction. 971 9 Normative Reference 973 [1] Rosenberg, et al. "STUN - Simple Traversal of User Datagram 974 Protocol (UDP) Through Network Address Translators (NATs)" RFC 3489, 975 March 2003. 977 [2] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft- 978 rosenberg-midcom-turn-00.txt, November 2001. 980 [3] D. Yon, "Connection-oriented media transport in SDP," Internet 981 Draft, Internet Engineering Task Force, May 2002. Work in progress. 983 [4] Rosenberg, et al. "NAT and Firewall Scenario and Solutions for 984 SIP", draft-ietf-sipping-nat-scenarios-00.txt, IETF, June 24, 2002. 986 [5] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", 987 IETF RFC 2327, April 1998. 989 [6] P. Srisuresh, K. Egevang, "Traditional IP Network Address 990 Translator (Traditional NAT)," RFC 3022, Internet Engineering Task 991 Force, January 2001. 993 [7] J. Postel, "internet protocol", RFC 791, Internet Engineering 994 Task Force, September 1981. 996 10 Author's Address 998 Yutaka Takeda 999 Panasonic Communications Research Laboratory 1000 10993 Via Frontera 1001 San Diego, CA 92127 1003 EMail: takeday@kmerl.com