HOSTBLOGGER.de

18 Trillionen IPv6-Adressen für jeden DSL-Kunden: Ob das ausreicht, um mit allen Endgeräten online zu kommen?

Ich würde das anders machen: /56 fürs DSL (Ja, ich nutze mehr als ein IPv4/IPv6 Netz zu Hause) und ein /64 auf dem Server. Evtl. auch ein /56, wenn ihr wollt, dass die Kunden tunneln können.

So funktioniert Routing aber nicht, mal ganz davon abgesehen, dass man nicht zwingend verschiedene MAC-Adressen hat, sondern diese durchaus auch mehrfach vorhanden sein können.


DHCPv6 wird von kaum einem OS überhaupt unterstützt, außerdem ist es mindestens idiotisch, eine der sinnigsten Neuerungen von IPv6 (stateless autoconfiguration) wirkungsvoll zu verhindern.


Selbst Big-T plant seinen Residential-Kunden ein /56 zuzuweisen - siehe beispielsweise hier bei heise:
http://www.heise.de/newsticker/meldung/Deutsche-Telekom-konkretisiert-IPv6-Plaene-1102458.html
Es wäre mir überhaupt neu, dass man an Festverbindungen nur /64 zuweisen will, alle mir bekannten Pläne sehen entweder ein /56 oder ein /48 vor.
Somit bekommt man mindestens 256 /64 - das sollte für Privatkunden ausreichend, aber eben auch notwendig, sein.
Warum man jedem dedizierten Host ein /48 zuweisen sollte, ohne dass der Bedarf dafür geklärt ist, erschließt sich mir ebenfalls so überhaupt gar nicht.

Ein dsl-Anschluß von maitu wäre für mich damit nutzlos, da ich zu Hause jetzt schon fünf Netze hinter einem Router habe (LAN, WLAN, DMZ, VoIP, Media wie vdr und Streamingclients) - übrigens unterstützen meine Telefone gar kein DHCPv6, wohl aber via radvd zugewiesene IPs und Bereichsoptionen, ebenso wie meine Rechner im LAN und im WLAN (Debian, SuSE und Windows 7).

Du denkst zu sehr im IPv4-Schema, allerdings befindest du dich da in bester Gesellschaft
Ohne Manuel nun zu nahe treten zu wollen - aber alleine die Formulierung zeigt, dass er sich noch nicht allzu ausgiebig mit der Materie beschäftigt hat - und auch er befindet sich damit ebenso in bester Gesellschaft.

Die Formulierung ist ebenso unsinnig wie richtig - übersetzt in das alte "IPv4-Schema" sagt er nämlich, dass er dem Kunden bei Zuweisung eines IPv4-/32-Prefixes "über 130.000 TCP- und sogar UDP-Ports" bereitstellt und zu ihm routet.
Das ist zwar richtig - aber eben auch unsinnig.

IPv6 ist mitnichten nur die schiere Vergrößerung des zuteilbaren Raumes an Prefixen bzw. eindeutigen Adressen - damit einher gehen ettliche weitere Neuerungen. Beispielsweise existiert hier auch der Begriff des "interface identifiers", der Teil der Adresse sein kann, aber nicht muss (das sind die letzten 64 Bit der Adresse). Daraus folgt, dass man kein kleineres Prefix zuordnen kann, wenn man den vollen Funktionsumfang nutzen möchte, und 128-64 ergibt nunmal 64.
Würdest du kleinere Prefixe zuordnen, würde beispielsweise die privacy-extension (in der jetzigen Implementation der mir bekannten IPv6-Stacks) nicht mehr tun, einfaches renumbering täte nicht mehr usw. - quasi alle qualitativen Verbesserungen, die mit IPv6 einher gehen, fielen weg.

Auch die hier genannten Voraussetzungen gehen an der Realität vorbei.
Die Carrier gehen schon lange auf IP-Only-Lösungen über - für Privatkunden bedeutet das beispielsweise, dass statt klassischer Telefonie über TDM-basierte Lösungen (POTS und ISDN) durch IP-basierte Dienste ersetzt wird. Selbst Big-T vermarktet das seit kurzem wieder aktiv. Oder nehmen wir klassische Triple-Play-Angebote, also vereinfacht "TV übers Internetz" - da haben wir schon mindestens drei Netzsegmente, die man unterteilt haben möchte, das machen die Carrier heute auch schon (zumindest diejenigen, die Komplettangebote vermarkten wie Bigt-T, Vodafone und Telefonica über O2 bzw. Hansenet). Die routen auch heute schon zwei bzw. drei voneinander unabhängige Netze zu dir nach Hause, wenn du deren Angebot willst.
Zwar sind das heute noch Netze aus dem RFC1918-Bereich, aber den gibt es bei IPv6 so nicht mehr, außerdem führt das oft zu Komplikationen bei den Endkunden, was zu erhöhtem Supportaufwand führt (Telefonica macht deren SIP-Server grundsätzlich nur über deren Intranet im Bereich 10/8 erreichbar, also registrar$foo.sip.alice-dsl.de löst grundsätzlich auf eine IP in AS6805 auf, darüber wird die Registrierung aber mit einem 403 ohne weitere Begründung abgelehnt; kontaktiert man über die RFC1918-Adresse funktionierts; das alles ist für den Residential zwar völlig transparent, ebenso das Routing über ein anderes VLAN - aber wenn er an seinem CPE den LAN-Adressraum verändert, also von einem Segment aus 192.168/16 in eines aus 10/8, und zufällig gerade das /23 trifft, auf dem das CPE deren Intranet anspricht, wird so manches Billig-CPE ganz strubbelig - und der Residential wird in aller Regel völlig hilflos sein - wie übrigens auch so mancher wannabee-ISP, der dort wholesale-Kunde ist ).


