[IPv6] Prefix delegation mit zugewiesener /64

[Bob.Dig]

Wobei ich das ja vorhin bereits selbst schrieb.

With that exception, and despite the comments above about the routing
architecture and the design of SLAAC, using an IID shorter than 64
bits and a subnet prefix longer than 64 bits is outside the current
IPv6 specifications, so results may vary.

 

[RalphS]

Totaler Quatsch den du erzählst!

.... Stell dir mal vor, ich hab ein bissel Ahnung von Netzwerken. Nicht viel -- aber definitiv mehr als der Normalo da draußen.

Mir ist selber klar, daß die Adressen absehbar reichen werden. Du sagst es auch selber: wir haben nicht die etwa 2^32 Adressen in v4 wegen Vergabe zu Anfang. 50% des Adressraums -- "A-Netze" sind pauschal einfach nicht da, sie können nicht genutzt werden und werden auch nicht genutzt.

Das ändert alles nichts an der absoluten Verschwendung.
Privatanwender haben derzeit, wenn sie nicht selber Hand anlegen, 254 Adressen zur eigenen Verfügung, irgendwo aus 192.168.0.0/16 als /24er Segment. Das ist bereits mehr als genug.
Wenn wir in Richtung Großunternehmen gucken, dann haben die was aus 10.0.0.0/8, also 2^24 - 2 Adressen, also ~16.7 Millionen oder so.

Jetzt, mit v6, kriegen Privatmenschen mit ihrem Bedarf an <= 254 Adressen stattdessen derer mindestens(!) 2^64. Unternehmen kriegen ggfs mehr. Das sind mehr Adressen, die alle Privatmenschen auf der Welt gemeinsam benötigen - der Einfachheit halber, 2^8 * 10^10 oder (grob abgeschätzt) 3*2^40 Adressen.
Es darf gefragt werden, ob die bis 2^64 fehlenden Adressen für sämtliche Unternehmen der Welt auch noch genügen würden.

Diese ganze Anzahl kriegen aber nicht alle. Sie kriegt ein jeder einzelne Haushalt, der sie noch nicht mal routen darf, wenn es wirklich "nur" diese 2^64 Adressen sind und nicht derer um einen Faktor von 2^8 mehr.

Wenn das nicht Verschwendung ist, dann weiß ich auch nicht. Und ich bin nicht willens, alle möglichen RFC zu umgehen oder zu ignorieren.

Jetzt mal theoretisch, wenn Du auf deinen Geräten alles selbst vergibst und die Netzmaske, ich meine Prefix, entsprechend klein ziehst, dann sollte die Topologie doch trotzdem funktionieren.

Das war der Plan gewesen. Aber da macht mir die Architektur von v6 einen Strich durch die Rechnung sowie der wechselnde Präfix. Augenscheinlich kann ich nur Prefixes kleiner 64 via PD durchreichen und wenn ich nicht grad betriebsblind bin, läßt mich der Cisco keine expliziten Prefixlängen anfordern.
Händisch vergeben ginge prinzipiell, nur wenn ich das mach, dann fliegt mir das beim nächsten Prefixwechsel um die Ohren und ich hab definitiv nicht vor, jeden Tag die Routerkonfigurationen händisch nachzutragen.

Adressen vergeben aus FC00::/7 ist auch kein Problem. Aber damit das "global" funktioniert, müßte es NAT geben, was es nicht tut.

Ich hab deshalb "übergangsweise" erstmal v6 lokal konfiguriert auf Basis des lokalen Adressraums. Gibt zwar auf diesem Weg immer mal Timeouts, bis der Netzwerkstack für die globale Kommunikation auf v4 runterschaltet, aber damit kann ich erstmal leben. Wer weiß, vielleicht kommt Pyur ja doch nochmal irgendwann mit irgendwas < /64 und dann kann ich die Sache nochmal angehen.

 

[Bob.Dig]

Adressen vergeben aus FC00::/7 ist auch kein Problem. Aber damit das "global" funktioniert, müßte es NAT geben, was es nicht tut.

