IP-Adresskonzept: Unterschied zwischen den Versionen
PK (Diskussion | Beiträge) K (Funkfeuer -> FunkFeuer, etc) |
|||
| (2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 18: | Zeile 18: | ||
== Ausgangssituation und Rahmenbedingungen == | == Ausgangssituation und Rahmenbedingungen == | ||
Der Verein | 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. | 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. | ||
| Zeile 27: | Zeile 27: | ||
# Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden. | # 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. | # 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: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden. | ||
# IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein. | # 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 == | == Umsetzung des IPv6-Adressierungskonzeptes == | ||
| Zeile 48: | Zeile 48: | ||
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff | Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff | ||
Dieser Bereich ist für das Mesh-Netz von 0xFF, | Dieser Bereich ist für das Mesh-Netz von 0xFF, FunkFeuer Wien, zu wählen. | ||
== IPv6-Bereich für Infrastruktur == | == IPv6-Bereich für Infrastruktur == | ||
| Zeile 81: | Zeile 81: | ||
=== User-Blocks === | === 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| | Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128| | ||
| Zeile 88: | Zeile 88: | ||
== IPv4-Adressen für Nodes == | == 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. | 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 100: | Zeile 100: | ||
=== Outbound-Traffic (von Device zu Tunnel-Server) === | === 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 | Used: 2a02:61:0:ee::/80 | ||
| Zeile 108: | Zeile 108: | ||
=== Inbound-Traffic (von Tunnel-Server zu Device) === | === 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 | Used: 2a02:61:0:ee:1::/80 | ||
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