ubuntuusers.de

Hallo,

meine Frage hat eigentlich nichts direkt mit Ubuntu zu tun, es ist ein OS-übergreifendes Thema. Folgendes: ich spiele/teste gerade ein wenig mit IPv6 im lokalen Netz herum und gebe meinen Rechnern statische Adressen. Wenn ein Rechner zB die statische v4-Adresse 192.168.2.1 hat, geb ich diesem die v6-Adresse fd00:192:168:2::1/64 v.a. um wenig Wiedererkennungswert zur v4-Adresse zu haben.

Wenn ich das richtig verstanden habe, darf man alle v6-Adressen, die mit fd anfangen, also (fd00::0/8) für interne Zwecke verwenden wie eben zB die privaten v4-Adressen aus 192.168.0.0/16 oder 172.16.0.0/12. Ist das so richtig? Oder kann ich hier wenn ich das so lasse mit irgendwelchen Schwierigkeiten/Problme rechnen wenn ich derartige statische v6-Adressen verwende?

cosinus schrieb:

[…] darf man alle v6-Adressen, die mit fd anfangen, also (fd00::0/8) für interne Zwecke verwenden wie eben zB die privaten v4-Adressen aus 192.168.0.0/16 oder 172.16.0.0/12. Ist das so richtig?

Ja.

Oder kann ich hier wenn ich das so lasse mit irgendwelchen Schwierigkeiten/Problme rechnen wenn ich derartige statische v6-Adressen verwende?

Adressen aus dem Bereich fd00::0/8 haben "scope global", sind also im Prinzip beliebig routing-fähig. Der Administrator eines Routers ist dafür verantwortlich, dass Pakete mit solchen Absender-Adressen im eigenen Verantwortungsbereich bleiben.

Wenn Du ein Netz 192.168.2.0/24 in den Netz-Anteil einer IPv6-Adresse aufnimmst – Dein Beispiel fd00:192:168:2::1/64 – solltest Du dafür sorgen, dass die Netze 192.168.2.0/24 und fd00:192:168:2::/64 denselben topologischen Gültigkeitsbereich haben, sonst keine Garantie für Eindeutigkeit der IPv6-Adressen und mögliche Fehlfunktion.

Danke für deine AW. Wie sorge ich denn dafür? Lt. wiki hab ich das so verstanden, dass alles was mit fd00 anfängt automatisch nicht ins Internet geroutet wird. 😕

cosinus schrieb:

[…] Lt. wiki hab ich das so verstanden, dass alles was mit fd00 anfängt automatisch nicht ins Internet geroutet wird.

„Automatisch“ geht da gar nichts, es sei denn, Du verstehst darunter, dass der Administrator des Routers, mit dem Du per IPv6 kommunizierst, für seinen Bereich alles richtig gemacht hat.

Der Administrator eines Routers an der Grenze eines Verantwortungsbereiches muss durch sachgerechte Konfiguration seines Routers sicherstellen,

• dass aus dem fremden Bereich keine IP-Pakete mit Absender-Adressen aus dem Bereich fd00::/8 übernommen werden und

• dass solche Pakete seinen Bereich nicht in Richtung des fremden Bereiches verlassen.

Das kann man durch Routen, Routing-Regeln und/oder Paketfilter realisieren. Das gilt übrigens bei den privaten IPv4-Adressen genau so, ist also nicht neu.

Neben fd00::/8 ist auch noch fc00::/8 mit ähnlicher Funktionalität definiert. Prefixe aus fc::/8 sollen aber zentral verwaltet werden – leider gibt es m.W. dafür aber keine zentrale Stelle. Deshalb wirft man Pakete mit solchen Adressen am besten weg.

Im Idealfall generiert man sich (z.B. aus der MAC vom Router/Homeserver) einen Teil vom Unique Local als Prefix. So gibt es später auch bei VPNs etc pp keine Kollisionen.

mfg Stefan

kB schrieb:

