Beiträge von frank_m

    Nein. Eine Site ist im allgemeinen ein Kunde an einem Standort.

    Laut rfc4949 (Glossary) ist eine Site:

    Code
    A facility -- i.e., a physical space, room, or building together with its physical, personnel, administrative, and other safeguards -- in which system functions are performed.

    Hört sich für mich eher nach Rechenzentrum denn nach Kunde an.

    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.

    Hat er ja. Ein /64 Netz anstatt eine /128 Adresse. Oder sogar mehrere /64 Netze bei Bedarf.

    Aber wie schwer ist es eigentlich zu verstehen, dass IPv6 nicht für einzelne /64ger Netze designed ist?

    Gar nicht, ich hab das verstanden. Aber wie schwer ist es zu verstehen, dass genau das das Problem ist?

    Und das es nur aufgrund der Einschränkungen eines verhältnismäßig winzigen Teils der Technologie (SLAAC), während ein Großteil der IPv6 Suite auch heute schon anders arbeiten könnte? Zumal SLAAC ja ursprünglich mal für kleine und ressourcenmäßig eingeschränkte Geräte und private Nutzung vorgesehen war, während für die Adressvergabe im professionellen Umfeld eher DHCPv6 angedacht war. Das hat sich in der Praxis allerdings sehr aufgeweicht, zugegeben.

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

    Ein /48 pro Server halte ich für übertrieben. Und als ein Kunde mit mehreren Servern hast du ja auch mehrere /64 Netze.

    Wir sind ja gar so weit auseinander. Wir haben beide das Problem, mit dem einen /64 Netz im Grund nicht zufriedenstellend arbeiten zu können. Nur die über die Gründe dafür sind wir unterschiedlicher Auffassung.

    Dort ist übrigens nur von "Home-Sites", sprich klassischen Endkunden von ISPs die Rede

    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.

    Wenn du öfter in der Situation bist ist, ist der Grund genau der selbe, dass du beim falschen Provider unterwegs bist.

    Das sind leider viele.

    Die RFCs sind wenn man so will die globalen Gesetze für die technische Realisierung von IT-Lösungen.

    Ich weiß, was Standards sind und wie sie funktionieren. Ich bin selber in diversen Standardisierungsgremien aktiv unterwegs, u.a. ISO und CEN.

    Ich erwarte auch nicht, dass man da jetzt was dran ändert. Aber da ist man damals schon bequem gewesen.

    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.

    Das mir das hier nicht weiterhilft, ist mir klar. Dennoch kann man ja offen darüber diskutieren, was schief gelaufen ist, damit man es beim nächsten Mal besser macht.

    Einfach an die RFCs halten und gut ist.

    Genau das tun ja alle. 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.

    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.

    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?

    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.

    Ich hab u.a. ne .biz Domain im Einsatz und keinerlei Probleme damit. Grund war ebenfalls dass de Wunschdomain für .biz frei war. Ein Kollege hat sich seine Wunschdomain bei ".in" gesichert. Geht halt auch. ;)

    Zeigt der erste Screenshot nicht einen Packet Loss von 18% zum ersten externen Gerät an?

    Irrelevant. Bei MTR zählt nur die Statistik zum Zielhop. Alles andere dazwischen ist wertlos, da viele Router ICMP gar nicht oder nur mit geringer Priorität behandeln.

    Wenn wirklich 18% Paketverlust zum ersten Hop auftreten würden, wieso sind dann alle weiteren Hops wieder ok? Eben. Deshalb zählt nur der letzte Hop

    Sehr gut möglich... Meine Konfiguration ist wie gesagt eine gesunde Mischung aus Trial & Error und Inspiration aus diesem Thread bzw. diesem Blog-Post. Dort scheint alles an das primäre eth0-Interface angebunden zu sein. Dort wird aber auch Ubuntu, netplan und LXD verwendet...

    Wenn jetzt alles läuft, dann kannst du es natürlich so lassen. Scheinbar haben die IPv6 Implementierungen heutzutage kein Problem mit mehreren Interfaces im gleichen Subnetz.

    Nur kurz der Vollständigkeit halber: In dem Blogpost geht der Kollege hin und weißt seinem Netzwerkinterface die Adresse als /128 zu, nicht als /64. Damit liegt sie natürlich außerhalb des /80 Netzes für die Bridge. Das wäre IP-mäßig sauber. Aber wie gesagt: Offenbar ein rein kosmetisches Problem.

    Bei meinen letzten Setups hier bei netcup war ein ndppd notwendig, da die Netze zu dem Zeitpunkt eben *nicht* gerouted waren.

    Also ich glaube, hier geht in der Bezeichnung was durcheinander.

    Geroutet werden die Subnetze auf jeden Fall, zumindest bis in die Infrastruktur unmittelbar "vor" dem zuständigen Host. Andernfalls wäre meines Erachtens gar keine Kommunikation möglich, auch schon nicht mit der "Standard-IP".

    Bleibt die Nutzung von ndppd. Die Infrastruktur von netcup muss ja letzlich wissen, wohin sie ein spezifisches Paket zustellen muss. Also schickt sie ein "neighbor solicitation, who has [...]" raus, und zwar als Multicast. Das muss natürlich zunächst mal vom Host mit der gesuchten IP beantwortet werden.

    Multicasts werden üblicherweise nicht weitergeroutet, also z.B. von einem Host in seine virtuellen Maschinen. Folglich wissen die virtuellen Maschinen auch nicht, dass sie gesucht werden und antworten nicht. Hier kommt der ndppd ins Spiel, der die Antworten in Vertretung für die VMs übernimmt. Anschließend landen die Pakete auf dem Host und können an die VMs weitergeroutet werden.

    Meines Erachtens gibt es zwei Alternativen zu ndppd: Ein Multicast Router, der die neighbor solicitations durchleitet, oder eine transparente Bridge, in der alle Netzwerkinterfaces des Hosts und der VMs zusammengeschaltet werden, die auch L2 uneingeschränkt durchlässt. Letzteres ist nicht gut falls man nur eine öffentliche IPv4 hat. Firewall in den VMs ist ein weiterer Aspekt.

    Ich habs gerade mal auf meiner VM getestet und von außen einen Ping auf eine Adresse aus meinem /64 Netz abgesetzt. Wie erwartet kamen direkt die neighbor solicitations für diese IP. Ich hab sie dann mal temporär einem dummy Netzwerkdevice zugeteilt, und sofort wurden die Pings auch beantwortet.