IP-Adresskonzept: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Zur Navigation springen Zur Suche springen
(Initiale Anlage der Seite mit Basis des IPv6-Konzepts (ohne Beispiele), um Aenderungen nachvollziehbar zu machen.)
 
(Vorschlag einer Anpassung des Konzepts auf Basis der Erkenntnisse aus dem v642-Projekt.)
Zeile 3: Zeile 3:
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.
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 ==
== Anforderungsprofil an das 0xFF-Adressierungkonzept ==
# Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.
# IPv6 soll das präferierte Layer-3-Protokoll innerhalb des Netzes sein. IPv4 soll bis auf Weiteres mittels Übergangsmachunismus unterstützt werden.
# Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
# Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
# Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
# Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
# Im verwendeten IPv6 Adressraum sollen die alten IPv4-Adressen mittels eines “Mapping Mechanismus” abgebildet bzw. “gemappt” werden können.
# IPv4-Adressen sollen im Host-Teil des IPv6 Adressraums gemappt sein.
# 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: 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 ==
== 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.)
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 256 lokale Netze realisierbar sind. Das ermöglicht z.B. 16 Router pro Standort mit 16 vollen /64 Netzen pro Router. Anmerkung: Für Router-IDs und lokale Netz-IDs stehen insgesamt 8 Bit zur Verfügung. Durch den jeweiligen Standortbetreiber, sind diese Adressbits, entsprechend den individuellen Erfordernissen und Gegebenheiten, selbstständig zu vergeben.
Der Empfehlung von RFC6177 nach vorausschauender Kapazitätsplanung wird nachgekommen, indem pro Standort bis zu 256 lokale Netze realisierbar sind. Das ermöglicht z.B. 16 Router pro Standort mit 16 vollen /64 Netzen pro Router. Anmerkung: Für Router-IDs und lokale Netz-IDs stehen insgesamt 8 Bit zur Verfügung. Durch den 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.
Die Realisierung einer “modified EUI64” Adressierung gemäß RFC4291 Appendix A, erfordert die Bereitstellung von 64 Bit im Host-Teil der IPv6-Adresse.


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


Das ist in voller Schreibweise:
Das ist in voller Schreibweise:


Allocation: 2a02:60:100::/40
  Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
  Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
  Erste Adresse:  2a02:0060:0100:0000:0000:0000:0000:0000
  Erste Adresse:  2a02:0060:0100:0000:0000:0000:0000:0000
  Letzte Adresse: 2a02:0060:01FF:FFFF:FFFF:FFFF:FFFF:FFFF
  Letzte Adresse: 2a02:0060: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.


== Adressgestaltung mittels Node-ID Adressierung ==
== IPv6-Adressen für Nodes ==
Zur weiteren Unterteilung des riesigen /40 Adressraums, wird eine eindeutige Standortkennung in die Bits 41-56 der IPv6 Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des Redeemer abgeleitet. Somit resultiert für jeden registrierten Standort ein 56 Bit langes “Site Prefix”.


Die jeweilige IPv6 Adresse wird gemäß des Schemas:
=== 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.


  16|  32|  48|  64|  80|  96| 112| 128|
Allocation & used: fe80::/64
  2a02:0060:01nn:nnri:xxxx:xxxx:xxxx:xxxx
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:60:100: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:60:100:ff::/64
Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
  Erste Adresse:  2a02:0060:0100:00ff:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:0100: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 41-56 der IPv6-Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des Redeemer abgeleitet. Somit resultiert für jeden registrierten Standort ein 56 Bit langes “Site-Prefix”. Die Node-ID mit der Nummer Null (0x0000) ist dabei für Infrastruktur reserviert (siehe unten) und wird nicht vergeben.