Würde ich so nicht sagen.

 

[Ortan]

Adressen vergeben aus FC00::/7 ist auch kein Problem. Aber damit das "global" funktioniert, müßte es NAT geben, was es nicht tut.

Das ist so nicht ganz richtig, laut RFC 6269 (ist zwar experimentell, wird aber von einigen routern unterstützt). Ich hab es noch nie verwendet, wäre aber einen Versuch wert.

Du kannst dabei anscheinend den Präfix, also die ersten 64 bit der Adresse, verändern. Das ähnlich wie 1:1 NAT im ipv4. Also intern private ipv6 verwenden und mit NPT nach außen "natten".

 

[xexex]

Das ändert alles nichts an der absoluten Verschwendung.

Leb damit! Die Entscheidung hat man getrofen, weil es eben allesamt Adressen sind die von überall auf der Welt erreichbar sein können. Deine "Rechnung" mit den IPv4 Netzen geht gar nicht auf, hier haben die meisten gerade einmal EINE von Außen erreichbare Adresse.

Bei der Entwicklung des Standards gibt man von grössten anzunehmenden Netzen und nicht von den kleinsten, damit eben nicht so ein Mist wie bei IPv4 passiert und durch Stückelung der Netze die Routigtabellen der Router Millionen von Einträgen verwalten müssen.

Ein Provider bekommt auf diese Weise so viele Adressen, dass er NIE noch ein zweites, drittes oder tausendes Subnetz bekommt und eine Firma bekommt so viele Subnetze und Adressen damit sie selbst in 100 Jahren nicht einen zusätzlichen Bedarf anmelden muss und das Netz neu strukturieren muss.

Es gibt schlichtweg genug Adressen und ob die Adresse 20, 30 oder 64 Stellen hat interessiert sowieso niemandem, weil man sich bei IPv6 auch endlich davon verabschiedet hat mit den Adressen, statt DNS zu hantieren. Ich weiß ja nicht weswegen du überhaupt einen Aufstand machst, das Problem ist dein Provider und nicht IPv6. Gäbe es 32bit Adressen, hätte dir dein Provider vermutlich ein /96er Subnetz gegeben und du hättest das gleiche Problem.

Und wieso es überhaupt 64Bit sind?

Der Interface Identifier kennzeichnet einen Host in diesem Netz. Er wird aus der 48-Bit-MAC-Adresse des Interfaces gebildet und dabei in eine 64-Bit-Adresse umgewandelt. Es handelt sich dabei um das Modified-EUI-64-Format.
Auf diese Weise ist das Interface unabhängig vom Network Prefix eindeutig identifizierbar.
https://www.elektronik-kompendium.de/sites/net/1902111.htm

Es gibt bei IPv6 eben keine Netzwerkmasken, kein NAT, kein ARP und keine Umsetzung in Hardwareadressen, alles was man braucht ist in IPv6 Adressen kodiert.

https://community.cisco.com/t5/netw...standing-ipv6-eui-64-bit-address/ta-p/3116953

 

[Bob.Dig]

Das war der Plan gewesen.

Ich überlege jetzt echt, das zu machen, z.B. mit einem /80 Prefix, nur weil ich es, vielleicht, kann. 😁

Ergänzung (12. April 2020)

Es gibt bei IPv6 eben keine Netzwerkmasken, kein NAT, kein ARP und keine Umsetzung in Hardwareadressen, alles was man braucht ist in IPv6 Adressen kodiert.

Und du brauchst keinen Prefix?
Ich denke statt Netzmasken gibt es den Prefix.

 

[RalphS]

Leb damit!

Seufz... und das ist der Grund, warum ich mich mit Fragen in Foren so schwer tu.

Ist es denn wirklich so schlimm, abseits ausgetretener Pfade zu schauen? Muß alles vorgekaut sein?

EUI64 kann man machen, muß man aber nicht. Ich machs nicht. Warum auch? Es gibt nur zwei Ansprüche:
A, die Adresse muß eindeutig sein. In v6 auch global eindeutig.
B, die Adresse muß routingfähig sein.

