Automatische Prefix Delegation im Layer 3 Netzwerk

Technik
1

Nachdem ich jetzt auch endlich zu Babel bin, standen wir vor dem Problem, dass wir Prefixe im Layer 3 Netzwerk verteilen müssen, die sich jeden Tag ändern.

Ich bin erstaunt wie einfach das mit Babel und Source-Routing geht. In einer Nacht habe ich mit einem Freund ein Konzept entwickelt und umgestzt, welches Prefixe im Netz verteilt.

Es werden einfach die Source-Specific default Routen genommen und alle anderen babel routen. Wir iterieren dann einfach durch eine Permutation der noch nicht announcten Prefixe der default routen durch, bis wir nen freien haben und assignen uns den selber. Es läuft bei uns im Backbone schon erfolgreich (bis jetzt nur 3 Nodes…^^).

ToDo:

  • Mehr Randomizierung
  • Collision Detection mit Auflösung
  • assign_prefixes und removes_prefixes noch ohne uci (openwrt unabhängigkeit)
  • Prefix-Größen und Längen Konfigurierbar machen
  • Skripte schöner machen

Ist noch von dem PR abhängig:

Aufbau:

config interface 'wan6'
	option ifname '@wan'
	option proto 'dhcpv6'
	option reqprefix '57'

  +----------+     +-------+     +------------+    +-----------+
  | Fritz!Box+-----+OpenWrt+-----+ Mesh|Hop|1 +----+Mesh|Hop|2 |
  +----------+     +-------+     +------------+    +-----------+

Edit:
Es empifehlt sich für den DHCP-Server folgendes zu setzen:

    option dhcpv6 'server'
    option ra 'server'
    option leasetime '3m'
    option ra_useleasetime '1'

Leider sind die Clients so „doof“ und erkennen nicht, dass macher Prefix deprecated ist. :confused:

4 „Gefällt mir“
2

Das hat Bieringer schon 2013 in seinem Paper zur IPv6-Konferenz-Frankfurt bemängelt:

Nachgeschalteter Netgear Router (OpenWRT)
Fritz!Box verteilt /62 Subnetze via DHCP an nachgelagerten
Router
keine Signalisierung bei Präfix-Wechsel
=> Netzwerk hinter OpenWRT-Router offline

Anscheinend ist das durch liftime settings nicht mal eben zu beheben.

  • Ist das systemimmanent?
  • Was ist hier die tiefere Ursache??
    (Fragt ein Laie, den das seit längerem nervt…)

Was meinst Du?

Zitiertes Paper:

Erfahrungen mit einem nativen IPv6-Zugang, Dr. Peter Bieringer, IPv6-Kongress Frankfurt/Main, 06. - 07. Juni 2013

3

Bei mir funktionierts? Ich hatte überlegt nen neuen Assoc über hostapd zu erzwingen.
Wir könnten vll unterschiedliche Metriken pushen? Ich muss mal gucken.

4

Können wir nicht nen Router Advertisement aktiv an den Client senden?

5

Das wäre auch meine erste Frage. Ich bin mir nicht sicher, ob ich das Scenario und dessen Anforderungen richtig verstehe, aber wenn es offenbar „nur“ darum geht, Prefixe und default-Routen zu verteilen, warum nimmt man da DHCP? Router Advertisement ist da viel robuster und einfacher. Ich glaube, es ist bei DHCP einfach nicht vorgesehen, dass der server sagt „Deine Adresse ist deprecated“. Das geht immer vom Client aus, und solange die Lifetime nicht abgelaufen ist, geht der davon aus, dass noch alles gültig ist.

7

Ich bin gerade wieder bei der Situation wo ich das brauche, ich muss mal gucken wie ich die Prefixe an den Client mit aufsteigender Metrik vergebe. :slight_smile:

8

Hä??? Ist das jetzt ne Frage oder eine Antwort? Ich bin doch nicht derjenige, der DHCP ins Spiel gebracht hat.

9

Whups, hab deine Antwort falsch gelesen.
Hast du ne ahnung ob ich da eine Metrik irgendwie mit advertisen kann?

10

Es gibt die Möglichkeit, die default Route mit einer „Preference“ zu versehen, die aber nur drei Werte annehmen kann, siehe RFC 4191

1 „Gefällt mir“
11

Super danke, ich guck mal wie ich das machen kann!

12

@Skeptiker
Ich hab nochmal ein bisschen nachgelesen auch im Source-Selection RFC. Dort gibt es z.B. die Möglichkeit „deprecated“ addresses zu haben, auf denen trotzdem noch Traffic empfangen werden kann. Ich frage mich dann manchmal wie das so ist bei Netflix, wenn meine IPv6 Addresse dann deprecated wird, was dann passiert.

Ich frage mich noch so ein bisschen wie ich das alles konfigurieren kann. Es gibt dabei sehr wichtige Unterschiede zwischen valid_lft und preferred_lft. Läuft die preferred_lft ab, wird die Source-Addresse als deprecated makiert und nichtmehr zum Senden bevorzugt benutzt (kann sie aber noch).

Es gibt bei OpenWrt aber eig nur die config option:

ra_lifetime:  Advertised router lifetime (in seconds)

und

ra_useleasetime:  Limit the preferred and valid lifetimes of the prefixes in the RA messages to the configured DHCP leasetime

und die kann man durch leasetime verändern.

Ich hab mal angefangen das in OpenWrt hinzuzufügen:

1 „Gefällt mir“
13

Ich hab hier nochmal mehr dazu geschrieben, was ich vorhabe:

1 „Gefällt mir“
14

Ich hab heute mal geadded, dass wir die preferred_lft viel geringer setzen können, als die valid_time:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033033.html

Nach meiner Vorstellung kann ich nun aus der Kombination mit filter_prefix und einem geringen preferred_lft, ohne probleme schnelle prefix-wechsel durchfühen.

1 „Gefällt mir“
15

@Polynomdivision Dein Ansatz sieht interessant aus. Mach doch mal ein Issue in Gluon als RFC auf. Wir (Christof, Sargon) hatten uns ja schon Gedanken darum gemacht. Unser Ansatz sieht etwas anders aus, aber vielleicht lässt sich da was zusammenbauen.

16

Ich hab noch mehr Code in der Hinterhand. :wink: Ich release das mal bald und linke das. Muss mal aufräumen.

17

Was ich auch noch gerne hätte, wäre sowas:

18

Mal fertig implementiert:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033590.html

19

Ich kann jetzt jetzt das hier machen ohne einen Tunnel aufrecht zu erhalten zum Gateway:

ul3c
ul3c1771×505 96.3 KB

Um direkt automatisch die Prefix Delegation zu machen kann man auch direkt mit shell (zum Beispiel 60s addieren):

date '+%d %b %Y %T' --date="@$(($(date +%s)+60))"
1 „Gefällt mir“