19. IAB-Überlegungen (IAB Considerations)
Das IAB hat das Problem des „Unilateral Self-Address Fixing (UNSAF)" untersucht, bei dem es sich um den allgemeinen Prozess handelt, bei dem ein Client versucht, seine Adresse in einem anderen Bereich auf der anderen Seite eines NAT durch einen kollaborativen Protokollreflexionsmechanismus zu bestimmen [RFC3424]. Die TURN-Erweiterung ist ein Beispiel für ein Protokoll, das diese Art von Funktion ausführt. Das IAB hat vorgeschrieben, dass alle für diesen Zweck entwickelten Protokolle einen bestimmten Satz von Überlegungen dokumentieren. Diese Überlegungen und die Antworten für TURN sind in diesem Abschnitt dokumentiert.
Überlegung 1: Präzise Definition eines spezifischen, auf einen begrenzten Bereich beschränkten Problems, das mit dem UNSAF-Vorschlag gelöst werden soll. Eine kurzfristige Lösung sollte nicht verallgemeinert werden, um andere Probleme zu lösen. Solche Verallgemeinerungen führen zu einer längeren Abhängigkeit von und Nutzung der vermeintlich kurzfristigen Lösung - was bedeutet, dass es nicht mehr zutreffend ist, sie als „kurzfristig" zu bezeichnen.
Antwort: TURN ist ein Protokoll für die Kommunikation zwischen einem Relay (= dem TURN-Server) und seinen Clients. Das Protokoll ermöglicht es einem Client hinter einem NAT, eine öffentliche IP-Adresse auf dem Relay zu erhalten und zu verwenden. Zur Bequemlichkeit des Clients ermöglicht TURN dem Client auch, seine Server-reflexive Transportadresse zu bestimmen.
Überlegung 2: Beschreibung einer Ausstiegsstrategie/eines Übergangsplans. Die besseren kurzfristigen Lösungen sind diejenigen, die mit der Bereitstellung der geeigneten Technologie natürlicherweise immer weniger genutzt werden.
Antwort: TURN wird nicht mehr benötigt, sobald es keine NATs mehr gibt. Leider ist es zum Zeitpunkt der Veröffentlichung dieses Dokuments unwahrscheinlich, dass NATs in absehbarer Zeit verschwinden werden. Mit zunehmender Anzahl von NATs mit der Endpoint-Independent Mapping [RFC4787] Mapping-Eigenschaft wird jedoch der Bedarf an TURN abnehmen.
Überlegung 3: Diskussion spezifischer Probleme, die Systeme „brüchiger" machen können. Beispielsweise schaffen Ansätze, die die Verwendung von Daten auf mehreren Netzwerkebenen beinhalten, mehr Abhängigkeiten, erhöhen Debugging-Herausforderungen und machen Übergänge schwieriger.
Antwort: TURN ist „brüchig", da es erfordert, dass die NAT-Bindungen zwischen Client und Server während der Lebensdauer der Allokation erhalten bleiben. Dies geschieht typischerweise unter Verwendung von Keep-Alives. Wenn dies nicht geschieht, verliert der Client seine Allokation und kann keine Daten mehr mit seinen Peers austauschen.
Überlegung 4: Identifizierung von Anforderungen für langfristige, solide technische Lösungen - Beitrag zum Prozess der Findung der richtigen langfristigen Lösung.
Antwort: Der Bedarf an TURN wird reduziert, sobald NATs die in [RFC4787] dokumentierten NAT UDP-Verhaltensempfehlungen implementieren. Anwendungen werden auch dringend aufgefordert, ICE [RFC5245] für die Kommunikation mit Peers zu verwenden, und obwohl ICE TURN verwendet, tut es dies nur als letztes Mittel und auf kontrollierte Weise.
Überlegung 5: Diskussion der Auswirkungen der festgestellten praktischen Probleme mit bestehenden, bereitgestellten NATs und Erfahrungsberichte.
Antwort: Einige heute bereitgestellte NATs zeigen ein anderes Mapping-Verhalten als Endpoint-Independent Mapping. Solche NATs sind schwierig zu handhaben, weil sie es für Protokolle wie ICE schwierig oder unmöglich machen, Server-reflexive Transportadressen auf diesen NATs zu verwenden. Clients hinter solchen NATs sind typischerweise gezwungen, ein Relay-Protokoll wie TURN zu verwenden, weil „UDP-Hole-Punching"-Techniken [RFC5128] nicht funktionieren.