is STUN usage must be considered as a building block usable in more complete solu- tions, such as, for example, ICE [7,8], which will be described later on in this chapter. Besides the STUN binding request/response message pair, STUN defines an indication message that generates no response. *If this were not the case, communication would not be possible between hosts in the network of the STUN client and hosts in the network of the STUN server. © 2009 by Taylor & Francis Group, LLC NAT Traversal 12.4.4 TURN: A STUN Extension to Support Relaying Traversal Using Relays around NAT (TURN) [9] is an extension to STUN to make STUN servers act as relays for hosts placed behind NATs. TURN introduces a framing method and a few new messages called TURN control messages. The new messages are used to request a transport address and to activate the relaying of data sent to/from external peers. Indeed even when a TURN client obtains a relayed transport address, it cannot be used to send/receive data to/from an external peer until this peer is enabled. Note that the TURN client may use the same relayed transport address to send/receive data from more than one peer. To this purpose, TURN encompasses different channels between the TURN server and the TURN client, each one for data received by the STUN server from a corresponding enabled peer; channel 0 is reserved for TURN control messages. The channels are implemented by adding a so-called framing header to data exchanged between a TURN client and a TURN server. Figure 12.9 shows an example of TURN operation. The client sends an allocate request to the TURN server to obtain a public transport address from the server. The server communicates the assigned address placing it in the RELAY-ADDRESS attribute of the allocate response. Both messages are new STUN messages defined in the context of TURN. The allocate response also includes a XOR-MAPPED-ADDRESS, thus offering the functionality of a STUN binding response. At this point, the TURN client enables the tar- get peer by sending a