IP-Adresskonzept: Unterschied zwischen den Versionen

Aktuelle Version vom 29. Mai 2020, 02:32 Uhr

Ü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

IPv6 soll das präferierte Layer-3-Protokoll innerhalb des Netzes sein.
IPv4 soll zumindest während dem Übergang mittels OLSRv1 weiter unterstützt werden.
Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
IPv6: Die Vergabe von IPv6-Adressen soll RFC6177 konform sein.
IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
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. Sie haben einen lokalen scope, Adressen sind nur auf OSI Layer 2 gültig, werden somit nicht geroutet. 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 [Anm: Bitte klarstellen, warum nicht?]

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

Dies ist etwa auf der Hälfte der Knoten in Verwendung. Damit ist keine Zuordnung zur Nodeid direkt möglich, deswegen werden User-Blocks verwendet.

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

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

@@ Zeile 18: / Zeile 18: @@
 == 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
+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
-a02: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.
+a02: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 ==
@@ Zeile 27: / Zeile 27: @@
 # Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
 # Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
-# IPv6: Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.
+# IPv6: Die Vergabe von IPv6-Adressen soll RFC6177 konform sein.
 # IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
 # IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
-# IPv4: Im verwendeten IPv6 Adressraum sollen IPv4-Adressen in Übereinstimmung mit RFC4291 mittels eines “Mapping-Mechanismus” abgebildet bzw. “gemappt” werden können.
+# 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 ==
@@ Zeile 48: / Zeile 48: @@
   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.
+Dieser Bereich ist für das Mesh-Netz von 0xFF, FunkFeuer Wien, zu wählen.
 == IPv6-Bereich für Infrastruktur ==
@@ Zeile 61: / Zeile 61: @@
 === 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.
+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.
+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 [Anm: Bitte klarstellen, warum nicht?]
 Allocation & used: fe80::/64
@@ Zeile 75: / Zeile 77: @@
   Erste Adresse:  2a02:0061:0000:00ff:0000:0000:0000:0000
   Letzte Adresse: 2a02:0061:0000:00ff:ffff:ffff:ffff:ffff
+Dies ist etwa auf der Hälfte der Knoten in Verwendung. Damit ist keine Zuordnung zur Nodeid direkt möglich, deswegen werden User-Blocks verwendet.
 === 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.
+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 [https://portal.funkfeuer.at/wien/ 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|
@@ Zeile 84: / Zeile 88: @@
 == 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.
+'''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.
@@ Zeile 96: / Zeile 100: @@
 === 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.
+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
@@ Zeile 104: / Zeile 108: @@
 === 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.
+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