Das wars. Der Rest ist arbiträr. EUI64 hat auch nix mit ARP zu tun, dafür gibts das Neighbor Discovery Protocol (NDP). IPv6 ist und bleibt Layer 3, es steckt eben nicht "alles" da drin und das ist auch gut so.

Werd mal Richtung NPT gucken. Ich bild mir ja ein, das schon mal auf dem Tisch gehabt zu haben, aber... nicht sicher, warum es dort wieder runter ist. Aber wie gesagt, ich hab die v6 Geschichte für mich derzeit eh eher abgeschrieben.

 

[Bob.Dig]

@RalphS Ich bin kein ITler, werde es aber morgen mal mit meiner pfSense versuchen und berichten, das Teil hat anscheinend die nötigen Optionen.

Versuch macht kluch.

 

[xexex]

Und du brauchst keinen Prefix?

Eine Adresse ist eindeutig und ergibt sich eben aus dem Präfix und den Geräteadresse. Wenn du es genauer nimmst ist eine eine "Maske", sie wird aber nirgendwo verwendet, wie es bei IPv4 der Fall ist.

Netzwerkmasken und NAT hat man bei IPv4 eingeführt, als es abzusehen war, dass irgendwann die Adressen ausgehen. Der ursprüngliche Plan sah sowas gar nicht vor und das es mal 4 Milliarden Geräte geben wird, die über das Netz erreichbar sein werden, war damals unvorstellbar.

EUI64 kann man machen, muß man aber nicht. Ich machs nicht.

Du hast schlichtweg ein gefährliches Halbwissen! Was glaubst du wie bekommt dein PC dann vorm Router oder einem DHCP Server seine IPv6 Adresse?

Eine IPv6-Adresse besteht aus insgesamt 128 Bit. Eine link-lokale IPv6-Adresse wird aus einem Präfix (64 Bit) und einem Suffix (64 Bit) gebildet. Der Präfix für alle link-lokalen IPv6-Adressen ist immer "fe80:0000:0000:0000". Das Suffix (Interface Identifier) ist der EUI-64-Identifier oder IEEE-Identifier, der aus der MAC-Adresse (Hardware-Adresse des Netzwerkadapters) gebildet wird. In der Mitte der 48-Bit-MAC-Adresse (zwischen dem dritten und dem vierten Byte) werden mit "ff:fe" zwei feste Bytes eingefügt, damit es 64 Bit werden. Zusätzlich wird noch das zweite Bit im ersten Byte der MAC-Adresse invertiert. Das heißt, aus "1" wird "0" und aus "0" wird "1".

Mit seiner link-lokalen IPv6-Adresse kann der Host nur im lokalen Netzwerk kommunizieren. Für das Internet braucht er eine zusätzliche IPv6-Adresse, die er sich ebenfalls selber generiert. Dazu muss der Host beim Standard-Gateway (nächster Router) nachfragen, was der Präfix des globalen Adressblocks ist. Dabei handelt es sich um den Adressraum, den man vom Netzzugangsprovider (ISP) zugeteilt bekommen hat. Der Präfix ist in der Regel 64 Bit lang.

Aus dem per Router Advertisement erhaltenen Präfix und dem Interface Identifier der link-lokalen Adresse wird dann die globale IPv6-Adresse gebildet. Danach prüft der Host, ob diese Adresse im lokalen Netzwerk schon vergeben ist (Duplicate Address Detection, DAD). Wenn sie frei ist, weist er die globale Adresse seiner Netzwerkschnittstelle zu.

https://www.elektronik-kompendium.de/sites/net/1902131.htm

Ergo, ist die Länge der Adresse festgelegt, weil die Hardwareadresse bereits 48 Bit lang ist. Daraus wird dann eine linklokale Adresse gebildet mit der dieser Client dann mit dem DHCP Server oder Router kommunizieren kann. Einen Broadcast wie unter IPv4 gibt es bei IPv6 nicht mehr.