Die jeweilige IPv6-Adresse wird gemäß des Schemas:
Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Schema:        2a02:0060:01nn:nnri:xxxx:xxxx:xxxx:xxxx
Erste Adresse:  2a02:0060:0100:0100:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:01ff:ffff:ffff:ffff:ffff:ffff
oder kurz: 2a02:60:1''nn:nnri''::/56 berechnet.
oder kurz: 2a02:60:1''nn:nnri''::/56 berechnet.


Zeile 44: Zeile 62:


;nnnn
;nnnn
: steht für den hexadezimal dargestellten 16 Bit Wert der Noder-ID des Redeemer,
: steht für den hexadezimal dargestellten 16-Bit-Wert der Noder-ID im Redeemer,
;r
;r
: ist eine 4 Bit Router-ID in hexadezimaler Darstellung (0,1,2...F),
: ist eine 4-Bit-Router-ID in hexadezimaler Darstellung (0,1,2...F),
;i
;i
: ist eine 4 Bit Interface-ID des Routers in hexadezimaler Darstellung (0,1,2...F),
: ist eine 4-Bit-Interface-ID des Routers in hexadezimaler Darstellung (0,1,2...F),
;x
;x
: ist ein Bitmuster zur eindeutigen Identifizierung des Endgerätes.
: ist ein Bitmuster zur eindeutigen Identifizierung des Endgerätes.


Die Werte für ''r'', ''i'' und ''x'' sind durch den Knotenbetreiber nach eigenem Ermessen festzulegen.
Die Werte für ''r'', ''i'' und ''x'' sind durch Knotenbetreiber nach eigenem Ermessen festzulegen.
 
== 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:60:100: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.
 
Allocation: 2a02:60:100:ee::/64
Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0060:0100:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:0100:00ee:ffff:ffff:ffff:ffff


== Adressgestaltung mittels IPv4 Mapping ==
=== Inbound-Traffic (von Tunnel-Server zu Device) ===
Für das Mapping von IPv4-Adressen auf IPv6 wird der Bereich 2a02:60:100::/64 verwendet. Dies entspricht dem Prefix Bereich der reservierten Node-ID Null im Redeemer.
Für das Mapping der 0xFF-internen IPv4-Adressen wird der Bereich 2a02:60:100:ee::/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. Zusätzlich übernehmen Tunnel-Server am Rand (Edge) des Netzwerks (Uplink zum Internet) die ankegündigten Routen und konfigurieren ihre Tunnel-Interfaces entsprechend.


Die Einbettung einer IPv4 Adresse erfolgt in den unteren 64 Bit der IPv6 Adresse. Gemäß RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators sowie unter Beachtung von RFC 4291, IP
Used: 2a02:60:100:ee::/80
Version 6 Addressing Architecture, ergibt sich das Schema:
Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0060:0100:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:0100:00ee:0000:ffff:ffff:ffff


  16|  32|  48|  64|  80|  96| 112| 128|
=== Inbound-Traffic (von Tunnel-Server zu Device) ===
2a02:0060:0100:0000:00(d.d.d.d) nn:xxxx
Für das Mapping des restlichen IPv4-Internets (alles außerhalb der 0xFF-Bereiche) wird der Bereich 2a02:60:100:ee:1::/80 verwendet. Der gesamte Adressbereich wird durch die Tunnel-Server angekündigt, wodurch sämtlicher IPv4-Traffic für Ziele außerhalb des 0xFF-Netzes seinen Weg dorthin nimmt.


oder kurz: 2a02:60:100:0:0''(d:dd:d)nn''::/112
Used: 2a02:60:100:ee:1::/80
Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0060:0100:00ee:0001:0000:0000:0000
Letzte Adresse: 2a02:0060:0100:00ee:0001:ffff:ffff:ffff


Die Platzhalter:
== IPv6-Bereich für Infrastruktur ==
Für Infrastruktur abseits der Nodes wird der Bereich 2a02:60:100::/56 reserviert.


