Standard-Subnetz-Größe bei IPv6

Bitte loggen sie sich ein oder registrieren sie sich.

Einloggen mit Benutzername, Passwort und Sitzungslänge
Erweiterte Suche  

Autor Thema: Standard-Subnetz-Größe bei IPv6  (Gelesen 4879 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

pkern

  • Grünschnabel
  • *
  • Offline Offline
  • Beiträge: 6
Standard-Subnetz-Größe bei IPv6
« am: 23.Januar 2013, 23:00:00 »

Hi,

ich würde gerne anregen, dass sich EUServ über die Standard-Subnetz-Größe bei Rootservern nochmal Gedanken macht.

Die IPv6-RFC-Familie macht an diversen Stellen (autoconf, source/destination address selection, etc.) Annahmen über die Netzgröße bzw. den Anteil der Interface ID an der IPv6-Adresse: die letzten 64 bit werden als solche verstanden. Die Root-Server eignen sich ja kaum zur alleinigen Nutzung ohne irgendeine Art von Virtualisierung, bzw. wären sie für die meisten Anwendungen überdimensioniert. Wenn man nun eine Bridge mit dem gerouteten /64-Subnetz konfigurieren würde, womit man z.B. Autokonfiguration nutzen kann, und für einen einzelnen Dienst noch eine weitere IPv6-Adresse benötigt (z.B. eine Adresse für das NAT64-Gateway und dessen ICMP-Fehlermeldungen) muss man entweder sehr unsauber ein Loch ins Subnetz reißen (inkl. Proxy NDP, damit die beteiligten VMs das auch mitbekommen) oder eben der Bridge ein kleineres Subnetz als /64 zuweisen. Mir ist bewusst, dass ich natürlich auch die professionelle Nutzung und weitere Netze buchen könnte. Aber mir geht es darum, die »IPv6 adoption« zu fördern und solche Limits, die ohne Not aufgestellt werden, führen immer zu Notlösungen, die man dann implementieren muss. Außerdem versucht man ja auch so wenige IPv4-Adressen wie möglich zu verwenden und stattdessen IPv6 zu benutzen, nur um dann doch kleine Stolpersteine in den Weg gelegt zu bekommen.

Es ist ja nicht so, als würde einem RIPE den Kopf abreißen, wenn man mehr als ein /64 pro Server vergibt (z.B. /60 oder gar /56). Die Zurückhaltung eines anderen großen Hosters lässt sich ja hauptsächlich darauf zurückführen, dass wegen der IPv4-Adressvergabe auf die Finger geklopft wurde. Mir ist auch klar, dass 2^64 Adressen sehr viele sind, aber das Protokoll geht nunmal davon aus, dass diese einer einzelnen Broadcast-Domäne zur Verfügung stehen. Die ursprüngliche Idee war ja ein /48 pro Kunde, damit man leicht von Provider zu Provider ziehen kann und der hintere Teil der Adresse gleich bleibt. Selbst davon sind im /29, was inzwischen jeder LIR zusteht, 524288 vorhanden. An /60 gibts im /29 halb so viel wie IPv4-Adressen weltweit (eigentlich mehr als halb so viel wegen Class E).

Mit freundlichem Gruß
Philipp Kern
Gespeichert


 

Seite erstellt in 0.075 Sekunden mit 17 Abfragen.