Änderungen

=== Layer 3 Routing ===

=== Layer 3 Routing ===

Um verbindungen zwischen den hoods und lokalen exit nodes zu ermöglichen müssen wir routing informationen zwischen den teilnehmern austausschen. Als Protokoll welches sowohl mit v6 als auch mit v4 umgehen kann eigent sich Babel. Um sicher zustellen das das Layer 3 Routing nicht manipuliert wird müssen wir ein verifikations medium einsetzen bsp. ein tunnel protokoll z.b. gre, tinc, usw.. Eine volle verschlüsselung ist dabei nicht notwendig. Evtl. bietet Babel selbst auch eine möglichteit der verifikation, somit könnte man den overhead des tunnels kompensieren.

Um Verbindungen zwischen den hoods und lokalen exit nodes zu ermöglichen müssen wir Routing Informationen zwischen den Teilnehmern austauschen. Als Protokoll welches sowohl mit v6 als auch mit v4 umgehen kann eignet sich Babel. Um sicher zustellen das das Layer 3 Routing nicht manipuliert wird, müssen wir ein Verifikationsmedium einsetzen bsp. ein Tunnel Protokoll z.b. gre, tinc, usw.. Eine volle Verschlüsselung ist dabei nicht notwendig. Evtl. bietet Babel selbst auch eine Möglichkeit der Verifikation, somit könnte man den overhead des Tunnels kompensieren.

[[Datei:L3Rounting_with_babel_v1.jpeg]]

[[Datei:L3Rounting_with_babel_v1.jpeg]]

In diesem Diagram wird Babel auch zwischen den Gateways im RZ gesprochen. Clients generell die Möglichkeit via Richtfunk strecke oder über die RZ Gateways zu komuniziren. Wenn wir jetzt z.B. die Komunikation auf die Richtfunkstrechen forcieren wollen könnte man die Babel Verbindung zwischen den RZ Gateways auch durch unsere aktuelle BGP oder OSPF lösung ersetzen. Somit müsste Theoretisch Babel die local bekante router über die Richfunk verbindung nehmen und erst wen Babel keine router findet und die default wählt kann der RZ gateway über BGP OSPF weiter an seine Anderen RZ Gateways vermitteln.

In diesem Diagramm wird Babel auch zwischen den Gateways im RZ gesprochen. Clients haben generell die Möglichkeit via Richtfunk strecke oder über die RZ Gateways zu kommunizieren. Wenn wir jetzt z.B. die Kommunikation auf die Richtfunkstrecken forcieren wollen könnte man die Babel Verbindung zwischen den RZ Gateways auch durch unsere aktuelle BGP oder OSPF Lösung ersetzen. Somit müsste Theoretisch Babel die Lokale bekannte Route über die Richtfunkverbindung nehmen und erst wenn Babel keine Route findet und die default wählt, kann der RZ Gateway über BGP OSPF weiter an seine Anderen RZ Gateways vermitteln.

== Quellen ==

== Quellen ==