Text noch nicht fertig

I2P

Der Permalink zu diesem Text lautet permalink.de/tino/i2p3

I2P DNS

Im Internet gibt es DNS. Im I2P gibt es nichts dergleichen. Schade eigentlich, denn es wäre schon, so etwas zu haben.

Grund

I2P arbeitet anders als das Internet. Leider. Und zwar, weil es keine Ports in den Tunneln kennt.

Deshalb muss jedes Ziel in die hosts.txt eingetragen werden. Wir wissen vom Internet, das das niemals so skaliert.

Die hosts.txt ist eine Krücke, die nur existiert, weil die "Namen" (es handelt sich um öffentliche Schlüssel) zu lang sind als dass man sie als URL eingeben kann (konforme Implementierungen erlauben nur max. 63 Zeichen für einen Domainnamen). In einem URL hat man nur wenige Stellen, an denen die Angabe des Hosts sich befinden kann. Tatsächlich aber ist es am einfachsten, diesen ganzen Zinnober nicht zu verwenden, sondern eine ordentliche, implizite Namensauflösung einzuführen.

Dazu kommt noch, dass der Name selber nicht ausreicht. Wir brauchen auch einen Service-Typ. Im DNS kann ich Mail und WWW auf denselben Host legen indem ich verschiedene Ports angebe. In I2P brauche ich keine Ports, aber verschiedene Schlüssel. So etwas wie Port-Nummern gibt es in I2P nicht, es gibt nur Tunnel-Deskriptoren.

Damit wir aber auch SMTP usw. für I2P inplementieren können, brauchen wir einen Service-Typ. Dieser sollte nicht in-band, sondern out-band ermittelt werden. In-band macht das zu viel Probleme.

Die Idee ist also, einen weiteren Aufsatz auf I2P zu machen, den Resolver.

Die Idee dahinter sind folgende 3 Dinge:

• Ich bin in der Lage, die Subdomain zu verwalten. So lange ich die Informationen publiziere, sind sie im Verzeichnis. Höre ich auf zu publizieren (nach 1 Jahr oder so) verfällt das "Lease" und andere können übernehmen.
  
  Derzeit kann jeder unterhalb meiner Domain beliebiges registrieren. Das ist gut und schlecht zugleich. Gut ist: Sterbe ich ab, kann jemand übernehmen. Schlecht ist: Damit kann mir jemand auch etwas kaputtmachen. Ganz mies ist: Der Key, den ich publiziert habe, kann man nicht übernehmen (der ist ja nur public), und den Eintrag kann man auch nicht überschreiben.
  
  
• Man müsste keine Namen mehr erfassen, sondern man broadcastet diese ins Netzwerk. Der, der älter ist, überlebt. Es gibt dazu ein verteiltes (dynamisches!) System das die Namen erfasst. Da die Information sehr groß werden kann, teilt man die Information am Besten in Teilstücke auf.
  
  Die Registrierung sollte automatisch und dynamisch sein, getreu dem Motto "bad news travels fast".
  • Ich verteile meinen Namen an meine Nachbarn, die alle meinen Namen dadurch kennen. Von dort wird ein Pfad um Namensarchiv aufgebaut und der Name dort gesperrt.
  • Im Netz gibt es mehrere Rechner die sich auf den Namen spezialisieren.
  • Die Rechner, die einen Namen weitergeleitet haben (das sind die aller Nachbarn und die Pfade zu den Archiven) werden im Speicher geblockt.
  • Die erfolgreiche Registrierung wird mit der Node-ID an den registrierten Rechner rückgemeldet.
  • Fällt nun der Link zu einem der Archive direkt oder indirekt aus, wird das an den Rechner mit den Namen mitgeteilt.
  • Dieser überprüft, ob er redundant genug ist, und baut evtl. einen neuen Pfad zu einem Archiv auf.
  • Ein Rechner ist niemals sein eigenes Archiv, und das eigene Archiv ist niemals direkt der nächste Hop. So wird Verteilung erzwungen.
    
    
• Die Sucher nach Name läuft auf dem üblichen Weg ab. Jeder Rechner sucht den Namen, wenn er ihn nicht kennt. Kann er den Rechner nicht erreichen überprüft er das Archiv ob die gecachte Information noch gültig ist.
  
  
• Man kann das Resolving auf Serviceklassen ausdehnen. Um SMTP zu machen suche ich den Eintrag für den SMTP-Service, um HTTP zu machen denjenigen für HTTP. Die entsprechenden Tunnel unterscheiden sich ja.

Resolving

(Und jetzt muss ich zuhause nachgucken, ich habe da schon einen englischen Text vorbereitet.)