KIF425:IPv6 an Hochschulen

Aus KIF
Version vom 16. November 2014, 22:43 Uhr von NormanS (Diskussion | Beiträge) (HTW Dresden ergänzt)

Folgende Fragen bitte für die eigene Hochschule beantworten:

  • Hat eure Hochschule IPv6?
  • Wird und wie sehr wird das Thema an eurer Hochschule in der Lehre aufgegriffen?
  • Gibt es an eurer Hochschule Forschungsprojekte, die die Thematik beleuchten? Ist euer AStA/StuRa/StuVe (etc.) für dieses Thema sensibel?
  • Falls nicht: Wie können wir das ändern?
Uni hat IPv6 wird gelehrt Forschungsprojekte AStA etc. sensibel wie ändern
uni ulm nope jap keine Ahnung bestimmt braucht Geld für Switches/Router
TU Dresden Nein Ja keine Ahnung FSR Informatik ja, Rest leidet nur unter IP-Adress-Not seit Jahren intern geplant, aber noch längst nicht in Aussicht
LMU München / LRZ ja, seit 2005 ja kleinere n.n. alles super
Friedrich-Alexander-Universität Erlangen-Nürnberg schon länger ≤ 2009 Ja (an der falschen Stelle) Könnn v6, kein Problem im WLAN noch wär's schön
RWTH Aachen nein ja unbekannt eher nicht das RZ hat nichts geplant
Ruprecht-Karls-Universität Heidelberg nope Ja - - Uni braucht Geld und Zeit
Otto-von-Guericke-Universität Magdeburg Nein Nein Nein Ein wenig, keine Beschlusslage IPv6 kompatible Admins einstellen
HTW Dresden

Pro IPv6

  • Konfiguration vereinfacht
  • Adressmangel wird aufgehoben
  • bei P2P-Verbindung KEIN NAT mehr nötig
  • leichtere Implementierung
  • unnötige Implementierungen sind entfernt worden (Checksumme für den Header)

Aktuelle Situation

  • München: IPv6 (2006)
    • zentrale Dienste IPv6 Supported
  • FAU Erlangen: IPv6 (~2009)
  • Magdeburg: IPv6 (NULL)
    • IPv6-Tunneln von RZ unerwünscht (verboten)
  • Heidelberg: IPv6 (-1)
  • Aachen: IPv6 (NOPE)
  • Uni Hamburg: IPv6 (NOPE)
    • Sieht auch nicht geplant aus
  • HTW & TU Dresden: IPv6 (NIL)

Probleme für die Umsetzung

  • große IPv4-Adressbereiche (/16) an Hochschulen
  • Hochschulen sehehn kein Sinn für den Einsatz
  • manche Betriebssysteme entwickeln "merkwürdige" Verhaltensmuster bei IPv6

Gründe für die Umsetzung

  • kein NAT
  • einfachere Konfigurierung
  • bessere Strukturierungsmöglichkeiten
  • die Zukunft des Internets

Links