Dies ist keine vollständige Antwort, da ich noch einige der Probleme durcharbeite, aber hier ist, was ich bisher habe, um ein nahezu identisches Setup bereitzustellen (allerdings aus etwas anderen Gründen).
Die gute Nachricht ist: Es kann innerhalb der Spezifikationen durchgeführt werden. Tatsächlich wurden die Spezifikationen explizit entwickelt, um diese Art der Subdelegation von Präfixen zu fördern, um die Notwendigkeit schmerzhafter Mehrfach-NAT-Schichten weitgehend zu vermeiden und gleichzeitig Flexibilität bei der Strukturierung von Netzwerken zu ermöglichen.
Die schlechte Nachricht ist: Es gibt keine "Out-of-the-Box" -Software, die ein Präfix von einem Upstream anfordert, Adressen und Routen lokal konfiguriert und Unterpräfixe an Downstream-Netzwerke verteilt. Zur Hölle, es scheint nicht einmal möglich zu sein, bereits vorhandene Software unter Linux (ohne Patches) zu verkabeln, um das zu tun, was getan werden muss. Am schlimmsten ist, dass es niemanden wirklich interessiert.
Was ich bisher eingerichtet und funktioniert habe, sieht folgendermaßen aus:
Ich verwende den WIDE DHCPv6-Client ( dhcp6c), um ein Präfix vom "Upstream" -Netzwerk anzufordern. Ich habe diesen Client gegenüber dem DHCP-Client von ISC ausgewählt, da er zum Zeitpunkt der Einrichtung der einzige DHCPv6-Client war, der anderen Schnittstellen automatisch Adressen aus dem empfangenen Präfix zuweist. Ich würde gerne glauben, dass sich andere DHCP-Clients seitdem verbessert haben, aber ich konnte mich an dieser Stelle nicht darum kümmern, dies zu überprüfen.
Leider ist es nicht die delegierten Präfix Details zu seinen externen Hook - Skript aussetzen, was bedeutet , dass man nicht (leicht) Ihre „downstream“ dhcpd Config neu schreiben.
ISC-DHCP-Server (im v6-Modus) zum Zuweisen von Präfixen zum "Downstream" -Netzwerk. Ich habe mich dafür entschieden, weil der DHCP-Server von WIDE, soweit ich das beurteilen kann, Präfixe nur statisch und nicht dynamisch delegieren kann. Es ist überraschenderweise relativ einfach, den ISC-DHCP-Server für die dynamische Präfixdelegierung zu konfigurieren. etwas so Einfaches wie dieses wird den Trick tun:
subnet6 2001:db8:1234:ffff::/64 {
prefix6 2001:db8:1234:a000:: 2001:db8:c0f:aff0:: /60;
}
Dies überwacht die Schnittstelle, an der eine Adresse eingegeben wurde, 2001:db8:1234:ffff::/64und gibt / 60s aus dem angegebenen Bereich aus. Solange Sie die dhcp6cAktualisierung der obigen Konfiguration erzwingen können (nächste!), Können Sie die dhcpd-Konfiguration automatisch aktualisieren, wenn sich Ihr delegiertes Superpräfix ändert.
dhcp6cnimmt, wie bereits erwähnt, einen scriptParameter in seine Konfigurationsdatei, um ausgeführt zu werden, wenn eine DHCPv6-Antwort empfangen wird. Leider werden nur Parameter wie der SIP-Server und DNS-Resolver angezeigt, keine nützlichen Informationen wie das delegierte Präfix. Ich habe also das folgende Skript, um das für mich zu erledigen:
#!/bin/sh
(sleep 3;
base_prefix="$(ip -6 ad sh eth0 | grep 'scope global' | cut -d ' ' -f 6 | cut -d : -f 1-4 | sed 's/00$//')"
if [ "$base_prefix" = "" ]; then
exit 0
fi
cat <<-EOF >/etc/dhcp/dhcpd6.conf
default-lease-time 1800;
max-lease-time 7200;
subnet6 ${base_prefix}00::/64 {
prefix6 ${base_prefix}a0:: ${base_prefix}f0:: /60;
}
EOF
svc -t /etc/service/dhcp6d) &
exit 0
Wenn ich die ganze Arbeit in einer Sub-Shell erledige, kann ich eine Weile warten, sleep 3bis der DHCP-Client die Schnittstelle tatsächlich konfiguriert hat (anscheinend wird das Skript ausgeführt, bevor die Schnittstelle konfiguriert wird). Es funktioniert zuverlässig genug. Beachten Sie, dass mein ISP mir a delegiert /56, weshalb ich nur die zwei Nullen vom empfangenen Präfix entferne. Wenn Sie das Glück haben, ein Ganzes zu erhalten /48, ist die zuzuweisende Pipeline base_prefixviel einfacher.
Was noch nicht existiert und ich bin mir ziemlich sicher, dass das Patchen des Quellcodes erforderlich ist, ist das Einrichten von Routen, wenn ein Präfix delegiert wird. Soweit ich sehen kann, kann kein DHCP-Server die Route automatisch hinzufügen (ich habe WIDE sorgfältig geprüft dhcp6s, es kann es sicherlich nicht und ich kann auf den Röhren nichts finden, was ich vorschlagen könnte dass ISC DHCP es tut). Es gibt nicht einmal die Möglichkeit, einen externen Befehl auszuführen, der das zu delegierende Präfix und die verbindungslokale Adresse des Clients verwendet (ISC DHCP hat dies on commit { execute(...) }, aber es gibt keine Möglichkeit, die verbindungslokale Adresse des Clients ohnmächtig zu machen).
Das Problem ist, dass der Router, der die Delegierung erstellt, ohne diese entscheidende Funktionalität nicht wissen kann, wohin der Datenverkehr für das Präfix danach geleitet werden soll. Das ist eine ziemlich grundlegende Einschränkung, und ich bin ziemlich verblüfft, dass sich anscheinend noch niemand mit diesem Problem befasst hat - oder wenn ja, schweigen sie wirklich darüber.
Ich habe gerade einen Patch für ISC DHCP entwickelt, um der Eval-Funktionalität einen zusätzlichen "Datenausdruck" zu verleihen. Auf diese Weise kann ich ein externes Programm aufrufen, das dann Routen zur Präfixzuweisung und zum Freigeben / Ablaufen hinzufügen / entfernen kann. Der Patch ist unter https://github.com/mpalmer/isc-dhcp/commit/4c8ae763bcf83c9068d57a5d9f570690a581b6d6 verfügbar (gegen ISC DHCP 4.3.1). Ich habe (noch) kein Skript zum Hinzufügen der Route, aber ich werde es wahrscheinlich contribin diesem Zweig hinzufügen , sobald ich es geschrieben habe.
ADDENDUM: Es stellt sich heraus, dass weitere Änderungen erforderlich waren, damit Routen wieder entfernt werden können. Das wurde jetzt dem client-address-data-expressionZweig hinzugefügt , zusammen mit einem kleinen Ruby-Skript, das zeigt, wie alles miteinander kombiniert werden kann.