Das kann man durch Routen, Routing-Regeln und/oder Paketfilter realisieren. Das gilt übrigens bei den privaten IPv4-Adressen genau so, ist also nicht neu.

Dass man das selbst für IPv4 machen muss ist mir echt neu. Ich dachte bisher immer, dass Router/Firewalls automatisch keine Pakete mit privaten Adressen ins Internet routen 😕 (Internet-Router machen das doch auch so) Was stellt man denn konkret zB bei einem Speedportrouter ein, wenn eh kein Router im Internet Pakete mit solchen Adressen weiterleitet?

Neben fd00::/8 ist auch noch fc00::/8 mit ähnlicher Funktionalität definiert. Prefixe aus fc::/8 sollen aber zentral verwaltet werden – leider gibt es m.W. dafür aber keine zentrale Stelle. Deshalb wirft man Pakete mit solchen Adressen am besten weg.

Angeblich ist nur fd00::0/8 momentan für private Adressen zugeteilt werden...

cosinus schrieb:

[…] Dass man das selbst für IPv4 machen muss ist mir echt neu. Ich dachte bisher immer, dass Router/Firewalls automatisch keine Pakete mit privaten Adressen ins Internet routen 😕 (Internet-Router machen das doch auch so

… weil fähige Administratoren ihre Geräte eben so konfiguriert haben.

Was stellt man denn konkret zB bei einem Speedportrouter ein, wenn eh kein Router im Internet Pakete mit solchen Adressen weiterleitet?

Bei einem Gerät für Endverbraucher ist bzgl. IPv4 vom Endverbraucher gar nichts einzustellen, weil der Hersteller schon durch Konfiguration dafür gesorgt hat, dass nur Pakete mit einer einzigen zulässigen Absender-Adresse (die sog. öffentliche IP) emittiert werden. Das ist vorhersehbar immer die gleiche Aufgabe und kann bei Consumer-Geräten daher vom Hersteller geleistet werden. Bei „richtigen“ Routern ist das anders.

Außerdem sorgt der Administrator des Providers dafür, dass von jedem seiner Kunden nur Pakete mit der diesem Kunden zugewiesenen IP-Adresse angenommen werden.

[…] Angeblich ist nur fd00::0/8 momentan für private Adressen zugeteilt werden...

Wer gibt Dir so etwas an? Siehe z.B. RFC 4193 und RFC 5156: "Unique Local IPv6 Unicast Addresses" sind fc00::/7. Der Bereich fc00::/7 ist nach den Regeln der IPv6-Adressrechenkunst die Vereinigung der beiden Bereiche fc00::/8 und fd00::/8, dabei soll fc00::/8 weltweit zentral verwaltet werden (was ohne eine entsprechende Zentralstelle natürlich nicht funktionieren kann) und fd00::/8 soll dezentral (also privat) verwaltet werden.

kB schrieb:

… weil fähige Administratoren ihre Geräte eben so konfiguriert haben. Bei einem Gerät für Endverbraucher ist bzgl. IPv4 vom Endverbraucher gar nichts einzustellen,

Und wann bitte bei welchen Geräten muss man denn nun tätig werden?

Wer gibt Dir so etwas an? Siehe z.B. RFC 4193 und RFC 5156: "Unique Local IPv6 Unicast Addresses" sind fc00::/7. Der Bereich fc00::/7 ist nach den Regeln der IPv6-Adressrechenkunst die Vereinigung der beiden Bereiche fc00::/8 und fd00::/8, dabei soll fc00::/8 weltweit zentral verwaltet werden (was ohne eine entsprechende Zentralstelle natürlich nicht funktionieren kann) und fd00::/8 soll dezentral (also privat) verwaltet werden.

Siehe https://de.wikipedia.org/wiki/IPv6

Derzeit ist nur das Präfix fd für lokal generierte ULA vorgesehen. Das Präfix fc ist für global zugewiesene, eindeutige ULA reserviert.

Ist das falsch oder verstehe ich da etwas falsch?

kB schrieb:

Außerdem sorgt der Administrator des Providers dafür, dass von jedem seiner Kunden nur Pakete mit der diesem Kunden zugewiesenen IP-Adresse angenommen werden.

Das wäre schön, aber man kann davon pauschal nicht ausgehen. Man wird halt keine Antwort bekommen, alles andere ist eher ein Wunsch.

mfg Stefan

Jetzt mal im Ernst Leude 😊 es schwirren doch keine Pakete mit SRC/DST 192.168.0.0/16 im inet herum. Gängige Lösungen bzw DSL-Router und andere erkennen doch was aus den privaten Segmenten kommt und was nicht. So ganz verstehe ich diese Hinweise deswegen dazu nicht. 😕

Moment mal werden die Unique Local Unicast nicht vom Endgerät erstellt. Nach einem Zufallsprinzip.

cosinus schrieb:

Jetzt mal im Ernst Leude 😊 es schwirren doch keine Pakete mit SRC/DST 192.168.0.0/16 im inet herum. Gängige Lösungen bzw DSL-Router und andere erkennen doch was aus den privaten Segmenten kommt und was nicht.

Ein Router ist hier gar nicht erforderlich. Du hast z. B. in deinem System 2 Routen konfiguriert: eine definierte Route in das Subnetz 192.168.0.0/16 (oder gleichwertig) und eine default Route für die anderen destination-IP-Adressen (die nicht zum 192.168.0.0/16 gehören).

Wenn Du eine IP-Adresse, die keinem Gerät zugewiesen ist, aus dem Subnetz 192.168.0.0/16 (via _definierte_ Route) erreichen willst, macht dein System sofort ein oder mehrere arp-request(s) und wenn keine Antwort kommt, wird das ganze verworfen. D. h., es geht keine Anfrage via default Route an der Router, für diese nicht zugewiesene IP-Adresse aus dem internen Subnetz.

Anders sieht es aus wenn eine "interne" IP-Adresse erreicht werden soll, für die es auf dem System keine definierte Route in deren Subnetz gibt. Dann wird die Anfrage via default Route an den Router weitergeleitet (obwohl es eine interne IP-Adresse ist).

Das kann man z. B. mit tcpdump und traceroute anschaulich machen.

Ja richtig. Was im lokalen Subnetz ist, ist "auf Verbindung" und für alle anderen Ziele also die unbestimmte IP muss ein Router eingetragen sein. Ich versteh jetzt aber nicht wie Pakete mit anderen Zielen aus anderen privaten Subnetzen im Internet herumschwirren sollen.

Anders sieht es aus wenn eine "interne" IP-Adresse erreicht werden soll, für die es auf dem System keine definierte Route in deren Subnetz gibt. Dann wird die Anfrage via default Route an den Router weitergeleitet (obwohl es eine interne IP-Adresse ist).

Wenn mein DSL-Router oder was auch immer für ein Gateway dieses Ziel nicht kennt, wird er diese Pakete doch verwerfen, weil diese aus einem bei mir nicht existenten privaten Bereich sind. Ich hab aber schon Leute gesehen, die meinen, man müsste irgendwelche Adressebereiche für intern verwenden, die eigentlich öffentliche Netze sind.

cosinus schrieb:

Wenn mein DSL-Router oder was auch immer für ein Gateway dieses Ziel nicht kennt, wird er diese Pakete doch verwerfen, ...

Das ist die Frage, die evtl. nur dein Provider beantworten kann, wenn er nachschaut was am für deinen Router (border device) zuständigen Gateway, an "privaten" (fürs Internet nicht geeignete) IP-Adressen ankommt. Wenn dort nichts ankommt, dann hat dein Router diese verworfen bzw. nicht weiter geleitet.

Welcher Provider ist denn so doof und leitet Pakete mit privaten Adressen als SRC oder DST weiter? Was anderes ist VPN aber stehen ja die internen eigentlichen Ziele im Datenbereich eines jeden Pakets. SRC und DST sind da immer die IP-Nummern der beiden beteiligten VPN-Gateways.