Bei der Entwicklung des Standards haben sich ein paar schlaue Köpfe was gedacht und es gibt gute Gründe wieso die Sachen so und nicht anders gelöst sind.

 

[Bob.Dig]

Eine Adresse ist eindeutig

Dir ist schon klar, dass ich die Prefix-Länge, also die CIDR-Notation meinte? Die Netzmaske ist eben nicht ersatzlos weggefallen, sondern ersetzt worden mit z.B. /64, /48 oder /128.

Die Netzmaske (IPv4) oder Präfixlänge (IPv6) kann man auch als Größenangabe eines IP-Netzes verstehen, wobei größere Präfixlängen kleinere Netze bedeuten, da nicht so viele Bits für Geräteteile zur Verfügung stehen.

Eine Adresse ist im Übrigen auch schon mit IPv4 eindeutig gewesen, sonst würde sie nicht funktionieren. Die Geschichtsstunde war also überflüssig.

 

[RalphS]

ich, gefährliches Halbwissen? Okay, ich weiß sicher nicht alles. Aber daß EUI64 ZWANG wäre, wär mir neu.

Sorry, aber das ist das gefährliche Halbwissen, was dem gefährlichen Halbwisser eben jenes unterstellt. Wenn EUI Pflicht wäre, dann wäre die Kennung für EUI64 nicht erforderlich als Infix in den Hostbits und würde auch nicht in jeder gescheiten Implementierung aktivier- und deaktivierbar sein.

Ich glaub ich klink mich hier aus. Meine Antwort hab ich ja: A, /64 gleich es geht nicht; B=leb damit.
Mehr kann ich eh nicht machen. Niemandes Schuld außer meiner eigenen, mehr erwartet zu haben.

 

[xexex]

Wenn EUI Pflicht wäre

Nochmal für dich. Nein die Erstellung der Adressen aus der MAC Adresse ist nicht verpflichtend, aber weil sie ein fester Bestandteil von IPv6 ist, wurde die Länge der IPv6 Adressen entsprechend festgelegt. alternativ erstellen die Clients, um eine Verbindung zum Netzwerk herzustellen, eine komplett willkürliche 64Bit IPv6 Adresse, macht es einen Unterschied?

Du kannst auch gerne versuchen jegliche Mechanismen von IPv6 auszuhebeln, die Adressen von Hand auf allen Clients eintragen und dann "glücklich" werden nur um mit dem Kopf durch die Wand zu rennen? Ich habe es dir mehrfach versucht zu erklären wieso die Adressen eine solche Länge haben, wieso es irrelevant ist, dass von Providern /48 oder /56 Präfixe an Endkunden vergeben werden und wieso die Anzahl der möglichen Adressen bei einem /64 Präfix so hoch ist.

Für dich scheint das aber alles egal zu sein, Hauptsache du kannst deinen Dickschädel durchsetzen und natürlich bist nicht du oder dein Provider "schuld" sondern das IPv6 Protokoll. Ich sage es einfach nochmal zum letzten mal, setze dich mit deinem Provider in Verbindung und gehe dem eigentlichen Problem auf den Grund statt irgendwelchen Mist zu versuchen um entgegen jeglicher Standards eine Krüschellösung aufzubauen.

Vor allem aber wenn du schon vor hast sowieso alles was das Protokoll bietet über den Haufen zu werfen, kannst du auch gleich das IPv6 ganz abschalten, denn letztlich wirst du mit solchen Lösungen bestenfalls intern zwei Geräte zum kommunizieren bekommen, aber niemals eine Verbindung nach "draußen" herstellen.

 

[Evil E-Lex]

Ist es denn wirklich so schlimm, abseits ausgetretener Pfade zu schauen?

Sicherlich nicht. Es ist aber im Bereich der Internetprotokolle, die so haarklein standardisiert sind, nicht zielführend. Die Probleme, die du aktuell hast, sind von den Leuten, die die RFCs schreiben, ja durchaus bedacht worden. Nur bei deinem Provider scheint man sich die RFCs nicht durchzulesen oder absichtlich zu missachten. Du könntest Pyur ja mal fragen, wie sie zu RFC 7368: IPv6 Home Networking Architecture Principles stehen (ja ich weiß, der hat nur "Informational"-Status, sollte aber dennoch nicht leichtfertig ignoriert werden).

