 messages consisting of a STUN header and a sequence of zero or more TLV (i.e., type-length-value) encoded attributes. A host behind a NAT willing to discover its external transport address must implement a STUN client and send to the STUN server a STUN binding © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security client server Internal network A Internal network B FIGURE 12.8 A typical STUN scenario. request. The STUN server must be placed in the external network, and pos- sibly on the open Internet in order to be reachable by any host and must be known by any client, e.g., through configuration; the STUN server is typically related to a known DNS entry. The STUN binding request traverses all the NATs up to the STUN server, and because it is generated from the inter- nal network, NATs do not drop it. In the example depicted in Figure 12.8, the transport address is modified twice: a first time by NAT A and then by NAT B, which assigns the message an external transport address valid for the STUN server network. The STUN server reads the source transport address of the packet carrying the STUN message and copies it in the XOR-MAPPED- ADDRESS attribute of a STUN binding response that is sends back to the STUN client. Since the STUN binding response traverses exactly the same NATs of the request, none of them drops it, whatever filtering behavior it is implementing.* Upon receiving the STUN binding response, the STUN client learns its external transport address (i.e., the transport address assigned by the NAT closest to the STUN server) from the XOR-MAPPED-ADDRESS attribute, which has indeed not been modified by the NATs. "Classic STUN" proposed this approach as a NAT traversal solution, since it provides a manner for the STUN client to discover its external transport address. The issue is that this solution when used alone is not effective with certain types of NATs, such as, for example, the non-deterministic NATs and NATs implementing address- and/or port-dependent mapping. So th