Das längste Thema

  • Wir drehen uns im Kreis. Der Fehler ist nicht im IPv6 Protokoll.

    doch der Fehler ist in der Definition des IPv6 Protokolls ...


    julian-w versteht es leider nicht, daß es einfach kompletter Quark ist, daß ein /64-Prefix als "kleinste Einheit" zu sehen ist

    weil unter diesem Gesichtspunkt in der Annahme er liege richtig, hast gerade ein paar Bits mehr als bei IPv4 und da ist es nur logisch

    daß viele auf IPv6 'pfeiffen' ...

    und es mehr Sinn macht sich was sauber zu überlegen, an Stelle von Design-Fehlern durchzudrücken ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • besser etwas nicht vestehen wollen - ich

    als etwas nicht verstehen in der Lage zu sein - Du.:P

    Aus deinem geschrieben würde ich behaupten ich hab mehr Ahnung von IPv6 oder anders formuliert: ich akzeptiere die Fakten. Du wärst vielleicht (?) in der Lage IPv6 zu verstehen, willst aber einige Design-Entscheidungen nicht akzeptieren und stempelst diese einfach als "Fehler im Desing" ab bzw. willst "dein Ding" durchziehen oder arbeitest nach dem Motto "das hab ich schon immer so gemacht, was soll der neumodische scheiß". So funktioniert es natürlich nicht. Wenn man sich nicht auf IPv6 einlässt, funktioniert IPv6 nicht und einige Dinge sind halt anders wie in IPv4.

    Du hast auch bei einem ganzen /64 mit SLAAC nicht die Chance zu definieren, aus welchem Teil davon die IPv6-Adressen generiert werden ...

    Warum sollte man das wollen? IPv6 sieht das nicht vor und es ist auch nicht notwendig, akzeptiere das oder halte dich aus IPv6 raus, das hat nichts mit meinem "Privatkäse" zu tun. Wenn du dich fragst warum das so ist: Im Internet sind die Antworten mehrfach enthalten. In IPv4 gibt es halt nichts vergleichbares (zumindest fällt mir auf die schnelle nix ein), daher ist diese Design-Entscheidung für dich vermutlich nicht nachvollziehbar. Die letzten 64 Bits stehen dem Client "frei" zur Verfügung im Falle von SLAAC. "Maximal kleine" Subnetze gibt es nur in IPv4, was zu Problemen führt wie rasend wachsenden Routingtabellen.

    Man muss akzeptieren das (prinzipiell) ein /64er-Netz die "kleinste Einheit" ist, ein kleineres Subnetz ist nicht möglich (im Gegensatz zu IPv4 das man quasi maximal klein machen konnte).

    Die Antwort: Gar nicht, weil es nicht gewollt ist in IPv6... der Client darf aus dem ganzen /64er-Netz seine IPv6 berechnen. Darüber zu Streiten ist eine sinnlose Grundsatzdiskussion die du so sehr liebst und das ganze hat nix mit "Fehler im Design" zu tun...


    Over and Out :rolleyes:

  • Aber was will Lieschen Müller mit einem /56er oder /64er Netz?

    Die Idee ist "verschwenderisch" zu sein. IPv6 wurde auch nicht für Lieschen Müller designed, sondern eher für größere Anwendungen. Gerade mit IPv4, wenn man für ein Subnetz nur ein /26er-Netz hatte, wurde dies unter Umständen mal voll, dann musste man den Netzplan erst mal über den Haufen werfen. Gerade an der Uni gibt es bei uns immer mal wieder Probleme das Arbeitsgruppen wachsen und dann die IPs nicht mehr ausreichend sind. Daher hat man bei IPv6 das kleinste Subnetz als /64er-Netz definiert, dieses Netz sollte wirklich niemals niemals voll werden. Damit ist das Problem ein für alle mal gelöst.


    Da ein /64er-Netz nun die kleinste Einheit ist, gibt man Endkunden z.B. ein /56er-Netz sodass jeder Endkunde dieses Netz noch untergliedern kann, in verschiedene /64er-Netze. Lieschen Müller braucht das eher nicht, daher geben fast alle ISP an Privatkunden auch nur ein einzelnes /64er-Netz heraus.


    Die gigantischen Blöcke sollen es hinterher auch ermöglichen, dass die globale Routingtabelle viel viel kleiner wird. Man schaut sich nur mal die verschiedenen AS an und die zugeordneten IPs. Bei IPv4 herrscht das "reinste Chaos", von überall her gibt es IP happen, gerade durch den Mangel fragmentiert der IPv4-Raum extrem. Bei IPv6 wirkt das ganze sehr geordnet. Da die IPv6 Blöcke unglaublich groß sind und auch sehr viele Subnetzte beinhalten, werden die auch eine ganze Zeit lang reichen (für "immer", bis die Menschheit ausstirbt? Wer weiß...).


    Daher ist es nicht tragisch wenn Lieschen Müller in ihrem /64er-Netz oder gar in einem /56er-Netz nur ein oder zwei Geräte hat. Hauptsache die globale Routingtabelle bleibt klein, und Adressen sind mehr wie genug da :)


    Hier mal am Beispiel von netcup:

    https://bgp.he.net/AS197540#_prefixes

    https://bgp.he.net/AS197540#_prefixes6


    IPv6: 3 Einträge

    IPv4: nicht gezählt, aber so 20-40 :/


    Edit:

    simple Rechnung: IPv6 wird meist als /32er Block zugewiesen. Daraus kann man 232 /64er-Blöcke machen, d.h. mit einer Zuweisung erhält ein Provider/Hoster/... direkt mal 4.294.967.296, also etwa 4 Milliarden 64er-Netze. Damit kommt man eine gute Zeit lang aus, bzw. man hat soviel 64er-Netzte wie es IPv4-Adressen gibt... ich denke damit dürften die meisten nur noch ein oder zwei Einträge in der globalen Routing-Tabelle brauchen und nicht mehr unzählige, Ausnahmen bestätigten die Regel ;)

  • mainziman , julian-w: Ihr sprecht valide Punkte an, aber der Ton dieser Diskussion driftet mir persönlich etwas zu sehr ab.

    Wäre es eventuell möglich, das anhand der konkreten RFCs zu erörtern?


    Der informational RFC 3769 "Requirements for IPv6 Prefix Delegation" (https://tools.ietf.org/html/rfc3769) etwa nennt Größen von /64 bis /48. Er sagt auch:

    Code
    The mechanism should allow for delegation   of more than one prefix to the customer.

    Um also Prefix-Delegation an einen Kunden von mehr als einem /64 durchführen zu können, muss der Prefix entweder größer als /64 sein, oder es müssen mehrere geroutete /64 zu diesem Zweck bereitgestellt werden. Man kann es also so oder so sehen, und der RFC ist „nur“ "informational".


    Wer nun "customer“ ist, ist eine Frage der Perspektive. Im Grunde wird eine vernünftige Zuteilung nicht den einzelnen Rechner, sondern eine Organisationseinheit bezeichnen. In diesem Fall tut man gut daran, es als Provider der RIPE gleichzutun, indem man einen Block reserviert und nur das untere Ende tatsächlich zuweist. So ist Platz für Wachstum.


    Für den Endkunden sollte ein /64 an sich nun wirklich genügen. Der einzelne Rechner kommt mit einem Präfix von /128 aus, sofern keine Privacy Extensions verwendet werden. Bei Business-Anschlüssen, sollte man diese Vorgehensweise nach Größe der Organisation aber überdenken.


    Möchte man Mappings des IPv4-Adressraums nach IPv6 durchführen, gilt ein /72 oder gar nur ein /96 als ausreichend. Auch dafür gibt es einen RFC - https://tools.ietf.org/html/rfc6052, der als Proposed Standard festgelegt ist für den aber Errata existieren.


    Der Designfehler besteht im Grunde nur darin, wie man „customer“ definiert.

  • julian-w versteht es leider nicht, daß es einfach kompletter Quark ist, daß ein /64-Prefix als "kleinste Einheit" zu sehen ist

    weil unter diesem Gesichtspunkt in der Annahme er liege richtig, hast gerade ein paar Bits mehr als bei IPv4 und da ist es nur logisch

    daß viele auf IPv6 'pfeiffen' ..

    und es mehr Sinn macht sich was sauber zu überlegen, an Stelle von Design-Fehlern durchzudrücken ...

    Ein paar Bits mehr heißt konkret: aus grob 4 Milliarden IPv4-Adressen werden bei IPv6 1,8 * 1019 Subnetze (NICHT Adressen), die alle quasi unendlich viele Geräte beinhalten können (ebenfalls 1,8 * 10.19). Natürlich sind dies nicht alle nutzbar, einige sind reserviert für link-local, broadcast etc.


    Aber ich denke die Dimensionen werden damit klar, es sind nicht "ein paar Bits mehr", sondern eher soviel mehr Netzte das man diese unmöglich verbrauchen kann. Und wie oben erwähnt is der Sinn hinter diesen gigantischen Netzte die globale Routingtabelle so klein und einfach wie möglich zu halten.


    Edit:

    Und die saubere Überlegung ist im Beitrag oben drüber: "unendlich" große Subnetzte -> nie mehr wird ein Subnetz voll weil zu viele Clients darin sind; Extrem große Blöcke -> Routingtabelle bleibt klein und sauber. Und man hat genug Adressen/Netze für immer und ewig. Drei große Vorteile für IPv6 zu IPv4.


    Ihr sprecht valide Punkte an, aber der Ton dieser Diskussion driftet mir persönlich etwas zu sehr ab.

    [Ironie]Ja aber...aber... ich wurde hier als erste als Käse-Redner beschimpft ;( Okay gut eigentlich wollte ich mich auch ganz raushalten :( [/Ironie]

  • dann sag mal was ich nicht vestehen will,

    bevor ich Dir sage, was Du leider nicht verstehen kannst;:P

    Sehr konstruktiv ... - Was ich vorhin schon sagte, führe doch bitte mal deine Punkte exakt auf, was denn alles so verkehrt ist.

    Und ich meine jetzt nicht deine Gegenfragen etc. sondern einfach mal klar definierte Punkte, denn sonst bringt, was ich und andere jetzt schon mehrfach sagten, die Diskussion hinten und vorne nichts.


    Zum Thema, dass sich Provider streuben IPv6 einzuführen, widersprechen die Statistiken der LIRs.

    Hier eine Liste von ISPs Deutschland, welche IPv6 zumindest erreichbar ausgerollt haben - https://ripeness.ripe.net/4star/DE.html
    Hier eine Liste von ISPs in Deutschland, welche Messbaren IPv6 Traffic liefern - https://ipv6ripeness.ripe.net/5star/DE.html (wie gemessen wird und wieso die Messung viel weniger ISPs listet, als wirklich vorhanden sind, steht im Dokument)

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

  • Ein paar Bits mehr heißt konkret: aus grob 4 Milliarden IPv4-Adressen werden bei IPv6 1,8 * 1019 Subnetze (NICHT Adressen)

    schön wärs:P


    da aus dem Zwang mehr als nur ein /64 zuzuweisen zu müssen,

    glztg. die oberen Bits teilweise ebenfalls reserviert sind: sprich die oberen 16-bit nur 0x2000 bis 0xEFFF sein können;

    weiters sind noch 2001:0::/23 (Teredo) bzw. 2002::/16 (6to4) nicht im nativen Adressraum, welche ich hier aber explizit ignoriere

    ein /60 ist die kleinste sinnvolle Größe LANsetig je Zugang ist, reduzieren sich die Bits gewaltig;


    bleiben also Eqn1.gif mögliche IPv6 Zugänge

    f. Infrastruktrur und so ziehe ich etwas ab, und nehme daher Eqn3.gif


    verglichen mit IPv4 bei dem 224.0.0.0/8 wegfällt, 127.0.0.0/8 bzw. 0.0.0.0/8 ebenso wegfällt

    auch die IP Adressen nach RFC1918 od. besser RFC3330 wegfallen, überschlagen 3 Klasse A-Netze

    es bleiben daher rund Eqn2.gif IPv4-Adressen

    f. Infrastruktrur und so ziehe ich etwas ab, und nehme daher Eqn4.gif


    da bei IPv4 vieles nur einen Zugang mit RFC1918 bekommt und auch nicht mehr haben soll/will/kann/braucht

    und hier IPv4-Adressen gleichbedeutend mit Zugängen ist,


    f. den Aufwand sind 28-bit nicht wirklch die Welt ...:/

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • da aus dem Zwang mehr als nur ein /64 zuzuweisen zu müssen,

    Der existiert nicht, sonst würden Endkunden nicht (fast) immer /64 bekommen ^^ Große Firmen brauchen natürlich mehr.

    f. den Aufwand sind 28-bit nicht wirklch die Welt ...

    Die Rechnung verstehe ich nicht ganz, aber du meinst 28 Bit sind effektiv nutzbar. Sonderadressen machen übrigens weniger wie 2% aus (Quelle Wiki). Ich bin mal so frei und sage: wir gewinnen nur 16 bit (im Vergleich zu IPv4) dazu, du gingst ja scheinbar von 28bit aus.


    Bei 48 bit ergeben sich grob 2,8 * 1014 komplette Netzte... reicht doch und das ist noch eine schwere Untertreibung in Wirklichkeit sind es viel mehr. Und man muss bedenken wir reden hier nicht von Adressen, sondern von Netzen. Der Adressraum ist einfach so unvorstellbar groß, daher tut es nicht weh /64er als kleinste Einheit anzusehen. Wenn man selbst etwas rumrechnet merkt man dies, dann muss man diese "Verschwendung" (die keine ist) einfach akzeptieren. Lieber zu viel wie zu wenig Adressen ;)


    Bislang wird im Internet sowieso "nur" 2000::/3 geroutet (RFC4291), der Rest ist reserviert, z.B. für den Fall das man merkt man war doch zu verschwenderisch, hat man noch ganz schön viele Adressen auf Halde. Aber alleine in diesem /3er Netz sind so viele 64er-Netzte enthalten (2,3 * 1018)... das kann man sich nicht vorstellen 8| Selbst wenn 99% für Infrastruktur drauf geht ist immer noch mehr wie genug da. Jedes BIt mehr verdoppelt die Anzahl verfügbarer Adressen.

  • Aber was will Lieschen Müller mit einem /56er oder /64er Netz?

    Lieschen Müller braucht auch keine eigene IPv4-Adresse. ? Größere IP-Netze brauchst Du für den entsprechenden Anwendungsfall. Als letztes Glied in der Kette kriegst Du dann vielleicht nur Deine dedizierte IPv6 Adresse im Plesk.

  • Der Unterschied zwischen 2 hoch 30 und 2 hoch 58 ist schon mehr als nur ein gigantischer. Wäre in etwa so, als ob jeder, dem eine IPv4 zugeteilt ist stattdessen ca ein Viertel aller verfügbaren v4 Adressen in /60 Netzwerken zugeteilt bekäme. Da kann aber jeder eine Menge Kühl- und Gefrierschränke versorgen. Und für das ein oder andere sonstige Elektrogerät reicht es auch noch. Keine Ahnung ob momentan jemand ein Viertel der verfügbaren v4-Adressen "besitzt". Denke aber eher nicht ;). Nicht mal Google, Facebook und Amazon zusammen. :) Und bei v6 wären das ganze Netzwerke, nicht einzelne Adressen.

  • Das unterstreicht auch die die Verschwendung.

    Wobei man dazu sagen muss, ein /32er-Netz entspricht "quasi" einer IPv4-Adresse, dann relativiert sich das alles auch wieder etwas ^^ (ich weiß ist natürlich etwas ungenau, da nur ein kleiner Teil von IPv6 geroutet wird etc., aber gibt einem ein ungefähres Gefühl)


    Am Beispiel von netcup: netcup hat zwei /32er-Netzte für sich beantragt (und eines für einen Kunden wohl) und laut he.net 61,184 IPv4-Adressen verteilt auf 46 Prefixe. Der Faktor 2 gegen 61.184 ist extrem. Auch 2 Einträge in der Routing-Tabelle gegen 46, wobei es sicherlich noch krassere Fälle gibt.

  • eripek Wenn Du bei RIPE IPv6 haben willst, bekommst Du ein /32. Das unterstreicht auch die die Verschwendung.

    „The minimum allocation size for IPv6 address space is /32.“ (https://www.ripe.net/publications/docs/ripe-707)

    Das stimmt für PA Space, nicht aber für PI Space, hier ist die minimum allocation size ein /48, sprich /48 ist das maximalste, was in der global Routing Table auftauchen sollten.

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

  • Geht das nur mir so?

    Irgendwie hat es sich eingeschlichen hier im Threat 3-4 Diskussionen gleichzeitig zu führen.

    Anstatt ein eigenen Thread zu starten, gerade wenn mehr als eine Antwort zu erwarten ist,

    wird hier wild durcheinander geschrieben und jeder, der nicht halbstündlich dieses Threat aufruft,

    ist mit der Flut an Beiträgen überfordert. Die IPv4/IPv6 Diskussion hätte gut und gerne ein eigenes

    Thema mit 10 Seiten gefüllt. Aber auch andere Themen wurden hier über mehrere Seite diskutiert,

    ohne dass irgend ein Ergebnis für die Nachwelt über bleibt. Und dies natürlich quer durcheinander.

    In diesem Jahr sind hier 38 Seiten zusammengekommen und wir haben morgen erst Woche 3.

    Vielleicht kann man solche Themen auch an andere Stelle diskutieren, damit die einzelnen Antworten

    auch aufeinander folgen und für ein Nachschlagen möglich macht für die Leute die vor ähnlichen

    Problemen stehen. Was jetzt nicht nur auf,für die IPv4/v6 Diskussion gemeint ist sondern mehrere

    Themen der letzten Zeit. Gerade wenn 2-3 bestimmte Leute mit diskutieren und es (wiedermal) in

    eine Endlosdiskussion läuft, kann man solche Themen besser ignorieren. ;)

    It's me, only me, pure michi 🦆

    RS 1000 SAS G8 | Cyber Quack

    VPS: 50 G7 |B Ostern 2017|200 | Karneval | piko

    WH: SmallEi | Adv17 Family |4000 SE|1000 SE

  • da bei IPv4 vieles nur einen Zugang mit RFC1918 bekommt und auch nicht mehr haben soll/will/kann/braucht


    und hier IPv4-Adressen gleichbedeutend mit Zugängen ist,

    Ich halte jedenfalls nichts davon, Adresskonzepte zur Glaubensfrage zu erheben und den jeweils anderen zu bezichtigen, „Käse“, „Quark“ oder Nonsense zu verbreiten, wenn noch nicht einmal die IANA-Gremien diese Streitfragen völlig geklärt haben.


    1. Zu RFC1918 bietet RFC4193 ein Äquivalent.

    2. Der gesamte IPv4-Adressraum kann auch kleinstmöglich in den 32 Bit „ganz hinten“ abgebildet werden, wobei -ich habe es schon erwähnt- eher die Tendenz in den RFCs zu Bit 72-80 geht. TRT/RFC 3142 macht den Rest.

    3. Die global nutzbaren Transition-Mechanismen aus der Diskussion auszuklammern, halte ich ebenfalls für weise, will man nicht Äpfel mit Birnen vergleichen. Der Zweck ist ja schon einmal ein anderer...


    Was /64 als kleinste Einheit anbelangt:

    1. Wieder stelle ich die Frage: definiere „customer“!? - Das Endgerät benötigt nur eine einzelne Adresse (/128) - soweit ist das richtig aber,

    2. den Entwicklern von IPv6 ging es ja bereits darum, den Adressbedarf von IoT zu decken und

    3. größtmögliche Freiheit innerhalb einer Zuteilung zu gewähren, respektive

    4. den Wechsel eines Prefix einfacher zu gestalten als bei IPv4 - allein dieser Aspekt bewirkt, dass man in die oberen Bits ausweichen muss.


    Insofern sind /64 für den Endkunden zwar auf den ersten Blick zwar großzügig, möglicherweise dann aber doch nicht so übertrieben - geht man davon aus, dass auch in diesem Adressraum Transition-Mechanismen udgl. angesiedelt werden könn(t)en.
    Es gibt zumindest Raum für Reserve-Zuteilungen im eigenen Netz. Immerhin ist der obere Adressraum immer noch beinahe doppelt soviele Bit lang, wie bei IPv4.


    Die Problematik sehe ich eher beim Verständnis jener Entwickler, die für Zuteilungen wie durch DHCPv6 recht große Prefices vorsehen, weil ohnehin so viele Adressen zur Verfügung stünden - was sich, auf Bitebene verlagert, rasch relativiert. Insofern ist Deine Kritik ja berechtigt.


    SLAAC mit link-Lokalen Adressen nimmt jedenfalls Niemandem etwas weg. Die Lektüre von zumindest https://de.wikipedia.org/wiki/IPv6#Autokonfiguration wird angeraten. Die dort erwähnten RFC 3315 und 3736 sollten unter Maßgabe des RFC 3769 gesehen werden.

    Es ist ja auch nicht gerade so, als ob RFCs sich niemals widersprechen würden... Darum heisst RFC auch Request for Comments und nicht Standards Code of Conduct for Operations. ;)

  • Das stimmt für PA Space, nicht aber für PI Space, hier ist die minimum allocation size ein /48, sprich /48 ist das maximalste, was in der global Routing Table auftauchen sollten.

    Als jemand, der in einem Verein tätig ist, dem ein /32 zugewiesen wurde, kann ich bestätigen, dass tatsächlich für Provider-AS ein /29 reserviert wird, von dem zunächst nur das /32 zugeteilt wird. Der Rest wird auf Abruf bereitgehalten. Lediglich die Verpflichtung, die Adressen binnen 2 Jahren auch zu verwenden (weiter zu vergeben) wird dabei eingegangen.

  • Geht das nur mir so?

    Irgendwie hat es sich eingeschlichen hier im Threat 3-4 Diskussionen gleichzeitig zu führen.

    Anfangs sah ich das ähnlich.


    Jedoch weiß man ja nie was für eine Lawine losgetreten werden kann bei einer doch recht simplen Frage/Aussage. Zudem muss ich immer schmunzeln wenn sich 1 1/2 Seiten um das selbe Thema drehen und auf einmal einer auf ein Thema eingeht welches vor ~5 Seiten zuletzt debattiert wurde. Das lockert aus meiner Sicht das ganze wieder auf :)


    Zudem ist es ja nun mal der Thread mit dem längsten Thema 8o