;d
Allocation: 2a02:60:100::/56
: stellen die 32 Bit lange IPv4 Adresse in hexadezimaler Darstellung dar.
Bitgrenze:       16|  32|  48|  64|  80|  96| 112| 128|
;nn
Erste Adresse:  2a02:0060:0100:0000:0000:0000:0000:0000
: bezeichnet einen optionalen 8 Bit langen Subnet Identifier (00 bis FF). Default: 00.
Letzte Adresse: 2a02:0060:0100:00ff:ffff:ffff:ffff:ffff

Version vom 15. Mai 2016, 19:08 Uhr

Ausgangssituation und Rahmenbedingungen

Der Verein Funkfeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/32. 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 Übergangsmachunismus 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 256 lokale Netze realisierbar sind. Das ermöglicht z.B. 16 Router pro Standort mit 16 vollen /64 Netzen pro Router. Anmerkung: Für Router-IDs und lokale Netz-IDs stehen insgesamt 8 Bit zur Verfügung. Durch den 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 /40 Prefixes. Auf Grund bereits bestehender Teilbelegungen ist in der /40 Verwaltungsebene der nächstmögliche freie und zusammenhängende Adressraum: 2a02:60:100::/40.

Das ist in voller Schreibweise:

Allocation: 2a02:60:100::/40

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

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

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:60:100: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:60:100:ff::/64

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Erste Adresse:  2a02:0060:0100:00ff:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:0100: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 41-56 der IPv6-Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des Redeemer abgeleitet. Somit resultiert für jeden registrierten Standort ein 56 Bit langes “Site-Prefix”. Die Node-ID mit der Nummer Null (0x0000) ist dabei für Infrastruktur reserviert (siehe unten) und wird nicht vergeben.

Die jeweilige IPv6-Adresse wird gemäß des Schemas:

Bitgrenze:        16|  32|  48|  64|  80|  96| 112| 128|
Schema:         2a02:0060:01nn:nnri:xxxx:xxxx:xxxx:xxxx
Erste Adresse:  2a02:0060:0100:0100:0000:0000:0000:0000
Letzte Adresse: 2a02:0060:01ff:ffff:ffff:ffff:ffff:ffff

oder kurz: 2a02:60:1nn:nnri::/56 berechnet.

Die Platzhalter:

nnnn
steht für den hexadezimal dargestellten 16-Bit-Wert der Noder-ID im Redeemer,
r
ist eine 4-Bit-Router-ID in hexadezimaler Darstellung (0,1,2...F),
i
ist eine 4-Bit-Interface-ID des Routers in hexadezimaler Darstellung (0,1,2...F),
x
ist ein Bitmuster zur eindeutigen Identifizierung des Endgerätes.

Die Werte für r, i und x sind durch Knotenbetreiber nach eigenem Ermessen festzulegen.

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:60:100: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.

Allocation: 2a02:60:100:ee::/64

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

Inbound-Traffic (von Tunnel-Server zu Device)

Für das Mapping der 0xFF-internen IPv4-Adressen wird der Bereich 2a02:60:100:ee::/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. Zusätzlich übernehmen Tunnel-Server am Rand (Edge) des Netzwerks (Uplink zum Internet) die ankegündigten Routen und konfigurieren ihre Tunnel-Interfaces entsprechend.

Used: 2a02:60:100:ee::/80

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

Inbound-Traffic (von Tunnel-Server zu Device)

Für das Mapping des restlichen IPv4-Internets (alles außerhalb der 0xFF-Bereiche) wird der Bereich 2a02:60:100:ee:1::/80 verwendet. Der gesamte Adressbereich wird durch die Tunnel-Server angekündigt, wodurch sämtlicher IPv4-Traffic für Ziele außerhalb des 0xFF-Netzes seinen Weg dorthin nimmt.

Used: 2a02:60:100:ee:1::/80

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

IPv6-Bereich für Infrastruktur

Für Infrastruktur abseits der Nodes wird der Bereich 2a02:60:100::/56 reserviert.

Allocation: 2a02:60:100::/56

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