Benutzer:Zem/IP-Adresskonzept

Revised Version Work in Progress

Überblick der FunkFeuer-IPv6-Adressbereiche

                         Präfix-
                          länge   16|  32|  48|  64|  80|  96| 112| 128|
FunkFeuer IPv6 (0<=x<=7)    29  2a02:006x:....:....:....:....:....:....
|
+- Early Registration       40  2a02:0060:00..:....:....:....:....:....
|
+- User Blocks              32  2a02:0061:....:....:....:....:....:....
   |
   +- Infrastruktur         48  2a02:0061:0000:....:....:....:....:....
   |  |
   |  +- 4in6, Egress       80  2a02:0061:0000:00ee:0000:....:....:....
   |  +- 4in6, Ingress      80  2a02:0061:0000:00ee:0001:....:....:....
   |  +- Loopback           64  2a02:0061:0000:00ff:....:....:....:....
   |
   +- Per-Node (nnnn!=0)    48  2a02:0061:nnnn:....:....:....:....:....

Ausgangssituation und Rahmenbedingungen

Der Verein FunkFeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/29. Aufgrund von “early registration”, also Versuchen mit IPv6 nach der Zuteilung an FunkFeuer, sind die Netze 2a02:60:0::/48, 2a02:60:1::/48 sowie 2a02:60:2::/48 vergeben und teilweise (noch 2 nodes mit OLSRv1, läuft aus) 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.
2. IPv4 soll zumindest während dem Übergang mittels OLSRv1 weiter unterstützt werden.
3. Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
4. Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
5. Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
6. IPv6: Die Vergabe von IPv6-Adressen soll RFC6177 konform sein.
7. IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
8. IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
9. 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. Oder anders gesagt, jeder Standort (Node) bekommt einen /48er ipv6 Adressbereich vergeben der zum beispiel in 65535 weitere /64 netze aufgeteilt werden kann.

Zusaetzlich kann ein node 1 oder mehrere weitere IPv6 Einzeladdressen vergeben, die in Form einer "modified EUI64" Addressierung vergeben werden. Die Realisierung einer solchen “modified EUI64” Adressierung gemäß RFC4291 Appendix A, erfordert die Bereitstellung von 64 Bit im Host-Teil der IPv6-Adresse. Solche einzeladdressen sind zum Beispiel nuetzlich um einem Node eine Globale IP geben zu koennen ohne hier auf teile des /48 node blocks zugreifen zu muessen.

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

(Default bei IPv6)

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. Sie haben einen lokalen scope, Adressen sind nur auf OSI Layer 2 gültig, werden somit nicht geroutet. Link Local addresse koennen aber als Router/Gateway Adressen eingesetzt werden, somit braucht ein node mit mehreren links nicht fuer jeden link eine IP zu vergeben sondern kann die Link Lokal addressen verwenden um IP Packete von und zu Globalen addressen zu routen.

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

Device-Adressen

Damit ein Device im Netz erreicht werden kann, zum Beispiel fuer Smokeping oder Fernwartung, oder zu Diagnosezwecken, muss es mindestens eine Globale IP Adresse zugewiesen bekommen.

Eine solche Addresse kann entweder aus dem /48 User-Block genommen werden (siehe naechster Abschnitt) oder sie wird aus dem Bereich 2a02:61:0:ff::/64 per EUI64 generiert. 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, theoretisch, ein Device ohne vorherige Adresszuweisung in Betrieb nehmen zu können, praktisch ist die Device Adresse im Redeemer zu hinterlegen damit eine Zuordnung zur NodeID und dem Device gemacht werden kann.

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

Die Device Addresse sollte als /128 auf dem node auf einem separaten Interface angelegt werden. Hierfuer eignet sich auf Linux ein bridge interface und auf OpenBSD ein vether interface am besten. Wichtig ist, da es sich hier aus Sicht des Devices um Einzeladressen handelt, das diese auf dem jeweiligen node als /128 netz angelegt werden, und OLSRD2 das Routing ueberlassen wird.

Node/User-Blocks

Hierbei handelt es sich um Adressbereiche, die pro Node zugewiesen werden können, um anschließend in Subnetzen "hinter" dem Node (z.B. als Client IPs) 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

Zum Beispiel: 2a02:61:abcd::1/48 - 2a02:61:abcd:ffff:ffff:ffff:ffff:ffff/48 fuer die Node ID 43981

IPv4-Adressen für Nodes

Wichtig: Diese Adressierung ist nur für reine IPv6-Knoten relevant. Knoten die weiterhin über Dual Stack angebunden sind benötigen diese idR nicht.

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