19. Considérations IAB (IAB Considerations)
L'IAB a étudié le problème du « Unilateral Self-Address Fixing (UNSAF) », qui est le processus général par lequel un client tente de déterminer son adresse dans un autre domaine de l'autre côté d'un NAT par le biais d'un mécanisme de réflexion de protocole collaboratif [RFC3424]. L'extension TURN est un exemple de protocole qui effectue ce type de fonction. L'IAB a exigé que tout protocole développé à cette fin documente un ensemble spécifique de considérations. Ces considérations et les réponses pour TURN sont documentées dans cette section.
Considération 1 : Définition précise d'un problème spécifique à portée limitée qui doit être résolu avec la proposition UNSAF. Une solution à court terme ne doit pas être généralisée pour résoudre d'autres problèmes. De telles généralisations conduisent à une dépendance prolongée et à l'utilisation de la soi-disant solution à court terme - ce qui signifie qu'il n'est plus exact de l'appeler « à court terme ».
Réponse : TURN est un protocole de communication entre un relais (= le serveur TURN) et ses clients. Le protocole permet à un client derrière un NAT d'obtenir et d'utiliser une adresse IP publique sur le relais. Pour la commodité du client, TURN permet également au client de déterminer son adresse de transport réflexive du serveur.
Considération 2 : Description d'une stratégie de sortie/plan de transition. Les meilleures solutions à court terme sont celles qui verront naturellement de moins en moins d'utilisation à mesure que la technologie appropriée sera déployée.
Réponse : TURN ne sera plus nécessaire une fois qu'il n'y aura plus de NAT. Malheureusement, à la date de publication de ce document, il est peu probable que les NAT disparaissent de sitôt. Cependant, à mesure que le nombre de NAT avec la propriété de mappage Endpoint-Independent Mapping [RFC4787] augmente, le besoin de TURN diminuera.
Considération 3 : Discussion des problèmes spécifiques qui peuvent rendre les systèmes plus « fragiles ». Par exemple, les approches qui impliquent l'utilisation de données à plusieurs couches réseau créent plus de dépendances, augmentent les défis de débogage et rendent la transition plus difficile.
Réponse : TURN est « fragile » en ce sens qu'il exige que les liaisons NAT entre le client et le serveur restent en place pendant la durée de vie de l'allocation. Cela se fait généralement en utilisant des keep-alives. Si cela n'est pas fait, le client perdra son allocation et ne pourra plus échanger de données avec ses pairs.
Considération 4 : Identifier les exigences pour des solutions techniques à long terme et solides - contribuer au processus de recherche de la bonne solution à long terme.
Réponse : Le besoin de TURN sera réduit une fois que les NAT implémenteront les recommandations de comportement NAT UDP documentées dans [RFC4787]. Les applications sont également fortement encouragées à utiliser ICE [RFC5245] pour communiquer avec les pairs, et bien qu'ICE utilise TURN, il ne le fait qu'en dernier recours et de manière contrôlée.
Considération 5 : Discussion de l'impact des problèmes pratiques notés avec les NAT existants déployés et rapports d'expérience.
Réponse : Certains NAT déployés aujourd'hui présentent un comportement de mappage autre que le mappage indépendant du point de terminaison. De tels NAT sont difficiles à traiter car ils rendent difficile ou impossible pour des protocoles tels qu'ICE d'utiliser des adresses de transport réflexives du serveur sur ces NAT. Les clients derrière de tels NAT sont généralement obligés d'utiliser un protocole de relais tel que TURN car les techniques de « perforation UDP » [RFC5128] ne fonctionnent pas.