Diskussion:Liste von IPv6-Tunnelbrokern

Übersetzung

--Panky9 (Diskussion) 23:36, 12. Mär. 2013 (CET)

Der englische Artikel wurde gelöscht wegen Verstoßes gegen en:Wikipedia:NOTDIRECTORY. --Matthäus Wander 18:24, 24. Mär. 2023 (CET)

AYIYA verlinkt auf einen Abschnitt dieses Artikels, der ihn nicht erklärt

AYIYA wird in dem Artikel überhaupt nicht erklärt. :-( --RokerHRO (Diskussion) 19:00, 4. Dez. 2016 (CET)

PoP

Falls korrekt wäre es sinnvoll auf Point of Presence zu verlinken. --89.21.56.82 08:43, 6. Okt. 2017 (CEST)

Verständlichkeit

OMA-Test nicht bestanden. bitte verständlicher schrieben. Danke :) --Fan-von-mir (Diskussion) 00:18, 3. Nov. 2021 (CET)

Tabellenbreite

Die Tabelle IPv6-Übergangsmechanismen verkleinert die Breite von der Liste von IPv6 Tunnelbrokern, was angesichts dieser breiten Tabelle echt blöd ist. Wäre cool, wenn man das irgendwie auflöst. --Fan (Diskussion) 20:56, 4. Jan. 2022 (CET)

erl.--Fan (Diskussion) 00:28, 14. Jan. 2022 (CET)

Ehemalige Tunnelbroker

Bezug: Spezial:Diff/232074875

Wenn ein Tunnelbroker hinreichend relevant war, um in der Liste aufgenommen zu werden, müsste er dann nach Einstellung des Dienstes nicht weiterhin relevant für die Nennung in diesem Listenartikel sein? Dies wäre die konsequente Anwendung des Grundsatzes "Relevanz vergeht nicht". Falls der Anspruch besteht, lediglich aktive Tunnelbroker aufzulisten, hat der Listenartikel den Charakter eines Registers und verstößt damit meines Erachtens gegen WP:WWNI, Punkt 7, Unterpunkt 2. --Matthäus Wander 18:19, 24. Mär. 2023 (CET)

VPN-Anbieter

Die Auflistung von VPN-Anbietern halte ich in der Liste für fehl am Platz, selbst wenn sie IPv6 unterstützen. So lieblos hingeklatscht wie unter Spezial:Diff/228189664 ist das doch einfach nur Werbung für VPN-Dienste statt Information über Tunnelbroker. --Matthäus Wander 18:22, 24. Mär. 2023 (CET)

Stimmt, etwas lieblos ist das schon, aber so wirklich falsch halt auch nicht (Siehe meinen Kommentar im RFC3053 abschnitt dazu). Da in https://www.rfc-editor.org/rfc/rfc3053#section-2.3 halt auch "most common (...) or 128" steht, ist quasi jeder VPN-Anbieter der IPv6 unterstützt auch irgendwie RFC3053 konform, wenn auch die Absichten andere sind. Die Unterscheidung ist da schwierig und teilweise in Details der VPN-Anbieter bedingt. Genaugenommen ist es schwer, ein VPN-Anbieter mit IPv6 Unterstützung zu sein und nicht RFC3053 konform zu sein... Der DNS Teil aus RFC3053 wird selbst von vielen der Aufgeführten Anbieter nicht unterstützt bzw. durch den User manuell (da statische Adresszuweisungen) oder via dyndns client agent gemacht und ist das somit auch wieder nicht wirklich aussagekräftig. Und wenn wir als Kriterium die Statische Adresszuweisung nehmen, grenzt das das ganze ebenfalls wieder nicht von klar "VPN-Anbietern" ab. Die Unterscheidung von "IPv6 Tunnelbrokern" (nach RFC3053) und "VPN-Anbieter mit IPv6" ist hauptsächlich im Marketing und in den Intentionen und weniger in der Technik. RFC3053 Tunnelbrokern haben kein Anonymitätsversprechen. Die Umgangssprachlichen "VPN-Anbieter" haben hingegen eins. Aber was machen wir dann mit VPN-Anbietern mit IPv6 die kein Anonymitätsversprechen haben und lediglich "Sicherheit beim Surfen in öffentlichen Hotspots" o.ä. versprechen? --Agowa (Diskussion) 20:39, 24. Mär. 2023 (CET)

