IP-Adresskonzept

Ausgangssituation und Rahmenbedingungen

Der Verein Funkfeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/29. Aufgrund von “early registration” sind die Netze 2a02:60:0::/48, 2a02:60:1::/48 sowie 2a02:60:2::/48 vergeben und teilweise im operativen Einsatz. Mit einem Betrachtungsfokus der nächst höheren Verwaltungsebene (eines /40 Prefix), ist daher der gesamte Netzbereich 2a02:60::/40 als teilweise belegt zu berücksichtigen.

Anforderungsprofil an das 0xFF-Adressierungkonzept

1. IPv6 soll das präferierte Layer-3-Protokoll innerhalb des Netzes sein. IPv4 soll bis auf Weiteres mittels OLSRv1 weiter unterstützt werden.
2. Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
3. Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
4. Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
5. IPv6: Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.
6. IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
7. IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
8. IPv4: Im verwendeten IPv6 Adressraum sollen IPv4-Adressen in Übereinstimmung mit RFC4291 mittels eines “Mapping-Mechanismus” abgebildet bzw. “gemappt” werden können.

Umsetzung des IPv6-Adressierungskonzeptes

Die Vorgabe nach Standortorientierung (lt. RFC6177) legt nahe, die “Node-ID” des Redeemer als Teil der IPv6-Adresse heranzuziehen. Wir gehen davon aus, dass 65535 Standorte für den Verwaltungbereich von Funkfeuer Wien, das entspricht 16 Bit im Adressfeld, ausreichend sind. (Anm.: Die Node-ID mit der Nummer Null gilt als reserviert. Erklärung im Text unten.)

Der Empfehlung von RFC6177 nach vorausschauender Kapazitätsplanung wird nachgekommen, indem pro Standort bis zu 65535 lokale Netze realisierbar sind. Das ermöglicht eine flexible Segmentierung mit /64 Netzen pro Interface. Durch die jeweiligen Standortbetreiber sind diese Adressbits, entsprechend den individuellen Erfordernissen und Gegebenheiten, selbstständig zu vergeben.

Die Realisierung einer “modified EUI64” Adressierung gemäß RFC4291 Appendix A, erfordert die Bereitstellung von 64 Bit im Host-Teil der IPv6-Adresse.

Unter Berücksichtigung aller oben beschriebenen Fakten, ergibt sich ein erforderlicher Adressraum eines /32 Prefixes. Auf Grund bereits bestehender Teilbelegungen ist in der /32 Verwaltungsebene der nächstmögliche freie und zusammenhängende Adressraum: 2a02:61::/32.

Das ist in voller Schreibweise:

Allocation: 2a02:61::/32

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff

Dieser Bereich ist für das Mesh-Netz von 0xFF, Funkfeuer Wien, zu wählen.

IPv6-Bereich für Infrastruktur

Für Infrastruktur abseits der User Blocks wird der Bereich 2a02:61::/48 reserviert. Innerhalb von diesem Bereich finden sich die Loopback Adressen und auch die Tunnel Bereiche.

Allocation: 2a02:61::/48

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:ffff:ffff:ffff:ffff:ffff

IPv6-Adressen für Nodes

Link-lokale Adressen

Geräte generieren pro Device-Interface automatisch mindestens eine link-lokale Adresse aus dem Bereich fe80::/64. Diese werden für die OLSRv2-Kommunikation zwischen Devices verwendet. Da dieseselben Adressen (auf verschiedenen Links) mehrfach vorkommen können, identifiziert OLSRv2 Devices über andere, global gültige Adressen (siehen unten). OLSRv1 kann damit nicht umgehen.

Allocation & used: fe80::/64

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  fe80:0000:0000:0000:0000:0000:0000:0000
Letzte Adresse: fe80:0000:0000:0000:ffff:ffff:ffff:ffff

Loopback-Adressen

Devices generieren mindestens eine global gültige Adresse aus dem Bereich 2a02:61:0:ff::/64 per EUI64. Diese Adresse identifiziert das Interface eindeutig und wird auch von OLSRv2 als Identifier herangezogen. Aufgrund der Eindeutigkeit der EUI64 zugrunde liegenden MAC-Adressen ist sicher gestellt, dass keine Adresse mehrfach verwendet wird. Weiters ermöglicht dieses Vorgehen, ein Device ohne vorherige Adresszuweisung in Betrieb nehmen zu können.

Allocation & used: 2a02:61:0:ff::/64

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:00ff:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ff:ffff:ffff:ffff:ffff

User-Blocks

Hierbei handelt es sich um Adressbereiche, die pro Knoten zugewiesen werden können, um anschließend in Subnetzen "hinter" dem Knoten Verwendung zu finden. Dazu wird eine eindeutige Standortkennung in die Bits 33-48 der IPv6-Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des Redeemer abgeleitet. Somit resultiert für jeden registrierten Standort ein 48 Bit langes “Site-Prefix”. Die Node-ID mit der Nummer Null (0x0000) ist dabei für Infrastruktur reserviert (siehe unten) und wird nicht vergeben.

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0001:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff

IPv4-Adressen für Nodes

IPv4-Adressen werden auf Devices als native IPv4-Interfaces bereit gestellt. Für den Transport des IPv4-Traffics über das IPv6-Netz wird das 4in6-Verfahren angewandt, das im Linux-Kernel seit längerem zuverlässig implementiert ist und einen zustandslosen Tunnel zwischen dem Device und einem Tunnel-Server herstellt. Für das Mapping von IPv4-Adressen auf IPv6 wird der Bereich 2a02:61:0:ee::/64 verwendet. IPv4-Adressen werden dabei auf die letzten 32 Bit gemappt, wobei für eingehenden und ausgehenden Traffic unterschiedliche Subnetze verwendet werden, wodurch zwischen 0xFF und dem Rest des Internets unterschieden werden kann (Details siehen unten). Das Konzept ist im Detail unter Projekte/v642/IPv4_Support erklärt.

Es werden IPv4-Adressen aus dem Bereich 185.194.20.0/23 vergeben. Pro Knoten wird grundsätzlich eine (1) IPv4-Adresse vergeben. Es wird nicht automatisch eine IPv4-Adresse pro Knoten alloziert, sondern die IPv4-Adresse muss angefragt werden. Die Zuweisung soll automatisiert werden.

Allocation: 2a02:61:0:ee::/64

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:ffff:ffff:ffff:ffff

Outbound-Traffic (von Device zu Tunnel-Server)

Für das Mapping der IPv4 Adressen für Traffic vom FunkFeuer Netz ins Internet wird der Bereich 2a02:61:0:ee::/80 verwendet. Der gesamte Adressbereich wird durch die Tunnel-Server angekündigt, wodurch sämtlicher getunnelter IPv4-Traffic seinen Weg dorthin nimmt.

Used: 2a02:61:0:ee::/80

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:0000:ffff:ffff:ffff

Inbound-Traffic (von Tunnel-Server zu Device)

Für das Mapping der IPv4 Adressen für Traffic vom Internet ins FunkFeuer Netz wird der Bereich 2a02:61:0:ee:1::/80 verwendet. Adressen aus den 0xFF zugewiesenen IPv4-Adressblöcken werden dabei wie o.g. User-Blocks behandelt: Technisch werden diese durch den innehabenden Knoten über ihre Loopback-(IPv6)-Adresse angekündigt, organisatorisch werden diese zugeteilt.

Used: 2a02:61:0:ee:1::/80

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0061:0000:00ee:0001:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:0001:ffff:ffff:ffff