Zusätzlich geroutetes /48 oder /56 IPv6 Subnetz

  • Die man bei /80 einfach 1:1 übernehmen könnte und bei /96 oder /112 über einen Hash-Algorithmus oder sowas ...

    Oder einfach ein /64 wie es aktuell ist, ist gar nicht so verkehrt ;) Ehrlich, ich verstehe das Problem nicht. 2^48 global erreichbare Enduser-Router, sprich Gebäude / Firmen / Netze / Server (nicht Geräte!) sollten wirklich für alle Zukunft ausreichen.

  • Und wenn mein Gefrierschrank beschliesst, dass er zukünftig ein Server sein will und ein Netzwerk für all die eingefrorenen Dinge braucht? Für alle Zukunft war schon immer eine gefährliche Aussage.

  • Und wenn mein Gefrierschrank beschliesst, dass er zukünftig ein Server sein will und ein Netzwerk für all die eingefrorenen Dinge braucht? Für alle Zukunft war schon immer eine gefährliche Aussage.

    Dann bezieht er ein /64, /62, /60 oder /56 aus dem /48, das deinem Router in deinem Haus zugeteilt wurde. Nochmal, bitte erst mit dem Thema befassen bevor man irgendwelche Kommentare schreibt.

  • Genau, so wie der Server, für den du ein /48 oder /56 brauchst ;)

    Ich hab nicht gesagt, dass ich ein /48 voll brauche. Ich brauch mehr als ein oder zwei /64 Netze und standardmäßig sind sinnvolle Allokationen eben /56 bzw. /48. /48 auch deshalb, weil dann von einem Kunden in der Regel nie wieder nach weiteren Adressen gefragt werden wird. Der Server ist im Übrigen eine Site, sprich ich habe als ein Kunde einen Server bei Netcup, ähnlich wie ich bei einem privaten ISP einen Vertrag für X Geräte habe.

  • Nebenbei möchte ich auch kurz darauf hinweisen, dass der Satz von Netcup in den Produktdetails "Sie erhalten mit Ihrem Server IPv6 Adressen nach Bedarf" so nicht korrekt ist, da er nicht eingehalten wird.

    Naja, Du bekommst eh beliebig viele /64 dazu. Von kostenlos steht ja nichts dabei :evil::saint:


    Oder anders formuliert: Du bekommst eh 18.446.744.073.709.551.616 Adressen ohne Aufpreis ^^

  • Naja, Du bekommst eh beliebig viele /64 dazu. Von kostenlos steht ja nichts dabei :evil::saint:


    Oder anders formuliert: Du bekommst eh 18.446.744.073.709.551.616 Adressen ohne Aufpreis ^^

    Das stimmt, aber bei IPv6 ist nicht die schiere Anzahl der Adressen interessant, sondern die Segmentierungsmöglichkeiten. Und ich bekomme kein größeres Netz als das kleinstmögliche /64. Selbst wenn ich 256 mal das /64 Zubuchprodukt für 1€ mtl. kaufe, bekomme ich KEIN komplett routebares /56 Netz, sondern 256* einzelne zufällige, nicht zusammenhängende /64 Routen / Prefixe. Entsprechend stimmt das "nach Bedarf" im Sinne vom Design von IPv6 eben nicht ;)

  • Entsprechend stimmt das "nach Bedarf" im Sinne vom Design von IPv6 eben nicht ;)

    Ich hätte auch gerne eine /32 ohne RIPE-Mitgliedschaft ;)


    Oder gleich ein /16. Werde ich aber bei keinem Provider der Welt bekommen 8o


    Ich denke es ist klar, dass Du und einige andere (inkl. mir) nichts gegen ein /56 oder /48 einzuwenden hätten. Der Wunsch dürfte netcup bekannt sein, aber wir können uns hier im Kreis drehen und das zu Tode diskutieren, die größeren Subnetze werden deshalb nicht vom Himmel fallen. Außer den Wunsch mehrfach zu deponieren gibt es nicht viele Möglichkeiten. Wenn die Nachfrage danach wirklich so groß wäre, würde der Markt das schon von alleine regeln. Das ist wohl nicht der Fall. Kunden mit diesem Wunsch muss man wahrscheinlich im unteren ‰-Bereich suchen.


    (Und persönlich ist es mir langsam nicht mehr so wichtig, seit ich Zuhause endlich ein statisches /60 über DSL beziehe.)

  • Das sind auch wieder zwei verschiedene Dinge. Dass es vermutlich weniger Kunden mit richtigem Bedarf daran gibt ist vermutlich so und daran ist auch gar nix auszusetzen. Das sollte mich als Provider aber nicht davon abhalten es korrekt und möglichst umfassend umzusetzen und ob ich ein /64 oder /48 oder /56 an den Kunden route, ändert für mich aufwandstechnisch überhaupt nix.


    Was ich gar nicht mag, ist, wenn man sich als Semi-Professional bzw. mit Halbwissen über so Dinge wie die /64ger Subnetzgröße von SLAAC oder den angeblich möglichen Mangel von IPv6 /48 oder /56 Netzen beschwert. Denn das zeigt einfach ganz klar fehlendes Verständnis auf. Die Adressmenge ist so unglaublich groß und absolut unvergleichbar mit IPv4, das sollte man sich erst mal vergegenwärtigen. Die Leute, die das designed haben (und auch ursprünglich ein /48 pro Site vorgesehen haben), sind nun auch keine Dummköpfe. Klar gibt es den Markt und es gibt auch einige Provider, die IPv6 korrekt und ausreichend umsetzen, Netcup gehört leider nicht dazu. Und da IPv6 immer wichtiger werden wird, fällt für mich zukünftig ein Server-Provider, bei dem es an Adressierungsmöglichkeiten (sprich an einer absolute Grundlage) mangelt, einfach flach. Das ist alles was ich sagen wollte und vielleicht das zuständige Personal mal wachrütteln die Sache zu überdenken, vor allem, da es kaum Aufwand bedeutet, da es sich immer nur um geroutete Netze handelt, keine Interface-Links.


    Netcup mag in erster Linie für Otto-Normal-Verbraucher konzipiert sein, aber ich finde auch als professional User sollte man gute Möglichkeiten finden, und das nicht nur im netcup Pro Bereich, wo gleich mehrere hundert € monatlich fällig werden, nicht bei einem Grundlagenthema, wo nichtmal Hardware bzw. Managed Services etc. relevant sind. Es ist einfach schade, dass es bei einem sonst guten Provider an sowas scheitert.

  • Das stimmt, aber bei IPv6 ist nicht die schiere Anzahl der Adressen interessant, sondern die Segmentierungsmöglichkeiten.

    Die hat man aber auch noch bei größeren Prefix Längen als /64.


    Völlig unabhängig von Adressmangel oder nicht: Ich werde nicht verstehen, warum man sich die größere Flexibilität von anderen Prefix-Längen auch für SLAAC verbaut hat. Gerade das wäre ein weiterer Vorteil für die Segmentierungsmöglichkeiten gewesen, die du ansprichst.

  • Die hat man aber auch noch bei größeren Prefix Längen als /64.


    Völlig unabhängig von Adressmangel oder nicht: Ich werde nicht verstehen, warum man sich die größere Flexibilität von anderen Prefix-Längen auch für SLAAC verbaut hat. Gerade das wäre ein weiterer Vorteil für die Segmentierungsmöglichkeiten gewesen, die du ansprichst.

    Ja aber damit rüttelst du an den Grundmanifesten von IPv6, die kann man nicht mehr ändern. Außerdem wer sagt, dass die 128 bit in Stein gemeißelt sind? Vielleicht wurde der Adressraum damals nur so groß designed, weil man eben bereits 64 bits für den Interface-Teil und SLAAC reserviert hat. Vielleicht spielte auch eine gewisse Lesbarkeit eine Rolle, sprich dass du 64 bit fürs Prefix eines LANs und weitere 64 bit für den Interface-Teil hast und damit exakt eine 50:50 Aufteilung. So oder so, es spielt keine Rolle, wie es ist, ist es irgendwo auch sinnvoll. Jetzt müsste man nur noch das Konzept richtig umsetzen und einem Kunden bei einer Site auch das vorgesehene /48 zuteilen, oder womit ich und viele anderen wohl auch zufrieden wären ein /56 pro Server zubuchbar.

    Zum Beispiel könnte es Netcup so umsetzen, dass man einem Kundenaccount ein /48 zuteilt und dann beliebige /56 Netze daraus einzelnen oder mehreren Servern zuweisen kann, falls man mehrere hat. Das wäre auf jeden Fall deutlich sinnvoller als die kleinen /64 Netze.

  • Ja aber damit rüttelst du an den Grundmanifesten von IPv6, die kann man nicht mehr ändern. Außerdem wer sagt, dass die 128 bit in Stein gemeißelt sind?

    Eine rückwärtskompatible Erweiterung ist ein Problem für dich, aber die Länge der Adresse ist diskutabel? Die Einstellung ist bemerkenswert.


    So oder so, es spielt keine Rolle, wie es ist, ist es irgendwo auch sinnvoll.

    Die funktionierenden Lösungen würden ja auch weiterhin funktionieren. Kein Grund, irgendwas zu ändern. Es würde einfach nur die Möglichkeiten deutlich erweitern - da wo es Sinn macht. Und in der Situation war ich schon öfter. So wie du heute.

    Die Frage ist auch: Warum hat man nur bei SLAAC darauf verzichtet, aber bei DHCPv6 z.B. nicht? Das ist inkonsequent. Wie gesagt, EUI-64 kann es nicht sei, mit EUI-48 stände eine Alternative zur Verfügung, für kürzere Host-IDs hätte man einfach eine Lösung finden können.


    Jetzt müsste man nur noch das Konzept richtig umsetzen

    Gemäß deiner Vorgaben ist das Konzept ja richtig umgesetzt. Es verstößt in keinster Weise gegen die von dir genannten Regeln. Nur kannst du damit nichts anfangen, weil du an die Grenzen des Systems stößt. Wer hat jetzt Schuld? Das System oder der Anbieter?

  • Eine rückwärtskompatible Erweiterung ist ein Problem für dich, aber die Länge der Adresse ist diskutabel? Die Einstellung ist bemerkenswert.

    Nein, was ich meinte ist: Selbst wenn SLAAC zB. nur 32 bits benötigen würde, wer sagt, dass dann eine einzige IPv6 nicht auch nur 128-32, sprich 96 bits lang sein würde? (von Haus aus per Design). Dann ging die Diskussion von vorne los und du würdest SLAAC gern auf 16 bits begrenzen. Du kannst außerdem nicht wirkungsvoll solche Dinge "rückwärtskompatibel" machen, denn sonst hätten wir die Probleme mit IPv4 nicht. Es gibt alte Clients, die nur 64 bit SLAAC können und daher ist das nicht sinnvoll, daran irgendwas zu ändern. Macht auch generell keinen Sinn, du hast mir bisher noch nie erklärt, was dich konkret an 64 bit SLAAC stört. Dass du es nicht verstehst, warum es 64 bit sein müssen, okay, aber gib mir einen stichhaltigen Grund was daran so schlecht sein soll.


    Quote from frank_m

    Gemäß deiner Vorgaben ist das Konzept ja richtig umgesetzt. Es verstößt in keinster Weise gegen die von dir genannten Regeln. Nur kannst du damit nichts anfangen, weil du an die Grenzen des Systems stößt. Wer hat jetzt Schuld? Das System oder der Anbieter?

    Ist es eben gerade nicht, denn ich kenne bei Netcup keine Möglichkeit, ein zusammenhängendes /56, geschweige denn ein /48 zu erhalten.


    Zum Rest kann ich nur sagen: Man kann es einfach halten, oder auch kompliziert machen. Wie gesagt, erklär mir mal, warum du SLAAC nicht sinnvoll erachtest wie es derzeit ist. IPv6 bietet alle Möglichkeiten, die man braucht, man muss sie nur nutzen bzw. der Provider muss sie einen nutzen lassen, in dem er für einen Server ein vernünftig großes Netz zur Verfügung stellt. Selbst zuhause im Privatkundentarif vom Saftladen Vodafone bekomme ich ein /56ger Netz, da erwarte ich von einem professionellen Serverbetreiber schon vernünftige Netzgrößen.


    Als Beispiel: Ich verwalte den Netzanschluss eines Wohnheims, der über das Leibniz Rechenzentrum angebunden ist. Wir haben dort ohne auch nur eine Nachfrage gehabt zu haben von Haus aus ein /48 Netz zugeteilt bekommen. Es gibt in dem Haus 5 VLANs, sprich es werden 5 /64 Netze genutzt. Wo ist das Problem? Nirgends! Wir werden nie wieder bei denen zwecks Adressmangel nachfragen müssen.

  • Quote

    A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.

    Quote

    The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space.

    Quote

    Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either. A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)

    Noch ein paar Auszüge aus den RFCs:

    - https://datatracker.ietf.org/doc/html/rfc3177

    - https://datatracker.ietf.org/doc/html/rfc6177

  • Der Punkt bei SLAAC ist halt, dass es auf MAC Adressen basiert und da diese 48 bits haben sind die 64 bit gar nicht so verkehrt gewählt.

    doch die 64-bit sind Unsinn; denn auch IPv6 setzt ein Layer 2 Protokoll voraus; und bei IPv4 ist es eben z.B. IEEE 802.3 od. IEEE 802.5

    (Achtung hier gibt es keine RFCs haben auch nichts mit IP zu tun, z.B. IPX/SPX baut auf dem selben auf)

    und hier ist nun mal die MAC-Adresse das basierende Adresseirungselement; dass IPv6 da was eigenes hätte wär ganz was neues;

    evt. der Kardinalsfehler vom Design schlecht hin ...


    die MAC-Adresse hat eben 48-bit, von daher ist die Geschichte mit 64-bit kompletter Quark;

    auch der Gedanke an die Zukunft, weil es ja angeblich bei den 48-bit MAC-Adressen eng wird, ist nur bis zum Tellerrand gedacht;


    IEEE 802 ändert sich deswegen nicht ...

    von daher wäre we eben frank_m es gesagt hat ein /80 f. SLAAC hinreichend gewesen,

    od. aus Securirty-Gründen z.B. ein 32-bit CRC auf die 48-bit MAC-Adresse und damit wäre /96 die kleinste Einheit;

    wie gesagt bei IPv6 ist nicht nur das ein Designfehler, da gibts noch andere ...


    darum gilt auch folgende Vergleichsrechnung wenn es um die Adressraumgröße geht ...

    bei IPv4 hast grundsätzlich 32-bit, da aber ab 224 reserviert ist,

    daher 1/8 weniger und noch ein paar fallen wegen z.B. RFC 1918 weg;


    bei IPv6 hast Du daher nur 64-bit, und auch hier fällt rund 1/4 weg (z.B. 0, 1, F);

    und jetzt höre ich ein großes ABER, ja richtig des hinter den 64-bit hast auch bei IPv4, nennt sich RFC 1918;

    und sind bis zu 24-bit auf einmal od. 16 mal 16-bit bzw. 256 mal 8-bit; wobei Du alle im selben LAN verwenden kannst;


    dann dividieren wir mal 3/4 64-bit dividiert durch 7/8 32-bit und sind bei knapp 32-bit;

    welche durch die Vergaben von RIPE u. A. nicht gerade sparsam vergeben werden;

    (ich habe hier z.B. die Mglkt. von z.B. AFFE::/16 od. D00F::/16 als normale globale IPv6-Prefixe mitkalkuliert)


    und f. NUR knapp 32-bit mehr ein derartiger Aufwand ist dann mehr als fragwürdig;

    Grüße / Greetings

    Walter H.


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

  • Macht auch generell keinen Sinn, du hast mir bisher noch nie erklärt, was dich konkret an 64 bit SLAAC stört.

    Mich stört daran genau das, was dich jetzt gerade stört. Du kannst mit dem einen /64 Netz, welches dir zur Verfügung steht, nichts anfangen. Mit mehr Flexibilität bei den Host-IDs könntest du dein Vorhaben direkt umsetzen. In der Situation war ich schon öfter, und es nervt jedes Mal, zu schauen, wo man jetzt mehr Netze herbekommt. Da müssen tausend Randbedingungen stimmen, entweder beim Anbieter oder ein Tunnel oder was auch immer. Anstatt einfach nur ein wenig mehr Hinrschmalz ins SLAAC zu stecken und damit den Adresspool nutzbar zu machen, den man bekommt.

  • Naja, 32 bit mehr als 32 bit ist ja nicht doppelt so viel, auch nicht 32 mal so viel sondern 4 Milliarden mal so viel wie vorher. ;)

    wenn es nicht so traurig wäre würde ich fast lachen;

    das ist auch f. den Klimawandel verantwortlich; ma braucht net f. jede(s) Rindviech, Schaf, Ziege od. sonst ein Huftier a Ohrmarke mit IP-Adresse ;)

    Grüße / Greetings

    Walter H.


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

  • wenn es nicht so traurig wäre würde ich fast lachen;

    das ist auch f. den Klimawandel verantwortlich; ma braucht net f. jede(s) Rindviech, Schaf, Ziege od. sonst ein Huftier a Ohrmarke mit IP-Adresse ;)

    So wichtig mir Umweltschutz ist: Das hat gar nichts mit dem eigentlichen Thema zu tun oder?

  • Newly created posts will remain inaccessible for others until approved by a moderator.

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • :pinch:
    • 8|
    • :cursing:
    • :wacko:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3
    • :!:
    • :?:
    The maximum number of attachments: 10
    Maximum File Size: 1 MB
    Allowed extensions: bmp, gif, jpeg, jpg, pdf, png, txt, zip