To make a long story short:
Es ist ein grundsätzlich falscher Ansatz, IPv6-Prefixe bis zu einem /128 herunterbrechen zu wollen und dort dann die Menge der zuteilbaren Adressen hochzurechnen. Man muss, um IPv6 vollständig nutzen zu können, auf /64-Prefixe für die jeweils nutzbaren Segmente herunterbrechen - es geht zwar auch kleiner, nur fällt einem das irgendwo immer auf den Fuß und man sollte das nur dann machen, wenn man genau weiß, was man da tut.
Einfacher gesagt - du bekommst, wenn dein ISP dir ein /56 zuweist, eben in erster Linie nicht 4722366482869645213696 einzelne Adressen, sondern ("nur") 256 /64-Segmente, die du nutzen kannst.
Man kann nun allenfalls fragen - braucht ein Residential überhaupt mehr als ein /64? Aktuell wohl eher nicht - nur habe ich oben versucht zu skizzieren, wohin der Trend geht - man will möglichst alles über IP realisieren, und da ist es sinnvoll, die einzelnen Netze auch trennen zu können (PCs, Telefone, Mediareceiver usw.), sowohl physikalisch als auch logisch.


Ich habe das nun bewusst vereinfacht, aber nicht sinnentstellend, versucht zu beschreiben.
Ich sehe ständig, dass eigentlich intelligente und technisch versierte Menschen versuchen, ihre "IPv4-Erfahrung" auf biegen und brechen auf IPv6 anzuwenden, und da stoßen sie oft auf unverständnis. Das liegt -so glaube ich- oft daran, dass sie sich kaum mit der Entstehung von IPv6 befasst haben, nur das Ergebnis sehen, und dann vieles nicht so einleuchtend empfinden - Paradebeispiel ist immer das hochrechnen auf einzelne /128.

Coole Sache, Manuel. Schon wieder guckt ein großer Teil des Internets auf das Zentrum des Internets in St. Wendel

Ähm, es gibt eine RFC der empfiehlt ein /48 pro Customer Site zu verwenden. Ob ein einzelner Server jetzt als Site gilt oder nicht, kann man sicher lange diskutieren. Die neusten RIPE Richtlinien sehen IIRC ein /56 als Standard für kleinere Sites vor.

Und wozu bitte brauche ich auf einem Server 65k Netze? Ein /56 macht u.U. Sinn, wenn man tunneln möchte.

Das verschwenden von Adressen ist übrigens gewollt, neben den immer knapper werdenden IPv4 Adressen wächst die globale Routing Tabelle an. Dies liegt u.A. daran, dass die meisten nicht ein großes Netz im BGP anouncen sonder viele kleine. (siehe auch http://bgp.potaroo.net/).

Mit IPv6 bekommt man viele Netze mit vielen Adressen, dass soll den Wildwuchs wie er jetzt bei IPv4 herrscht etwas mindern. Und wenn wir in 20 Jahren feststellen, dass wir mit 2000::/3 zu verschwenderisch umgegangen sind, haben wir ja noch 4000::/3, 6000::/3, ....

Also maitu: /56 fürs DSL und evlt. auch /56 für die Server.

Oute ich mich jetzt als Jemand der von IP V6 keine Ahnung hat wenn ich sage, mir reicht doch eine IP ?
Oder in wie fern unterscheided sich dass hier von IP V4?

Hier im Netzwerk hab ich gerademal 10 IPs (ohne Mobilgeräte), von ausen alles über die selbe IP erreichbar.
Ich denke mal nicht dass ich jemals mehr als eine benötigen würde.
Ein Apache, ein FTP... fertig.

Ich möchte noch vorschlagen, dass es möglich sein sollte ganze Subnetze zu routen. So wäre es sinnvoll das ein Kunde sowohl ein /48er als auch ein /64er Netz bekommt. Aus dem /64 weißt der Kunde jedem Server eine IP zu. Zusätzliche Subnetze aus dem /48 werden dann via next-hop auf die jeweilige IP geroutet. So kann man am Server mit dem Netz machen was man will und es ist pro Server nur eine IP per NDP "herauszufinden". Außerdem würde man sich so bei Virtualisierunglösungen die unschöne PROXY NDP Lösung sparen.

IPv6-Traffic zu verschenken, macht durchaus Sinn - leider ist die Kundenbasis gerade im Dialup-Bereich ziemlich mager. Es ist aber spannend zu sehen, welche Services schon jetzt per Default miteinander in v6 reden, wenn sie können - und welche partout nicht. Stichwort "MySQL"...

Nachdem wir nun seit etwa 5 Monaten produktiv in v6 sind und sage und schreibe zwei Kunden sich dafür interessiert haben, kann ich zwar den "IPv6 Ready" Aufkleber überall draufkleben, aber verkäuflich ist das wirklich noch nicht.

Ich warte auch schon gespannt auf die Verfügbarkeit von IPv6, dürfte ja nicht mehr allzu lange dauern