Beiträge von MeisterYoda

    Lach. Ja. Wie eine Garantie klingt mir das nicht.

    Der Durchschnitt ist ja auch erfüllt, wenn sie mir Nachts wenn ich nichts brauche, 12 Stunden lang 2Gb zur verfügung stellen und dann wenn ich es bräuchte, garnichts...

    Gut es kommt halt darauf an, wieviele VMs maximal auf welchem Uplink liegen. Ich weiß nicht ob Dual Sockel Server eingesetzt werden, aber im Falle von Single Sockel würden ja maximal 32 VMs auf einem Host liegen (64 Cores / 2 ded = 32). Die Server werden mind. mit je 1x10Gbit/s auf zwei verschiedene Switche im Cluster angebunden sein, dh. ich würde mal von mindestens 20 Gbit/s pro Node ausgehen, im Zweifel eher 40. Im ersteren Fall wären es ca. 625 Mbit/s, im zweiteren doppelt so viel was theoretisch immer anliegen müsste. Vorausgesetzt es werden ausschließlich Single Socket Server eingesetzt...

    Das ist alles nicht so schlimm, wie einen Mailserver mit einer neuen IP an den Start zu bringen.

    +1


    Grundsätzlich sollte man solche Dienste wie einen Mailserver nie auf der festen "Grund"-IP des Servers betreiben, sondern hierfür eine zusätzliche IP buchen, die man mitnehmen kann. Bei Netcup gibt es hierbei zwei Möglichkeiten:

    • Die bequeme, aber teure Failover-IP (5€ mtl.); diese kann zu jeder Zeit per SCP sowie API umgeschaltet werden.
    • Die etwas unbequemere Variante (normale IP für 1€ mtl.): Diese Variante kann man wählen, wenn es nicht darauf ankommt, ob der Service mal einen Tag ausfällt (wie es beispielsweise bei einem Mailserver mit backup MX u.U. der Fall ist). Zum Kündigungsdatum des alten Servers wird die IP wieder erneut zuweisbar. Leider ist (mir) nicht bekannt, zu welchen exakten Uhrzeiten die Löschung des Servers vorgenommen wird. Vermutlich wird das zu einer festen Zeit 1x täglich per cronjob ausgeführt, aber es könnte auch zufällig sein, sodass man ein gewisses Zeitfenster einer downtime bzgl. der IP einplanen sollte. Edit: Zu einem Preis von 45€ lässt sich die Zusatz-IP zu einem fix definierten Zeitpunkt umbuchen.

    Hallo Claudia,


    vielen Dank für die Weiterleitung! Genau darum ging es mir auch in dem ganzen Thread, sprich auf das Thema aufmerksam zu machen, dass es durchaus gute Anwendungsfälle gibt, für die man ein größeres zusammenhängendes Netz braucht (bzw. praktisch ist). Ich denke in diesem Thread ist nun sehr viel Für und Wieder gesammelt und das entsprechende Personal bei Netcup kann sich gut ein Bild darüber machen. Ob, wie und in welchem Umfang es eine Umsetzung bzw. Korrektur der bestehenden Umsetzung gibt, ist dann natürlich Netcup überlassen bzw. letztendlich natürlich dem Markt an sich.


    Beste Grüße

    Eben. Dort ist die Konstellation eine andere mit mehreren Endgeräten und ggf. auch mehreren Netzen (Gastnetz etc.). Außerdem ist dort immer von "sites" die Rede, also nicht von einzelnen Servern, sondern vom Standort, in diesem Fall also wohl dem Rechenzentrum.


    Ein Server ist erst mal nur ein Endgerät, der nicht nur eine Adresse, sondern direkt ein ganzes /64 Netz bekommt. Für evtl. Container oder VMs kannst du ein oder mehrere weitere /64 Netze bekommen. Wo siehst du da jetzt einen Widerspruch zu deinen Zitaten? Dazu kommt folgendes: Es gibt in Standards obligatorische Vorschriften ("shall") und Empfehlungen ("should"). Letztere kann man machen, muss man aber nicht. Welchen Typs deine Zitate sind, ist ja offensichtlich.

    Nein. Eine Site ist im allgemeinen ein Kunde an einem Standort. Der Standort ist Nürnberg, ich bin Kunde von Netcup mit meinem virtuellem Root-Server, als Router für meine privaten Netzwerke. Entsprechend ist der Root-Server eine Site (= Ich als Kunde an diesem Standort beim Provider Netcup). Ein Server kann durch Virtualisierung / Container / VPNs etc. und sonstige Dienste deutlich mehr, als ein Client-Rechner zuhause im /64ger LAN, der braucht tatsächlich nicht mehr. Nach deinem Argument könnte man die zusätzlichen IPv4 Adressen abschaffen, denn es handelt sich ja nur um einen Rechner / Server - der braucht doch keiner weitere Adressen.


    Und natürlich wird jetzt die RIPE Netcup den IPv6 Pool nicht entziehen, weil sie nicht genügend Adressen zuteilen. Aber wie schwer ist es eigentlich zu verstehen, dass IPv6 nicht für einzelne /64ger Netze designed ist? Wie oft muss man sich hier noch wiederholen?

    -> Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default.

    -> significantly more than a single /64


    Die Empfehlung von einem /48 pro Kunde entstammte genau dem Argument, dass so sichergestellt ist, dass jeder genügend Adressraum erhält. Nur hat man halt für Otto-Normalkunden gesehen, dass vermutlich auch ein /56 reicht mit seinen 256 /64 Subnetzen, was deutsche Provider ja auch so umsetzen. Dies gilt allerdings nicht für professionelle Server, dort sollte im Allgemeinen weiterhin ein /48 das Maß der Dinge sein (bzw. pro Kunde, der dann das am Besten flexibel an seine gebuchten Server verteilen kann). Ich denke es steht ganz klar im RFC, dass die endgültige Verteilung Sache der zuweisenden Entity (Netcup) ist, aber, unter allen Umständen sichergestellt und oberste Priorität haben sollte, dass ein Kunde niemals unter Adressmangel leidet. Und diesem Punkt Netcup mit seinen /64ger Netzen sicherlich NICHT nach.

    Du kannst ja nicht sagen, dass sich das Angebot und die Umsetzung von netcup nicht an die RFC hält. Und es führt genau dazu, dass man in eine Sackgasse läuft, aus der man als Endanwender einen Ausweg suchen muss, der technisch dann oft eine Krücke ist.

    Ich hab vorhin beispielhaft 3 Zitate aus zwei der relevanten RFCs gepostet. Dort sogar wichtige Teile markiert, und daran sieht man sehr deutlich, dass sich Netcup nicht daran hält. (Dort ist übrigens nur von "Home-Sites", sprich klassischen Endkunden von ISPs die Rede, von einem professionellem Server-Betreiber, wo die Kundenanzahl nochmal eine ganze Hausnummer weniger ist, ganz zu schweigen.

    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.

    Wenn du öfter in der Situation bist ist, ist der Grund genau der selbe, dass du beim falschen Provider unterwegs bist. Leider sind Netcup nicht die einzigen, die das bzgl. IPv6 falsch machen, ich kenn sogar welche die einzelne /128 Adressen zuteilen, die würde ich direkt in die Nachhilfe schicken.

    Das Thema Erweiterung von SLAAC: Schön und gut solche Ideen zu haben, aber in der Praxis hier und jetzt bringt es genau... nix? Es gibt den Standard nun mal und den kann man nicht so ohne weiteres ändern -> siehe IPv4. Irgendwann muss man sich einfach mal an die RFCs halten und dort gilt seit eh und je: ein /64 pro LAN und don't mess with it! Die RFCs sind wenn man so will die globalen Gesetze für die technische Realisierung von IT-Lösungen. Die haben sich schlaue Leute ausgedacht und auch wenn nicht alles komplett optimal ist muss man es akzeptieren und sich daran halten. Daher ist der Vergleich "mich stört das was dich stört" falsch. Mich stört, dass sich Netcup nicht an die standardisierten RFCs bzgl. der Realisierung von IPv6 hält, so wie sie gedacht sind. Dich stört der Inhalt der RFCs an sich. Wenn mich ein deutsches Gesetz stört, gehe ich auch nicht zur Polizei und verlange eine andere Handhabung, sondern dann gehe ich in die Parlamente, denn nur dort kann man es ändern. Deine Vorschläge sind von daher in diesem Forum etwas fehl am Platz, wenn sie auch berechtigt sein mögen, aber das ist einfach das falsche Forum.


    @mainziman Ich denke Teile der Antwort gelten auch für dich. Ja, dhcpv6 ist Murks und gerade daher ist es eben auch kein Ersatz für SLAAC, weil es genug Clients gibt, die damit nicht klar kommen. Sonst gäbe es die Probleme ja auch erst gar nicht, wenn man das /64 weiter zerbricht, was nachdrücklich nicht empfohlen wird. Einfach an die RFCs halten und gut ist.

    Zitat

    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.

    Zitat

    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.

    Zitat

    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

    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.


    Zitat von 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.

    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.

    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.

    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 ;)

    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.

    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.

    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.

    Flexibel einstellbar. Ein /64 Netz für einen VPS reicht ja wahrscheinlich jedem, wenn er dann einfach weiter zerlegen kann mit allen gängigen Anwendungsfällen. Für meine VPN Konfigurationen und Container brauche ich nicht jeweils ein /64er Netz.

    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.

    Die standardmäßig enthaltenen /64 sind bei netcup aber von NDP abhängig, die werden eben nicht direkt auf einen Server geroutet. Insofern belasten sie das (interne) Netz schon, da für jede einzelne angeforderte Adresse aus dem /64 die Tabellen weiter gefüllt werden. Es ist ja kaum davon auszugehen, dass die bestehenden /64 plötzlich verschwinden oder nicht mehr vergeben werden, wenn man zusätzlich ein /48 oder /56 einführt. Fakt ist, dass es (für netcup) komplizierter werden würde, wenn man plötzlich vom /64 abweicht.


    Ob es sinnvoller wäre, wenn man jedem Server z.B. fix eine einzelne IPv6-Adresse aus einem /64 zuteilt und darauf das eigene /64 (oder größer) routet, will ich nicht beurteilen. Es wird schon seine Gründe haben, warum es so implementiert wurde. Daran werden wir als Kunden wahrscheinlich nichts ändern können. :)

    Ja, wir sprechen hier glaube ich von zwei unterschiedlichen Punkten. Ich will nichts am standardmäßig inkludierten /64 Netz ändern, denn dort verhält es sich genau so wie du schreibst und das ist auch sinnvoll so. Ich hätte gerne sinnvollerweise ein zusätzliches /56 oder /48, das wie die derzeitigen zubuchfähigen /64 Netze auf eine Adresse des Servers im standardmäßig inkludierten /64 Netzes geroutet werden. Dann hast du dort auch kein Problem mit NDP etc.

    Jeder Router und jeder Switch hat ein Limit. Egal ob MAC-Adressen oder IP(v6) Subnetze/Adressen, da kann man nicht unendlich viele darüber laufen lassen. Und dann kommt noch hinzu, dass größere Subnetze in der Theorie mehr Last für das Netzwerk bedeuten, da die Kunden sich höchstwahrscheinlich kein /48 nehmen, nur um tausende coole PTR-Records anzulegen. :)


    Nur zur Klarstellung: Ich wäre auch absolut dafür, dass es ein /56 oder /48 gibt. Aber es ist wahrscheinlich nicht immer so einfach in historisch gewachsenen Netzwerken bzw. Systemen.

    Falsche Denkweise, denn es ist genau anders herum: Je länger das Prefix (und damit desto kleiner die Subnetze), desto MEHR Aufwand ist es für Router, da die Routingtabellen größer werden und jeweils mehr Bits verglichen werden müssen. Jetzt interessiert sich das Internet aber nicht für die einzelnen /64 Subnetze, die Netcup intern verteilt, sondern das Internet routet einfach nur die zwei /32 Netze zu Netcup. Und für Netcup intern, ist es widerrum egal, da "die paar /64ger Routen" im Vergleich zu Internet-Scale Routingtabellen absolut nur der Tropfen auf den heißen Stein sind. Wenn du so argumentierst wäre es für die Netcup-Router deutlich mehr Last 65.536* ein /64 zu einem Server als ein einziges /48 dorthin zu routen.


    Es hat übrigens schon seinen Grund, warum ein /48 das kleinste im Internet routebare Netz ist ;)


    Zitat von KB19

    Ob /64 für SLAAC so intelligent war, sei mal dahingestellt. Wäre es kleiner, würden die Provider halt ebendiese Größe herausgeben. Da hast Du schon recht.


    Welche Größe würdest du denn vorschlagen?