19. IAB Considerations
The IAB has studied the problem of "Unilateral Self-Address Fixing (UNSAF)", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. These considerations and the responses for TURN are documented in this section.
Consideration 1: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short-term fix -- meaning that it is no longer accurate to call it "short-term".
Response: TURN is a protocol for communication between a relay (= the TURN server) and its clients. The protocol allows a client behind a NAT to obtain and use a public IP address on the relay. For the convenience of the client, TURN also allows the client to determine its server-reflexive transport address.
Consideration 2: Description of an exit strategy/transition plan. The better short-term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
Response: TURN will not be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it is not likely that NATs will go away any time soon. However, as the number of NATs with the Endpoint-Independent Mapping [RFC4787] mapping property increases, the need for TURN will decrease.
Consideration 3: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
Response: TURN is "brittle" in that it requires the NAT bindings between the client and the server to remain in place during the lifetime of the allocation. This is typically done using keep-alives. If this is not done, then the client will lose its allocation and will not be able to exchange data with its peers any longer.
Consideration 4: Identify requirements for longer-term, sound technical solutions -- contribute to the process of finding the right longer-term solution.
Response: The need for TURN will be reduced once NATs implement the NAT UDP Behavior recommendations documented in [RFC4787]. Applications are also strongly urged to use ICE [RFC5245] to communicate with peers, and though ICE makes use of TURN, it only does so as a last resort and in a controlled way.
Consideration 5: Discussion of the impact of the noted practical issues with existing, deployed NATs and experience reports.
Response: Some NATs deployed today exhibit mapping behavior other than Endpoint-Independent Mapping. Such NATs are difficult to deal with because they make it hard or impossible for protocols such as ICE to use server-reflexive transport addresses on these NATs. Clients behind such NATs are typically forced to use a relaying protocol such as TURN because "UDP hole punching" techniques [RFC5128] do not work.