gistfile1.md

• Grundsituation:
• Es gibt einen Community-Mesh-Prefix (z.B. /18)
• Der Prefix ist in Blöcke von z.B. 4 Adressen unterteilt (ein /18 ergibt 4096 Blöcke a 4 Adressen)
• Knoten multicasten periodisch Listen ihrer reservierten Blöcke, um Konflikte zu erkennen
• Jeder Knoten hat irgendeinen Identifier (untere 8 Byte der IPv6-Adresse?)
• Jeder Knoten unterhält eine Liste der Blöcke mit zuständigen Knoten
• Situation: Ein Knoten braucht neue Adressen (z.B. auch nach Boot)
• 1. Der Knoten wählt zufällig einen der Blöcke aus (gegebenfalls unter Ausschluss schon bekannter von anderen Knoten verwendeter Blöcke)
• 2. Der Knoten fragt mehrmals per Multicast im Mesh, ob der Block schon verwendet wird
• 3. Gibt es kein NACK innerhalb von $TIMEOUT, wird der Block verwendet, ansonsten zurück zu 1.
• 4. Wird der gleiche Block gleichzeitig von einem anderen Knoten angefragt, so gewinnt der Knoten mit niedrigerer ID (Request von Knoten mit niedrigerer ID als der eigenen wird als NACK interpretiert)
• ( 5. Falls das scheitert, bekommen alle weiteren Clients eine vordefinierte, gleiche IP, die nur in Richtung Internet funktioniert. )
• Ein Block wird so lange behalten, wie eine Adresse aus dem Block verwendet wird, und kein Konflikt erkannt wird
• Situation: Konflikt durch sich auflösenden Netsplit
• Einer der vergebenen Blöcke (bzw. alle bis auf einen) müssen neu vergeben werden
• Regeln:
• Der Knoten mit den meisten aus diesem Block vergebenen Adressen darf ihn behalten
• Bei Gleichstand: niedrigere ID behält den Block
• Knoten versuchen Blockfragmentation zu vermeiden (Blöcke erst füllen bzw. leerlaufen lassen entsprechend der Leasetime)
• Situation: der Client fragt Adresse an, für die ein andere Knoten zuständig ist

1. Es wird beim ursprünglich zuständigen Node angefragt

• Adresse gehört tatsächlich dem Client: Node antwortet mit ACK
• Adresse gehört tatsächlich dem Client und der Client ist die einzige vergebene Adresse aus dem Prefix: Node antwortet mit ACK und überantwortet den ganzen Block dem anfragenden Knoten (+ Multicast-Announcement im Mesh)

2. Reagiert der ursprünglich zuständige Node nicht innerhalb von $TIMEOUT2, so versucht der Knoten selbst, für den Prefix zuständig zu werden (nach gewöhnlichem Ablauf)
3. Falls eine IP nicht per Proxy renewed werden kann und der Block nicht übernommen werden kann, bekommt der Client ein NAK und darf nach einer neuen IP fragen

• GIADDR zum merken der Gateway IP?
• "Eigenschaften"
• Alle Knoten wissen welche Blöcke von welchen Knoten verwaltet werden.