Und weil du immer von "arbiträr" schreibst: Natürlich sind die gesetzten Grenzen arbiträr. Nur haben sich da Leute mit befasst, die viel mehr von Netzwerktechnik verstehen, wie du oder ich und das Ganze in einen Standard gegossen. Und damit ist es eben nicht mehr "arbiträr" sondern eben "der Standard".

Der Fehler der hier bei der Standardisierung gemacht worden ist nicht der feste 64 Bit Interface Identifier, sondern dass man nicht festgeschrieben hat, dass ein /56 (oder meinetwegen ein /60) das kleinste Prefix ist, dass man einem Endkunden zuteilen kann. Stattdessen empfiehlt man es nur. Man hat da zu sehr an "das Gute" bei den Providern geblaubt.

 

[Bob.Dig]

Habe meine Test abgeschlossen und muss erst mal feststellen, dass so eine IPv6-Konnektivität festzustellen, insbesondere wenn die Maschinen erst anders betrieben wurden, nicht die einfachste Aufgabe ist.

Noch mal mein Setup kurz erklärt, ich habe ein Kabelmodem im Bridgemodus an eine virtualisierte pfSense angeschlossen, welche mein alleiniger Router ist. Ich habe mehrere Interface(NICs) auf LAN-Seite, davon zwei physikalische und ein paar virtuelle.

Spoiler

Ich hatte erst überlegt, das Ganze nur "virtuell" zu testen, mit virtuellen Maschinen und mich dann aber dagegen entschieden, um ein realistischeres Bild zu bekommen. Im Nachhinein die richtige Entscheidung, auch wenn es, wie gesagt, nicht einfach war. So fand sich z.B. in einem Rechner eine statische Route, die ich nicht angelegt hatte (hab ich noch nie) und ich hatte den Test deswegen schon fast abgeschrieben, bis mir diese Route endlich aufgefallen war. Dies war leider erst nach dem NPt(NAT)-Test.

Alles in allem war der Test erfolgreich, ich habe den einzigen /64er-Prefix von Pyur/Telecolumbus 😉 aufgeteilt in mehrere /80er und den einzelnen Interfacen zugeordnet und per DHCP verteilt. Die Konnektivität war sowohl für mehrere Windows10-Rechner als auch eine UbuntuServer-VM gegeben, auch von außen. Soweit das Positive.

Mein Accespoint, ein älterer Asus-Router im AP-Modus, wollte nicht mitspielen, er verblieb bei IPv4 only und auch das per Wifi an ihn angebundene Android10-Phone bekam keine IPv6, ebenso wie ein per Ethernet angeschlossener MuFu-Drucker von Dell.

Nun ist es so, dass ich diese Geräte schon vorher absichtlich nicht mit IPv6 versorgt habe, sondern an ein Interface angeschlossen hatte, welches kein IPv6 bekam. Hintergrund dafür ist, dass ich im Router diesen Geräten entweder das Internet blockiert oder in ein VPN eines VPN-Anbieters umgeleitet habe, welcher kein IPv6 unterstützt.

Mein Fazit lautet daher, man kann es machen und es funktioniert auch, aber nicht für alle Geräte. Ob dies schlimm ist oder nicht, darf jeder für sich selbst entscheiden. Ich zumindest komme damit zu recht, wenn mein Drucker keine IPv6-Adresse hat.

Da ich aber eh einer /48 Tunnel von HE habe, habe ich mein altes Setup wieder hergestellt.

Dank @Yuuri an dieser Stelle, auch wenn er mit dem Test nichts zu tun hatte, da ich mir dank ihm endlich den Windows Befehl route print gemerkt habe, ohne den wäre der Test nämlich negativ ausgefallen.

 