Die Argumentation finde ich schlüssig. EIn IPv6-Tunnelbroker bietet IPv6-Konnektivität, ein VPN-Anbieter Anonymität und/oder Sicherheit. Vielleicht ist das Konzept eines Tunnelbrokers mittlerweile einfach überholt. IPv6 ist soweit Mainstream geworden, dass die IPv6-Konnektivität beispielsweise bei VPN-Anbietern nebenbei mit im Produkt integriert ist. --Matthäus Wander 16:50, 26. Mär. 2023 (CEST)

Überholt würde ich nicht sagen. Selbst wenn du eine IPv6 Verbindung hast, gibt es noch relevante Anwendungszenarien.

Die Tunnelbroker sind inzwischen quasi die bevorzugte Alternative zu den vom Markt weniger gut angenommenen Locator/Identifier_Separation_Protocol, SHIM6, HIP, ILNP, Mobile_IP, Proxy_Mobile_IPv6.

Anwendungsfallbeispiele: Für die Nutzung von IPv6-PI ohne für SD-WAN (für BGP durch den ISP) zu bezahlen. Bei Multi-Homing wenn keine doppelte Adressierung möglich oder gewünscht ist, da du dann leichteres Failover hast. Und wenn der ISP nur dynamische IPv6 Adressen zur Verfügung stellt, kann via Tunnelbroker entweder ein statischer Prefix vom Tunnelbroker bezogen werden. --Agowa (Diskussion) 21:38, 26. Mär. 2023 (CEST)

RFC3053

Spezial:Diff/232074977: ... listet Tunnelanbieter und ob diese die Kriterien von RFC 3053 erfüllen.

Woran in der Tabelle erkennt man die Erfüllung des RFCs? --Matthäus Wander 18:30, 24. Mär. 2023 (CET)

Aktuell nicht ganz so einfach. Du musst den Teil hier https://www.rfc-editor.org/rfc/rfc3053#section-2.3 für jeden Eintrag durchgehen.

Die ganze RFC 3053 lässt sich aber als "ein Tunnel/VPN irgend einer Art, der einem client oder router in einem IPv4-only Netzwerk eine GUA IPv6 Adresse bzw. prefix zur Verfügung stellt."

Und das ist auch der Punkt wieso die Abgrenzung zu VPN-Anbietern nicht möglich ist, da ein RFC3053 Tunnel-Anbieter per definition auch ein VPN-Anbieter ist sowie umgekehrt. Der Unterschied liegt hier in der Intention des Benutzers und der Garantien des Anbieters.

RFC3053 Tunnel-Anbieter haben kein Anonymitätsversprechen und Kontaktdaten des Nutzers könnten sogar öffentlich einsehbar (z.B. Ripe Datenbank) sein, wie für "gekaufte IPs".

Manchmal bieten die RFC3053 auch LIR dienste an und erlauben die Verwendung eigener mitgebrachter PI Adressen.

Die umgangssprachlich als "VPN-Anbieter" bezeichneten Anonymizer haben genau den zweck, zu verschleiern wer der eigentliche Aufrufer ist und somit wird vom Provider auch keine Registrierung in der RIPE Databank gemacht noch die Verwendung eigener IPs unterstützt. --Agowa (Diskussion) 18:50, 24. Mär. 2023 (CET)

Hm, also aus Sicht des Lesers finde ich die Ankündigung, man könne die Erfüllung von RFC 3053 aus der Tabelle entnehmen, ein bisschen schwierig, da es die Tabelle so nicht hergibt. --Matthäus Wander 16:59, 26. Mär. 2023 (CEST)