[Evil E-Lex]

Danke für den Test. Deckt sich mit den Empfehlungen aus den RFCs. Dort wird bei einem /64 Prefix auch zu DHCPv6 geraten. Kannst du Vermutungen dazu anstellen, wie sich das Setup verhält, wenn sich das Prefix ändert?

 

[Bob.Dig]

Dort wird bei einem /64 Prefix auch zu DHCPv6 geraten.

Wobei ich ja eben keinen /64 Prefix hatte, versteh daher deine Anmerkung nicht. Gut, ich hatte einen, den musste ich aber aufteilen, wenn du das meinst. Der Bezug des einen /64 Prefixes war ja nie das Problem.

Bei den LAN-Interfacen kann man natürlich nicht "Track-Interface" benutzen, sondern muss manuell eine IP für das Interface verwenden, in meinem Falle aus dem /80 Prefix, der Rest wird dann mittels des DHCP-Server auf dem jeweiligen Interface an nachfolgende Geräte verteilt. Wenn sich nun der Prefix ändert, was man wie gesagt mit einer bestimmten Option verhindern oder zumindest drastisch hinauszögern kann, dann müsste man tatsächlich die Interface und jeweiligen DHCP-Server aktualisieren. Ich meine aber, dass NPt(NAT) funktionierte.
Das war mein erster Test und ich habe durch die DHCP Server der jeweiligen Interface ULA verteilt und dann mittels NPt(NAT) umgewandelt und das funktionierte fürs erste Interface und, hätte ich die statische Route früher ausgemacht, sehr wahrscheinlich auch für jedes andere Interface. Damit hätte man nur an einer Stelle den prefix ändern müssen. Der einzige Nachteil davon wäre vermutlich gewesen, dass man interne Geräte nicht oder nicht optimal mit ihrer globalen Adresse hätte ansprechen können, denn eigentlich haben sie ja keine.

Wenn sich nun doch gerade der Prefix geändert haben sollte, so besteht das Problem, diesen überhaupt in Erfahrung zu bringen. Zumindest bei pfSense musste ich dafür den DHCP-Client auf der WAN-Seite in den debug modus versetzen, was auch kein Problem ist, um dieses Log dann auszulesen zu können.

Aber wie schon vorher gesagt, mit der Option "Do not allow PD/Address release" am WAN DHCP-Client kann man einen Präfix-Wechsel aktiv verhindern.

 

[Evil E-Lex]

Gut, ich hatte einen, den musste ich aber aufteilen, wenn du das meinst. Der Bezug des einen /64 Prefixes war ja nie das Problem.

Das meinte ich. Ich bezog mich auf das /64 Prefix vom Provider. Sorry, falls das unklar gewesen sein sollte.

Aber wie schon vorher gesagt, mit der Option "Do not allow PD/Address release" am WAN DHCP-Client kann man einen Präfix-Wechsel aktiv verhindern.

Die Option kannte ich nicht. Hab zwar IPv6 mit OPNSense realisiert, dank statischem und großen Prefix hatte ich aber nie die Situation in der ich das benötigt hätte und hab mich daher nie näher damit beschäfigt.

 

[Bob.Dig]

Ich bezog mich auf das /64 Prefix vom Provider.

Ich weiß nicht, ob SLAAC überhaupt PD kann.

 

[Evil E-Lex]

Nee, SLAAC funktioniert nicht mehr, wenn dein Prefix kleiner als /64 ist, da sich SLAAC auf den 64 Bit Interface Identifier verlässt. DHCPv6 oder manuelle Konfiguration sind hier die einzigen Möglichkeiten.

 

[Bob.Dig]

Nee, SLAAC funktioniert nicht mehr, wenn dein Prefix kleiner als /64 ist, da sich SLAAC auf den 64 Bit Interface Identifier verlässt. DHCPv6 oder manuelle Konfiguration sind hier die einzigen Möglichkeiten.

Das war ja klar. Ich hatte mich nur gefragt, ob PD an sich überhaupt mit SLAAC geht. 😉