Diplomarbeit · GSM-Netze werden hier als Teil des PSTN betrachtet. UMTS ist in den neueren...

Fachhochschule Köln

University of Applied Sciences Cologne

07 Fakultät für Informations-, Medien- und

Elektrotechnik, Studiengang Elektrotechnik/NT

Institut für Nachrichtentechnik

Labor für Datennetze

Diplomarbeit

Thema: Adressierungs- und Migrationskonzepte für Voice

over IP (VoIP) zur Unterstützung des GeoVIPA-Konzeptes in IPv4- und IPv6-Netzen.

Student : Achim Marikar

Matr. Nr. : 11027686Referent : Prof. Dr. Andreas Grebe

Koreferent : Prof. Dr. Heiko Knospe

Abgabedatum : 15. März 2005

Hiermit versichere ich, dass ich die Diplomarbeit selbständig angefertigt und keine anderen

als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt

habe.

_____________________

Achim Marikar

Inhaltsverzeichnis 2

Inhaltsverzeichnis

Darstellungsverzeichnis 4Einleitung 6

1. Das GeoVIPA-Konzept 7

1.1. Ziele 71.2. Umsetzung 8

2. Grundlagen VoIP 12

2.1. Allgemeines 122.2. Voraussetzungen für VoIP 122.3. Protokolle 132.4. SIP 132.4.1. Server und Clients 132.4.2. Methoden und Abläufe 15

3. Grundlagen IPv6 18

3.1. Neuerungen in IPv6 183.2. Der IPv6-Header 193.3. IPv6-Adressierung 203.3.1. Unicast-Adressierung 223.3.2. Site-Local- und Link-Local-Adressen 233.3.3. Multicast-Adressen 233.3.4. Darstellung von IPv6-Adressen 233.3.5. Autokonfiguration 243.4. Quality of Services 263.5. Mobile-IPv6 273.6. Migration von IPv6 und IPv4 283.6.1. Tunnel 283.6.2. Migrationsmechanismen 31

Inhaltsverzeichnis 3

4. Unicast-Adressen mit eingebettetem Local Area Code 32

4.1. Allgemeines 324.2. Der Local Area Code 334.3. Adressierungskonzepte 334.4. Auswahl 364.5. Draft für die IETF 38

5. Aufbau eines IPv6-Subnetzes für VoIP-Verbindungstests 46

5.1. Aufbau 465.2. Betriebssysteme 475.3. Installation und Konfiguration der Dienste 475.4. Entwicklungsstand 50

6. VoIP und IPv6 51

6.1. VoIP-Soft- und -Hardware 516.2. Leistungsfähigkeit der Migrationstechniken 51

7. Einbringen der Erkenntnisse in das GeoVIPA-Konzept 56

7.1. Ziele 567.2. Verfahren 567.2.1. Anwendungsbeispiele 597.2.2. Erweiterte Funktionen 617.3. Umsetzung 627.3.1. Beispiele zur Anwendung des IP-DNA 647.3.2. Software 68

Schlussbetrachtung 70

Anhang 71Abkürzungen 93Quellen 94

Darstellungsverzeichnis 4

Darstellungsverzeichnis

AbbildungenAbbildung 1: Einfügen von VoIP in das PSTN 7Abbildung 2: VoIP mit IP-DNA 9Abbildung 3: IPv6-Gateway 10Abbildung 4: SIP-Proxy 10Abbildung 5: IPv6-Anbindung 10Abbildung 6: Lokalisierung über den DSLAM 11Abbildung 7: Peer to Peer 14Abbildung 8: Nutzung eines SIP-Proxys 14Abbildung 9: Minimale Kommunikation für einen Verbindungsaufbau und -abbau 16Abbildung 10: Verbindung mit Hilfe eines SIP-Servers 16Abbildung 11: Vermittlung über mehrere SIP-Server 17Abbildung 12: Nutzung eines SIP-Proxys 17Abbildung 13: Der IPv6-Header 19Abbildung 14: IPv6-Header mit zwei Erweiterungen 19Abbildung 15: Adresstypen 20Abbildung 16: Unicast-Adressierung nach RFC 2374 22Abbildung 17: Unicast-Adressierung nach RFC 3587 und 3177 22Abbildung 18: Generierung der Interface-ID 24Abbildung 19: Traffic Class 26Abbildung 20: Mobile-IPv6 28Abbildung 21: IPSec im Tunnelmodus mit ESP 29Abbildung 22: OpenVPN 30Abbildung 23: Simple Internet Transition 30Abbildung 24: Metro-Based Addressing 32Abbildung 25: Providerunabhängiges Adressformat 33Abbildung 26: Konzept A 34Abbildung 27: Konzept B 34Abbildung 28: Kürzen der Interface-ID 35Abbildung 29: Konzept C 35Abbildung 30: Das derzeitige Adressformat 36Abbildung 31: Das neue Adressformat mit integriertem LAC 36Abbildung 32: Der LAC 37

Darstellungsverzeichnis 5

Abbildung 33: Tunnel im IPv6-Netz 49Abbildung 34: IPv6-Netz im Experimentiernetz 49Abbildung 35: Verbindung zwischen den Clients 52Abbildung 36: Leistungsbedarf von OpenVPN bei einem Filetransfer mit 670 kbyte/s 53Abbildung 37: Leistungsbedarf des RTP-Proxys im ausgelasteten System 55Abbildung 38: Verwendung von SIP-Proxys 56Abbildung 39: Lokalisierung über den DSLAM 57Abbildung 40: Lokalisierung für einen Notruf 59Abbildung 41: Lokalisierung für die entfernungsabhängige Abrechnung 60Abbildung 42: Hierarchiestufen des IP-DNA 62Abbildung 43: Anwendungsbeispiel mit IP-DNAs 64Abbildung 44: Kommunikation im Fall 1 65Abbildung 45: Kommunikation im Fall 2 67

TabellenTabelle 1: Die wichtigsten Requests 15Tabelle 2: Die wichtigsten Responses 15Tabelle 3: IPv6-Präfixe 21Tabelle 4: Einige Multicast-Adressen 23Tabelle 5: Einige Werte der Service Class 27Tabelle 6: Bedarf der einzelnen Länder an Bits für die Ortscodes 37Tabelle 7: Einteilung der Größenklassen 38Tabelle 8: Laufzeit von ICMP-Paketen 52Tabelle 9: Jitter des RTP-Proxy 53Tabelle 10: Auslastung des Systems 54

Einleitung 6

Einleitung

Heutzutage hat nahezu jeder Mensch in Deutschland die Möglichkeit, das Internet zu nutzen.

Durch fallende Preise für Breitbandanschlüsse ist es verlockend, den Internetanschluss zum

Telefonieren zu nutzen. VoIP (Voice over IP) ist in den letzten Jahren zu einer brauchbaren

Alternative zu der gängigen Festnetz-Telefonie weiterentwickelt worden und hat mittlerweile

das Potential, den Festnetzanschluss zu ersetzen. Zusammen mit der neuen Version des

Internetprotokolls (IPv6) ist es absehbar, dass die Internettelefonie in Zukunft das PSTN

(Public Switched Telephone Network) ablösen wird.

Zusammen mit der Firma Tecon wird im Rahmen dieser Diplomarbeit versucht, einige

wichtige Zusatzfunktionen für VoIP bereitzustellen. Als Grundlage dieser Diplomarbeit dient

das GeoVIPA-Konzept von Lars Weyerstraß der Firma WeyTeCon und Horst Fröhlich von

der Firma Tecon. In dieser Arbeit wird auf einen Teil der Grundlagen des Konzeptes

eingegangen. Da während der Diplomarbeit die Anforderungen mehrmals angepasst werden

mussten, besteht sie neben den Grundlagen aus drei teilweise unabhängigen Teilen:

- Entwicklung eines IPv6-Adressierungskonzeptes zur Lokalisierung der VoIP-

Teilnehmer.

- Aufbau eines IPv6-Netzes im Experimentiernetz und die Implementierung

verschiedener Übergänge von IPv4 nach IPv6 für VoIP.

- Einfügen der gewonnenen Erkenntnisse in das GeoVIPA-Konzept

Weiterführende Informationen zu GeoVIPA findet man unter [GEOVIPA]. Bei IPv6 und

VoIP werden ebenfalls nur die Teile erklärt, die für die Diplomarbeit von Bedeutung sind. Auf

Details, wie die Optionen der IPv6-Erweiterungsheader oder die zahlreichen Sonder-

funktionen bei SIP, wird in dieser Arbeit nicht eingegangen. Hier kann man auf ausführlichere

Fachliteratur zurückgreifen. Einige Informationen zu Büchern und Webseiten finden sich im

Quellennachweis am Ende dieses Dokuments.

Bei den Lesern werden umfangreiche Kenntnisse von IPv4 sowie grundlegende Kenntnisse

des PSTN und von DSL-Verbindungen vorausgesetzt.


1. Das GeoVIPA-Konzept

1.1. Ziele

GeoVIPA wird derzeit von den Firmen WeyTeCon und Tecon entwickelt. Es ist ein Verfahren

für die

„geografische Zuordnung von VoIP Verkehr zur Authentifizierung und

Abrechnung“.

Die Hauptziele von GeoVIPA sind:

- Bestimmung der Ursprünge eines Telefonats, besonders bei Not- und Röchelrufen.

- Ermöglichen von Bedarfsträgeranfragen (Abhören des Telefonats).

- Abrechnung nach Entfernung und Übertragungsvolumen.

- Abrechnung von Mehrwertdiensten.

- Abrechnung mit den bisher eingesetzten Billingsystemen.

Abbildung 1: Einfügen von VoIP in das PSTN


VoIP soll sich mit Hilfe von GeoVIPA nahtlos in das bestehende PSTN einfügen können.Nationale und internationale Telefonieanbieter sollen VoIP-Anbieter mit mindestens der

gleichen Funktionalität anbinden können wie herkömmliche Telefonnetzbetreiber.

Mehrwertdienste sind vom Nutzer abhängig, Notrufe von dem physikalischen Anschluss. Eine

Bedarfsträgeranfrage muss ebenfalls bei nomadischer Nutzung möglich sein. Eine nomadische

Nutzung entspricht der Verwendung eines VoIP-Telefons, das in einem fremden Netz

angeschlossen ist, beispielsweise in einem öffentlichen WLAN oder im Hotel.

Eine Übersicht der nötigen Übergänge zeigt Abbildung1 1. GSM-Netze werden hier als Teil

des PSTN betrachtet. UMTS ist in den neueren Versionen (Release 4 und 5)2 als IP-Telefonie

anzusehen und gilt bei GeoVIPA als VoIP-Anbindung.

1.2. Umsetzung

In der ursprünglichen Fassung geht GeoVIPA davon aus, dass die geographische Zuordnung

der Teilnehmer nur durch die IPv6-Adresse geschieht, welche eine Ortsinformation enthalten

soll. Durch die Zuordnung einer oder mehrerer fester Charging-IPs (CHIP) zu jeder Ruf-

nummer soll der Nutzer identifiziert werden.

Da es sehr wahrscheinlich noch einige Zeit dauern wird, bis IPv6 flächendeckend eingesetzt

wird, geht GeoVIPA in der aktuellen Version davon aus, dass vorerst lediglich die

Providerseite mit IPv6 ausgerüstet ist. Die Endkunden sollen noch IPv4 nutzen können. Das

VoIP-Telefon im IPv4-Netz bekommt vom Provider eine IPv6-Adresse zugeordnet, die als

CHIP geführt wird. Diese Adresse ist der Rufnummer fest zugeordnet und ist für die

Lokalisierung nicht von Bedeutung. Der Anschluss soll eine PLIP (Physical Line IP) erhalten,

welche die notwendigen Lokalisierungsinformationen enthält. Die verwendeten IPv6-

Adressen sollen einen Local Area Code (LAC) enthalten, die den Bezirk des Anschlusses

angeben. Die Vergabe des LAC lehnt sich an die Verteilung der Ortsvorwahlen im

Telefonnetz an. Durch diesen LAC kann ein Anrufer einer Notrufzentrale zugeordnet werden.

Entfernungsabhängige Abrechnungen sind mit Hilfe des LAC ebenfalls realisierbar.

1 entnommen aus: [GEOVIPA]

2 [RUSILA]


Die technische Umsetzung des Konzeptes soll mit Hilfe des IP-DNA (Abbildung 2)1

geschehen, der je nach Ausbaustufe einen SIP-Server und einen SIP-Proxy vereint und

Schnittstellen für Abrechnungsdienste und Lokalisierungsanfragen bietet, wobei die Aufgaben

des IP-DNAs auch auf mehrere Geräte verteilt werden können. Des Weiteren soll der IP-DNA

in Zukunft den herkömmlichen AAA (Authentication, Authorization, Accounting) ersetzen

können. Um Bedarfsträgeranfragen und Verwaltungsaufgaben zu bearbeiten, ist ein

übergeordneter ROOT-IP-DNA auf nationaler Ebene vorgesehen.

1 entnommen aus: [GEOVIPA]

Abbildung 2: VoIP mit IP-DNA


Bei der Unterstützung von IPv6 auf der Seite der Provider ergeben sich 3 Anwendungs-

möglichkeiten:

- Nutzung von IPv6 im Backbone und IPv4 beim Endkunden, Übergang mit Hilfe

von IPv6-Tunneln (Abbildung 3). Das Telefon im IPv4-Netz baut über einen IPv6-

Tunnel eine Verbindung in das IPv6-Netz auf. Hierzu wird ein Tunnelgateway

benötigt.

- Nutzung von IPv6 im Backbone und IPv4 beim Endkunden, Übergang mit Hilfe

von Protokollumsetzern (Abbildung 4). Das Telefon nutzt lediglich IPv4. Die Sprach-

pakete werden vom SIP-Proxy in das IPv6-Netzt geleitet.

- Nutzung von IPv6 im Backbone und beim Endkunden (Abbildung 5).

Abbildung 4: SIP-Proxy

Abbildung 5: IPv6-Anbindung

Abbildung 3: IPv6-Gateway


Um Röchelrufe lokalisieren zu können, wird die Unterstützung des Providers vorausgesetzt.

Da der Provider in der Regel bei DSL-Anschlüssen die Ports des DSL-Access-Multiplexers

(DSLAM) fest vergibt, kann über die Zuordnung der IP-Adressen zu den Ports eine eindeutige

Bestimmung des Teilnehmers erfolgen (Abbildung 6). Andere Zugangstechniken erfordern

ähnliche Mechanismen, GeoVIPA geht hier jedoch nur von DSL-Anschlüssen aus.

Abbildung 6: Lokalisierung über den DSLAM

2. VoIP - Grundlagen 12

2. VoIP - Grundlagen

2.1. Allgemeines

VoIP ist eine Internetanwendung, die momentan eine immer größere Verbreitung findet. Der

Internettelefonie wird ein sehr großes Wachstum vorausgesagt. Lange wurde VoIP als zu

kompliziert, instabil und nicht konkurrenzfähig bezeichnet. Mittlerweile haben sich die

Codecs verbessert, die Geschwindigkeit der Internetanschlüsse vervielfacht und die

Installation von VoIP-Telefonen vereinfacht. Derzeit gibt es nur noch wenige Nachteile

gegenüber der konventionellen Festnetztelefonie.

2.2. Voraussetzungen für VoIP

Um ein Telefongespräch ohne Beeinträchtigung über das Internet führen zu können, müssen

einige Rahmenbedingungen gegeben sein. Es muss genügend Übertragungskapazität für den

Datenstrom vorhanden sein, die Verzögerung darf ein gewisses Maß nicht überschreiten und

die Ausfallsicherheit sollte so hoch wie möglich sein. Heutzutage gibt es mit DSL und

anderen Breitbandanschlüssen Übertragungsraten, die für VoIP vollkommen ausreichend sind.

Die verbesserten Codecs helfen, das benötigte Übertragungsvolumen nochmals zu verringern,

ohne die Sprachqualität zu sehr zu beeinträchtigen. Je nach verwendeter Qualität werden 8-64

kBit/s pro Richtung für die Nutzdaten benötigt. Ein Problem bei VoIP ist der Jitter der

Internetverbindung. Bei einem hohen Jitter muss im Telefon des Empfängers ein großer

Puffer eingesetzt werden, um Aussetzer bei der Sprachwiedergabe zu minimieren. Die

dadurch entstehende Verzögerung addiert sich zu der Verzögerung, die durch die Laufzeit in

den Leitungen sowie durch die Verarbeitungsdauer in den Routern, Proxys und Telefonen

entsteht. Bei einer zu hohen Verzögerung müssen die Gesprächsteilnehmer ungewöhnlich

lange auf eine Reaktion warten, oder sie fallen sich gegenseitig ins Wort, wodurch der Nutzen

des Telefonats sinkt. Um den Jitter gering zu halten, benötigt man eine garantierte Bandbreite

oder mindestens ein ausgefeiltes Prioritätenmanagement, wie beides von ATM bekannt ist. An

dieser Stelle ist IPv6 der Hoffnungsträger, um VoIP nicht nur durch eine bloße Überkapazität

der Verbindungen zu ermöglichen. Bei den heutigen sehr stabilen Verbindungen spielt der

Paketverlust meist eine untergeordnete Rolle, zumal ein einzelnes fehlendes Paket die

Sprachqualität nur sehr gering beeinflusst.


2.3. Protokolle

In der Internettelefonie haben sich zwei Standards durchgesetzt, H.323 und das Session

Initiation Protocol (SIP). H.323 hat seinen Ursprung im PSTN, wobei SIP aus der Internetwelt

kommt. Beide Protokolle nutzen für die Sprachdatenübertragung das Real Time Protocol

(RTP), welches wiederum auf TCP oder UDP aufsetzt. Neu hinzugekommen ist IAX, das

Protokoll der Open Source Telefonanlage Asterisk1, das ursprünglich dazu gedacht war,

mehrere Telefonanlagen zu einer logischen Einheit zu verbinden. Mittlerweile unterstützen

erste Hardwaretelefone das IAX-Protokoll. Andere, teils proprietäre, Protokolle werden meist

nur innerhalb eines Firmennetzes verwendet und durch geeignete Telefonanlagen mit dem

Festnetz verbunden. Da H.323 von SIP immer mehr in den Hintergrund gedrängt wird und

IAX noch nicht weit verbreitet ist, wird in dieser Diplomarbeit lediglich auf das SIP-Protokoll

eingegangen.

2.4. SIP

Das Session Initiation Protocol wurde 1999 von der IETF-Workgroup MMUSIC2 als

Konkurrenz zu H.323 entwickelt. Die SIP-Architektur ähnelt elektronischen Tauschbörsen

und basiert im Normalfall auf Peer-to-Peer-Netzen, welche durch Server verwaltet werden.

2.4.1. Server und Clients

Bei SIP gibt es die sogenannten User-Agent-Clients (UAC) und die User-Agent-Server

(UAS). Ein UAC ist bei SIP wie ein herkömmliches Telefon zu verstehen. Es kann Telefonate

annehmen und neue Verbindungen initiieren. Bei den UASs gibt es mehrere verschiedene

Arten von Servern3:

1 [ASTERISK]

2 [RFC2543]

3 [VOVIDA] Seite 14


RegistrarserverDer Regitrarserver dient der Authentifizierung der User. In der Regel ist die

Registrarfunktionalität im Redirectserver integriert.

LocationserverDer Locationserver speichert die Kontaktadressen (IP-Adressen) der User. Durch den

Locationserver kann ein registrierter User ausfindig gemacht werden. Dieser Server ist in der

Regel in Redirect- oder Proxyservern integriert.

Redirectserver

Ein Redirectserver vermittelt zwischen den Clients. Er ist unter anderem für den

Verbindungsauf- und -abbau zwischen den Clients zuständig (Abbildung 7). Da der

Redirectserver SIP-Nachrichten weiterleiten kann, wird er oft auch als Proxy bezeichnet.

ProxyserverEin Proxyserver kommt zum Einsatz, wenn eine direkte Verbindung zwischen zwei Clients

nicht möglich oder nicht gewünscht ist. Der Server emuliert jeweils zwei Clients und

verbindet so ein Gespräch (Abbildung 8). Die Proxyfunktion bezieht sich beim Proxyserver

hauptsächlich auf RTP.

Abbildung 7: Peer to Peer

Abbildung 8: Nutzung eines SIP-Proxys


Da Registrar- oder Locationserver in der Regel zusammen mit einem Redirectserver

implementiert werden, wird in dieser Arbeit nur zwischen einem SIP-Server

(Registrar/Location/Redirect) und einem SIP-Proxy unterschieden.

2.4.2. Methoden und Abläufe

SIP setzt wie RTP auf UDP oder TCP auf, wobei die Verwendung von UDP empfohlen wird.

Um die Implementation des Protokolls möglichst einfach zu gestalten, werden die einzelnen

Anweisungen im ASCII-Format übertragen. SIP ähnelt dadurch HTTP (Hypertext Transfer

Protocol) und verwendet mehrere Methoden, um miteinander zu kommunizieren.

Zur Verbindungssteuerung werden Requests (Anfragen) gesendet (Tabelle 1).

REGISTER Mit REGISTER meldet sich der Teilnehmer beim SIP-Server an und teilt ihm seine Kontaktadresse mit.

INVITE Die Anfrage INVITE lädt einen Teilnehmer zu einemGespräch ein.

ACK Mit ACK wird der Verbindungsaufbau vom Anruferbestätigt.

BYE BYE teilt mit, dass ein Gespräch beendet werden soll.Tabelle 1: Die wichtigsten Requests

Auf die Anfragen wird mit einem Response (Antwort) geantwortet (Tabelle 2).

100 Trying Es wird versucht, die Anfrage auszuführen.180 Ringing Der Anruf wird beim Empfänger signalisiert.200 OK Die Anfrage wurde erfolgreich ausgeführt.400 Bad Request Die Anfrage war fehlerhaft.Tabelle 2: Die wichtigsten Responses

Zusätzliche Informationen werden mit dem Session Description Protocol (SDP) angegeben,

das in die SIP-Nachricht eingebettet wird. SDP enthält Informationen über verwendete

Codecs, Kontaktadressen und andere Daten der Verbindung. Ein Beispiel zu einer SIP-

Nachricht mit SDP findet sich im Anhang auf Seite 71.


Minimale KommunikationBei Kenntnis der Kontaktadresse des Empfängers ist eine direkte Kommunikation der Clients

ohne Server zum Aufbau der Verbindung möglich (Abbildung 9). Über INVITE wird der

Empfänger eingeladen. Der Empfänger bestätigt die Signalisierung mit Ringing. Das Abheben

des Empfängers wird mit der Meldung OK signalisiert und mit ACK der Gegenseite bestätigt.

Während des Gespräches findet die Kommunikation über RTP statt. Zur Beendigung des

Gesprächs wird die Nachricht BYE gesendet und mit OK bestätigt.

Abbildung 9: Minimale Kommunikation für einen Verbindungsaufbau und -abbau

Abbildung 10: Verbindung mit Hilfe eines SIP-Servers


Kommunikation mit Hilfe eines SIP-ServersIm Normalfall erfolgt der Verbindungsaufbau mit Hilfe eines SIP-Servers (Abbildung 10).

Der Server kennt den Aufenthaltsort der Teilnehmer und leitet Anfragen an die dazugehörigen

Empfänger weiter. Die RTP-Kommunikation im Anschluss läuft in der Regel direkt zwischen

den Teilnehmern ab. Der Wunsch zur Beendigung des Gesprächs kann wahlweise über den

SIP-Server oder direkt an den Empfänger geäußert werden.

Weitere Kommunikationsmöglichkeiten

Wenn der Empfänger nicht bei dem gleichen SIP-Server registriert ist wie der Anrufer,

werden die Anfragen an den zuständigen Server weitergeleitet (Abbildung 11). Wenn ein SIP-

Proxy genutzt werden soll, bekommen die Clients den SIP-Proxy als Kommunikationspartner

zugewiesen. Die RTP-Kommunikation läuft dann über den Proxy (Abbildung 12).

SIP zeichnet sich vor allem durch seine Flexibilität aus, so sind viele weitere Szenarien

möglich.

Abbildung 11: Vermittlung über mehrere SIP-Server

Abbildung 12: Nutzung eines SIP-Proxys

3. IPv6 - Grundlagen 18

3. IPv6 - Grundlagen

3.1. Neuerungen in IPv6

Wenn man heute jemanden fragt, was der größte Unterschied zwischen IPv6 und IPv4 ist,

dann bekommt man meist den um 96 Bit auf 128 Bit erweiterten Adressraum genannt. IPv6

bietet aber noch wesentlich mehr Vorteile gegenüber IPv4. Da IPv4 das erste großflächig

eingesetzte Internetprotokoll ist, konnte man bei IPv6 alles das einbringen und verändern, was

bei der Entwicklung von IPv4 noch nicht abzusehen war.

Die neue Version des Internetprotokolls hat einen neuen Header mit konstanter Größe,

welcher durch Erweiterungsheader zusätzliche Optionen erhalten kann. Durch das flexible

Design unterstützt IPv6 IPSec, feste Routen und viele weitere Optionen ohne Platz im Header

zu verschwenden. Ein einfacher IPv6 Header ist trotz 128 Bit (16 Byte) langen Adressen

lediglich 40 Byte groß. Durch die verbesserte hierarchische Struktur der Adressen werden die

Routingtabellen minimiert und das Routing optimiert. Bei IPv6 werden die Pakete über das

Flow Label und die Traffic Class gekennzeichnet und priorisiert. Dadurch können

zeitkritische Anwendungen wie VoIP beim Routing mit einer höheren Priorität behandelt

werden. Wesentlich vereinfacht wurde auch die Anbindung an mehrere ISPs gleichzeitig. Die

Geräte im Netzwerk erhalten einfach mehrere Präfixe und verwenden, je nach

implementiertem Algorithmus, die Adresse für eine Verbindung, die die größte

Übereinstimmung im Präfix des Empfängers aufweist und somit den geringsten

Routingaufwand verspricht. Eine wichtige Neuerung bei IPv6 ist, dass ein mobiler Nutzer auf

Wunsch immer unter derselben IP-Adresse erreichbar ist. Bei IPv6 wird oft von Nodes oder

Geräten gesprochen, anstatt von Computern. Dies liegt an dem Wunsch, mittels IPv6

zukünftig alle elektrischen Geräte im Haushalt und Büro vernetzen zu können. Der PC soll in

Zukunft nur noch einen kleinen Teil des Netzwerkes ausmachen.

Da sich IPv6 teilweise noch in der Entwicklung befindet, kann es mehrere Lösungsvorschläge

für eine Problemstellung geben. Dadurch kann es zu widersprüchlichen Aussagen in anderer

Literatur kommen. Es wurde versucht, jeweils den Vorschlag zu übernehmen, der die größte

positive Resonanz in der Entwicklergemeinde hervorruft.


3.2. Der IPv6-Header

Der IPv6-Header1 wurde gegenüber dem IPv4-Header deutlich vereinfacht. Unnötige

Optionen wurden gestrichen und durch einige Neue ersetzt. Der Header hat bei IPv6 eine feste

Länge, zusätzliche Optionen können über Erweiterungsheader angehangen werden.

4 Bit 8 Bit 20 BitVersion Traffic Class Flow Label

16 Bit 8 Bit 8 BitPayload Length Next Header Hop Limit

128 BitSource IP Address

128 BitDestination IP Address

Abbildung 13: Der IPv6-Header

Durch die Verkettung (Abbildung 14)2 einzelner Header ist IPv6 sehr flexibel. IPv6 bietet

unter anderem Header zur Fragmentierung, Authentisierung und Verschlüsselung sowie

Header mit Optionen für das Routing. Bei den Erweiterungsheadern wird unterschieden, ob

sie nur vom Empfänger oder auch von den Router ausgewertet werden müssen. So steht der

sogenannte Hop-by-Hop-Header immer an erster Stelle, da dieser Optionen für die Router

mitführt.

1 [RFC2460]

2 entnommen aus: [HPDIT] Seite 11

Abbildung 14: IPv6-Header mit zwei Erweiterungen


3.3. IPv6-Adressierung

Bei IPv6 wird zwischen drei Adresstypen (Abbildung 15)1 unterschieden, Unicast, Multicast

und Anycast. Unicast-Adressen stellen die gewöhnlichen Adressen für ein einzelnes Interface

dar, wobei mittels Multicast-Adressen mehrere Geräte gleichzeitig angesprochen werden

können. Anycast-Adressen stammen aus dem Wertebereich der Unicast-Adressen. Mittels

Anycast-Adressierung können mehrere Geräte gleichzeitig adressiert werden, wobei ein

Router ein Datenpaket im Gegensatz zu Multicast nur an einen der möglichen Empfänger

weiterleitet. In der Internetgemeinde herrscht derzeit noch Unklarheit über die Verwendung

von Anycast-Adressen, da bislang konkrete Anwendungsbeispiele fehlen.

Wie auch in IPv4 wurden einzelnen Adressblöcken bestimmten Aufgaben zugeordnet. Die

Blöcke haben die in Tabelle 3 aufgelisteten Präfixe2.


2 [RFC2373]

Abbildung 15: Adresstypen


Verwendung Präfixbinär hexadezimal1

Anteil amAdressraum

noch frei 0000 0001 0100::/8 1/256Abbildung von NSAP-Adressen(Network Service Access Point)

0000 001 0200::/7 1/128

Abbildung von IPX-Adressen(Internet Packet Exchange Protocol)

0000 010 0400::/7 1/128

noch frei 0000 011 0600::/7 1/128noch frei 0000 1 0800::/5 1/32noch frei 0001 1000::/4 1/16globale Unicast-Adressen 001 2000::/3 1/8noch frei 010 4000::/3 1/8noch frei 011 6000::/3 1/8noch frei 100 8000::/3 1/8noch frei 101 A000::/3 1/8noch frei 110 C000::/3 1/8noch frei 1110 E000::/4 1/16noch frei 1111 0 F000::/5 1/32noch frei 1111 10 F800::/6 1/64noch frei 1111 110 FC00::/7 1/128noch frei 1111 1110 0 FE00::/9 1/512Link-Local Unicast-Adressen 1111 1110 10 FEB0::/10 1/1024Site-Local Unicast-Adressen 1111 1110 11 FEC0::/10 1/1024Multicast-Adressen 1111 1111 FF00::/8 1/256

eingebettete IPv4-Adressen Präfix (hexadezimal)Abbildung von IPv4-Adressen 0:0:0:0:0:FFFF::/96IPv4 kompatible Adressen 0:0:0:0:0:0::/966to4-Adressen 2002::/16Tabelle 3: IPv6-Präfixe

1 Darstellung siehe Seite 23


3.3.1. Unicast-Adressierung

Wenn man heute über den Aufbau einer Unicast-Adresse für IPv6 spricht, beschreibt man in

der Regel den im RFC 2374 beschriebenen Vorschlag für globale Unicast-Adressen mit dem

Formatpräfix 001. Dieses Adressformat zeigt sehr deutlich die gewünschte hierarchische

Struktur der IPv6-Adressen (Abbildung 16).

Bit 3 13 8 24 16 64Art desInhalts Präfix TLA-ID Reserviert NLA-ID SLA-ID Interface-ID

Werte: 001 ID des TopLevelAggregators

frei ID des NextLevelAggregators

ID des SideLevelAggregators

Abbildung der MAC-Adresse des Interfaces

Abbildung 16: Unicast-Adressierung nach RFC 2374

Die IANA (Internet Assigned Numbers Authority) hat Ende 2001 die Adressierung der IPv6

Adressen durch ein neues und wesentlich einfacher aufgebautes Format ersetzt, welches in

RFC 3587 und RFC 3177 beschrieben wird (Abbildung 17). Die IDs der TLAs und NLAs

wurden gestrichen und durch ein globales Präfix ersetzt. Die ID des SLA wird durch die

funktionsgleiche Subnet-ID ersetzt. Das Präfix „001“ ist nicht mehr verpflichtend. Bei Bedarf

darf auf weitere Präfixe ausgewichen werden.

Bit 48 16 64Art desInhalts globales Präfix Subnet-ID Interface-ID

Werte: 001 Präfix aus dem Wertebereich des Providers Subnetzbildungdes Endkunden


Abbildung 17: Unicast-Adressierung nach RFC 3587 und 3177

Endkunden sollen eine Adresse der Größe /48 (65.536 Subnetze), /64 (ein Subnetz) oder /128

(ein Interface/Gerät) zugeteilt bekommen. Bei begründetem Bedarf können Kunden jedoch

auch größere Netze als /48 zugeteilt bekommen. Dadurch muss der reservierte Bereich für die

Subnetzbildung variabel gestaltet werden.

Es ist denkbar, dass viele Provider den Kunden eine Subnetzbildung nur gegen Aufpreis

ermöglichen und der Bereich für die providerseitige Subnetzbildung verwendet wird. Des

Weiteren werden Kleinstnetzwerke keine Subnetzbildung benötigen.


3.3.2. Site-Local- und Link-Local-Adressen

Die Site-Local- und Link-Local-Adressen gehören zu den Unicast-Adressen. Die Site-Local-

Adressen ähneln den privaten Adressen von IPv4. Diese Adressen haben keine globale

Gültigkeit. Da die Verwendung von Site-Local-Adressen sehr umstritten ist, gelten sie

mittlerweile als veraltet.

Die Link-Local-Adressen sind ausschließlich zur Kommunikation mit den Nachbarn gedacht

und werden bei IPv6-fähigen Geräten beim Start selbst erzeugt. Link-Local-Adressen werden

nicht geroutet und benötigen somit nur eine Eindeutigkeit innerhalb eines Subnetzes.

3.3.3. Multicast-Adressierung

Mittels Multicast lasssen sich bestimmte Gerätegruppen im Netz ansprechen, wobei auch

selbstdefinierte Gruppen für kommende Anwendungen möglich sind. Eine Auswahl der

wichtigsten Multicast-Adressen findet sich in Tabelle 4.

Multicast-Adresse VerwendungFF02::1 alle benachbarten Geräte FF02::2 alle benachbarten RouterFF05::2 alle Router im lokalen NetzFF02::1:2 alle benachbarten DHCPv6-AgentenTabelle 4: Einige Multicast-Adressen

Durch die Verwendung von Multicast-Adressen werden Broadcastnachrichten zur Auffindung

einzelner Dienste wie DHCP-Server unnötig. Mit Hilfe von individuellen Multicast-Gruppen

können beispielsweise Multimediadaten gleichzeitig an mehrere Empfänger versendet

werden.

3.3.4. Darstellung von IPv6-Adressen

Die 128 Bit langen IPv6 Adressen sind sehr unübersichtlich. Um sie dennoch handhabbar zu

gestalten, wurden einige Regeln1 zur Darstellung definiert. Es wird empfohlen, die Adressen

1 [HEINREIS] Seite 40 ff.


in hexadezimaler Schreibweise darzustellen, wobei jeweils vier Ziffern (16 Bit) von einem

Doppelpunkt getrennt werden. Auf die Adresse folgt meistens die Subnetzmaske. Eine gültige

IPv6-Adresse wäre demnach 2001:0000:0000:0010:0000:0000:0000:0001/64. Um die

Lesbarkeit zu verbessern, können führende Nullen weggelassen werden. Blöcke, die nur aus

Nullen bestehen, können durch zwei Doppelpunkte ersetzt werden. Dies darf jedoch nur

einmal pro Adresse genutzt werden, um die Integrität der Adresse sicherzustellen. Die oben

genannte Adresse lässt sich in der Kurzform 2001:0:0:10::1/64 darstellen, die Loopback-

Adresse in der Kurzform ::1. Um Abbildungen von IPv4-Adressen besser darstellen zu

können, sind auch gemischte Hexadezimal- und Dezimaldarstellungen erlaubt. Die IPv6-

Version der Adresse 192.168.1.2 kann durch ::192.168.1.2 dargestellt werden.

Um bei manchen Programmen eine Portnummer mit angeben zu können, wird die Adresse oft

in eckige Klammern gesetzt. Eine Webseite kann beispielsweise mit der Adresse

[2001:0:0:12::20]:80 aufgerufen werden.

3.3.5. Autokonfiguration

Der Aufwand zur Verteilung der IP-Adressen und zum Einrichten der Netzwerkkonfiguration

sollte mit IPv6 geringer werden als mit IPv4. Deswegen hat man bei der Entwicklung von

IPv6 besonders viel Wert auf eine Autokonfiguration gelegt.

Statuslose AutokonfigurationDurch die Interface-ID wird den an ein IPv6-Netz angeschlossenen Geräten die Möglichkeit

geboten, sich über die statuslose Autokonfiguration eine IP-Adresse selbst zu vergeben. Da

die Netzwerkinterfaces in der Regel eine weltweit einmalige MAC-Adresse besitzen, kann

hieraus das Präfix des Netzes zu einer weltweit einmaligen IP-Adresse ergänzt werden. Da die

MAC-Adresse in der Regel nur 48 Bit lang ist, muss sie auf 64 Bit abgebildet werden.

Abbildung 18: Generierung der Interface-ID


Wie in Abbildung1 18 zu sehen ist, wird die MAC-Adresse geteilt und mit FFFE aufgefüllt.

Das zweitniederwertigste Bit des ersten Bytes wird auf 1 gesetzt, um eine globale

Eindeutigkeit zu markieren. Dieses Bit ist bei MAC-Adressen immer 0. Bei nicht global

eindeutigen Interface-IDs ist dieses Bit auf 0 zu setzen.

Die ersten 64 Bit werden über Router Advertisement Messages regelmäßig durch die im Netz

befindlichen Router bekannt gegeben. Durch diese Nachricht erfährt das Gerät ebenfalls das

Gateway. Da diese Bekanntgabe nur im Abstand von wenigen Minuten erfolgt, kann ein Gerät

mit Hilfe einer Router Soliciation Message die Router auffordern, eine Router Advertisement

Message zu verschicken.

Privacy ExtensionDurch die gleichbleibenden und einmaligen 64 Bit der Interface-ID kann ein Rechner immer

wieder identifiziert werden. Dadurch besteht die Gefahr, dass Daten über mobile Nutzer

gesammelt werden können.

Um dies zu verhindern, wurde die Privacy Extension for Stateless Address Autoconfiguration

in IPv62 entwickelt. Rechner, die nicht als Server dienen, sollen in regelmäßigen Abständen

eine neue IP-Adresse generieren. Es wird empfohlen, dies täglich bis mehrmals täglich zu tun.

Die neue Adresse wird für neue Verbindungen verwendet, bereits initiierte Verbindungen

benutzen bis zu deren Beendung die alte Adresse weiter.

Die Interface-ID wird mit Hilfe eines MD5-Hashs generiert. Als Eingabe für die Hashfunktion

dient eine Zufallszahl und, wenn vorhanden, eine MAC-Adresse. Durch die Duplicate-

Address-Detection3 wird sichergestellt, dass es keine Kollision bei den IP-Adressen gibt.

Statusbehaftete Autokonfiguration

Unter der statusbehafteten Autokonfiguration versteht man in der Regel das Verwenden des

Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Möchte man den einzelnen

Geräten von einer zentralen Stelle aus über mehrere Subnetze hinweg eine IP-Adresse

vergeben, ist DHCPv6 nötig. Mit DHCPv6 lässt sich die Adressvergabe besser kontrollieren

als über die statuslose Autokonfigutration. DHCPv64 ist eine Weiterentwicklung des


2 [RFC3041]

3 [RFC2462]

4 [RFC3315]


klassischen DHCP für IPv4 (DHCPv4). Da man DHCPv4 schon um zahlreiche Funktionen

erweitert hat, entschloss man sich, das Protokoll in einer neuen Version herauszugeben und

nicht erneut die alte Version anzupassen.

3.4. Quality of Services

Bei IPv6 unterscheidet man zwischen 2 QoS-Kriterien. Mit Hilfe der Traffic Class wird die

Priorität des Paketes angegeben. Mit Hilfe des Flow Labels soll sichergestellt werden, dass

der Jitter gering bleibt. Beide Optionen sind bereits im Standardheader enthalten, die

Verwendung bleibt allerdings freigestellt.

Traffic Class

Die Traffic Class ähnelt dem aus IPv4 bekannten Type of Service (TOS) und besteht aus 5

Feldern (Abbildung 19)1, die Angaben zu den Übertragungsanforderungen des Pakets machen.

Hier wird zwischen Laufzeit und Zuverlässigkeit unterschieden.

0 1 2 3 4 5 6 7CE ECT DP Service Class MBZAbbildung 19: Traffic Class

Das Bit Congestion Experienced (CE) wird vom Router gesetzt, wenn das Paket durch einen

Stau aufgehalten wurde. Alle weiteren Bits werden vom Absender festgelegt. Wenn das Bit

ECN-capable transport (ECT) gesetzt ist, können Stauwarnungen an den Absender gesendet

werden. Das Bit Drop Preference (DP) zeigt an, dass ein Paket bei einer Überlastung

bevorzugt verworfen werden kann. Dies macht vor allem bei Diensten Sinn, die ein

verspätetes Paket selbst auch verwerfen würden. Das Feld Must be Zero (MBZ) zeigt an, dass

die Traffic Class nach einem anderen, zukünftigen Verfahren ausgewertet werden muss. Die

Werte für die Service Class sagen aus, ob eine niedrige Verzögerung nötig ist oder der Jitter

minimal gehalten werden muss. Zeitunkritische Anwendungen wie Email können dagegen

eine besonders langsame Übertragen gestatten (Tabelle 5)2.


2 nach: [HPDIT] Seite 16


Wert Funktion0001 zeitunkritischer Verkehr (z.B. Email)0000 unklassifiziert1000 interaktiver Verkehr, Übertragung mit geringer

Verzögerung erwünscht (z.B. Telnet / SSH)1001 Realzeitanwendungen, geringe Verzögerung,

geringer Jitter (z.B. VoIP)0010 Steuernachrichten, maximale Zuverlässigkeit

(z.B. Routing)0010 Massendaten, maximaler Durchsatz (z.B. FTP /

SCP)Tabelle 5: Einige Werte der Service Class

Flow Label

Eine IPv6-fähige Anwendung füllt das Feld Flow Label in allen Paketen einer Verbindung

immer mit der gleichen Zufallszahl. Dadurch können Router zusammengehörige Pakete

erkennen. Protokolle wie RSVP (Resource Reservation Protocol) versuchen, diese Pakete

immer über die gleiche Strecke zu routen, um somit den Jitter zu verringern. Der Wert 0 gibt

an, dass kein Flow Label verwendet wird.

3.5. Mobile-IPv6

Derzeit stellt die nomadische Nutzung eines internetfähigen Gerätes den Nutzer vor eine

Reihe von Problemen. Individuelle Netzwerkonfiguration und aufwendige VPNs sind

notwendig, um den Rechner wie im Heimnetz nutzen zu können. Die Netzwerkkonfiguration

kann mittels einer Autokonfiguration via DHCP erfolgen, allerdings besteht dann immer noch

das Problem einer dem Rest des Internets unbekannten IP-Adresse. Die Entwickler von IPv6

haben in IPv6 einen Mechanismus integriert, der die größten Probleme beseitigt.

Jeder Rechner, der in einem fremden Netzwerk angeschlossen wird, bekommt automatisch

von dem lokalen Router eine sogenannte Care-Of-Adresse aus dem Wertebereich des Netzes

zugewiesen. Diese Care-Of-Adresse wird dem Heimrouter mitgeteilt (Binding), welcher dann

als Home Agent tätig wird. Wird ein Paket an den mobilen Rechner gesendet, wird dieses von

dem Home Agent an die Care-Of-Adresse weitergeleitet. Daraufhin antwortet der mobile

Rechner dem ursprünglichen Sender und teilt ihm über die Option Home Address im

Destination-Option-Header seine aktuelle IP-Adresse mit.


Vorgehensweise, um einen mobilen Rechner zu erreichen (Abbildung 20)1:

1. Ein entfernter Rechner sendet ein Paket an den Home Agent des Users.

2. Der Home Agent leitet das Paket an den mobilen Rechner weiter.

3. Der mobile Rechner antwortet dem entfernten Rechner direkt. Im Antwortpaket ist

ebenfalls die Care-Of-Adresse enthalten.

4. Weitere Kommunikation ohne Umwege über die Care-Of-Adresse

3.6. Migration von IPv6 und IPv4

Bei der Einführung von IPv6 ist zu beachten, dass man das Internet nicht über Nacht oder in

einem vorhersagbaren Zeitraum auf IPv6 umstellen kann. Um die Umstellung so sanft wie

möglich durchzuführen, ist es notwendig, beide IP-Versionen zeitgleich einsetzen zu können.

Dies bedeutet auch, dass IPv4-Geräte mit IPv6-Geräten kommunizieren können müssen und

umgekehrt. Man kann davon ausgehen, dass IPv6-Geräte meist auch IPv4 beherrschen.

3.6.1. Tunnel

Um zwischen zwei Punkten im Netzwerk mit dem gewünschten Protokoll kommunizieren zu

können, muss eine Lösung gefunden werden, mit der man das Protokoll unabhängig von den

Fähigkeiten des Netzwerkes nutzen kann. Dazu dienen in der Regel Tunnel. Mit Hilfe eines

1 frei nach: [IPV6NET]

Abbildung 20: Mobile-IPv6


Tunnels kann man zwei einzelne Rechner, zwei Netzwerke oder einen Rechner mit einem

Netzwerk verbinden.

Wenn man heutzutage über IPv6 mit entfernten Rechnern kommunizieren möchte, muss man

das Protokoll über IPv4 tunneln, da aktuelle Netzwerke meist nur IPv4 direkt unterstützen.

Sobald primär IPv6 im Netzwerk genutzt wird, ändert sich die Situation und die reinen IPv4-

Geräte müssen über Tunnel Anschluss an das restliche IPv4-Netz erhalten.

Tunnelprotokolle

Es gibt viele verschiedene Protokolle, um einen Tunnel aufzubauen. In der Regel wurden sie

entworfen, um virtuelle private Netzwerke (VPN) bilden zu können. Je nach Protokoll bieten

sie unterschiedliche Sicherheitsfunktionen. Auch bei der NAT-Kompatibilität unterscheiden

sich die Protokolle stark.

IPv4-Header

ESP-Header

Original IPv6-Header

Daten (inkl. TCP/UDP) ESP-Trailer

ESP-Authentication

Abbildung 21: IPSec im Tunnelmodus mit ESP

a) IPSecEin sehr sicherer Tunnelmechanismus für IPv6 ist IPSec, der mittlerweile auch für IPv4

erhältlich ist. Die zahlreichen Sicherheitsfunktionen bieten einen guten Schutz, um die

Authentizität, Integrität, Verbindlichkeit und Vertraulichkeit zu gewährleisten. IPSec kann

neben einer einfachen Passphrase auch mit X.509-Zertifikaten umgehen und bietet dadurch

eine sehr ausgefeilte Rechteverwaltung. Zahlreiche SoHo1-Router können mittlerweile mit

IPSec umgehen, lediglich ältere Geräte haben damit ihre Schwierigkeiten.

IPSec unterstützt den Tunnel- und den Transportmodus. Der Tunnelmodus (Abbildung 21)

verbindet zwei Netzwerke, die jeweils auch aus nur einem Gerät bestehen können und

verschachtelt die IP-Pakete in einem neuen Paket. Dieser Modus ist für einen Tunnel zur

Anbindung an ein IPv6-Netz zu verwenden. Der Transportmodus gewährleistet eine echte

Ende-zu-Ende-Sicherheit. Da er aber den vorgegebenen IP-Header weiterverwendet, ist dieser

Modus für einen Tunnel nicht anwendbar.

1 Small Office / Home Office


IPv4-Header

UDP /TCP

OpenVPN-Header

verschlüsselteroriginal IPv6-Header

verschlüsselte Daten (inkl. TCP/UDP) Trailer

Abbildung 22: OpenVPN

b) OpenVPN

OpenVPN bietet einen Tunnel über UDP oder TCP an, dadurch gibt es mit NAT keine

Probleme (Abbildung 22). Die SSL-Verschlüsselung kann wie bei IPSec mit Hilfe von X.509-

Zertifikaten erfolgen. Als Vorteil gegenüber IPSec zählt, dass OpenVPN auf Nutzerebene

verwendet werden kann, ohne Adminisrtationsrechte zu benötigen.

IPv4-Header

OriginalIPv6-Header

Daten (inkl. TCP/UDP)

Abbildung 23: Simple Internet Transition

c) SITDas sehr einfache Protokoll SIT (Simple Internet Transition) verfügt über keinerlei

zusätzlichen Sicherheitsmaßnahmen. Der IPv6-Header bekommt einfach einen neuen IPv4-

Header vorangestellt (Abbildung 23), welcher bis zum Gateway des zu verbindenden

Netzwerkes geroutet wird. Mit SIT können die meisten SoHo-Router nichts anfangen,

dadurch ist dieses Tunnelprotokoll für den Endanwender oft nicht anwendbar.

d) Automatische Tunnel

Neben den statischen Tunneln gibt es auch die Möglichkeit, Tunnel bei Bedarf aufzubauen.

Ein automatischer Tunnel baut eine IPv6-Verbindung über ein IPv4-Netz auf. Der

Tunnelendpunkt wird über eine IPv4-kompatible1 Adresse angesprochen, so kann der

Endpunkt über seine IPv4-Adresse erreicht werden. Neuere Verfahren nutzen allerdings ein

Adressierungskonzept, das eine Subnetzbildung zulässt und mehr als einen Rechner über den

Tunnel anbinden kann. Bei den dabei verwendeten 6to4-Adressen folgt auf das Präfix 2002

die IPv4-Adresse. Wie bei den herkömmlichen Unicast-Adressen sind die darauf folgenden

Bereiche für die Subnetzbildung 16 Bit und die Interface-ID 64 Bit lang. ISATAP (Intra-Site

Automatic Tunnel Addressing Protocol) benutzt ein herkömmliches 64 Bit Präfix inklusive

1 Aufbau siehe Seite 21


Subnetzbereich und schreibt die IPv4-Adresse in die letzten 32 Bit der Interface-ID. Die

ersten 32 Bit der ID werden mit dem Wert 0x00005E5F aufgefüllt.

3.6.2. Migrationsmechanismen

Um den Übergang in das IPv6-Internet so sanft wie möglich zu machen, ist ein direktes

Zusammenspiel von IPv4 und IPv6 nötig. Dafür sind verschiedene Migrationsverfahren

entwickelt worden:

Dual Stack

Eine Möglichkeit der Migration bietet der Dual Stack. Ein IPv6-fähiges Gerät nutzt weiterhin

IPv4 zur Kommunikation mit reinen IPv4-Geräten. Hierzu muss eine IPv4-Kommunikation

zwischen den beteiligten Geräten möglich sein. Das gesamte dazwischen liegende Netz muss

IPv4 unterstützen. Dual-Homed Geräte besitzen mindestens zwei Netzwerkanschlüsse, die

jeweils nur ein Protokoll bedienen. So läßt sich das IPv4-Netz von dem IPv6-Netz trennen.

NAT-PTReine IPv4-Geräte können mittels NAT-PT (Network Address Translation - Protocol

Translation) direkt mit reinen IPv6-Geräten kommunizieren. NAT-PT übersetzt den IPv4-

Header in einen IPv6-Header und umgekehrt. Gleiches passiert bei Bedarf mit den höheren

Protokollebenen. Durch dieses Verfahren kann jedoch nur die Schnittmenge des

Funktionsumfangs beider Protokolle genutzt werden. Ein reines IPv6 Gerät nutzt IPv4-

kompatible Adressen, um im NAT-PT-fähigen Router die Umsetzung zwischen dem IPv4-

Gerät und sich selbst zu veranlassen. Der Router nutzt für die Kommunikation mit den

Geräten die IPv4-kompatible IPv6-Adresse und eine dafür reservierte IPv4-Adresse. Der

Router benötigt so viele IPv4-Adressen wie reine IPv6-Geräte aus seinem Netzwerk

gleichzeitig mit IPv4-Geräten kommunizieren können sollen. Wenn ein IPv4-Gerät eine

Verbindung zu einem IPv6-Gerät aufbauen möchte, ist vorher eine DNS-Abfrage nötig. Über

den DNS-Server bekommt das Gerät eine IPv4-Adresse als Kontakt genannt, die zeitgleich im

Router für diese Verbindung zugeordnet wird.

Bei der Erweiterung NAPT-PT (Network Address Port Translation - Protocol Translation)

geschieht zusätzlich eine Portumsetzung bei TCP- und UDP-Paketen. Dadurch kann eine

IPv4-Adresse wie bei PAT (Port Address Translation) für mehrere Verbindungen gleichzeitig

genutzt werden.


4. Unicast-Adressen mit eingebettetem Local Area Code

4.1. Allgemeines

Basierend auf dem aktuellen Adressierungsschema der IANA für globale Unicast-Adressen

sollen hier mehrere Möglichkeiten vorgestellt werden, wie man die geographische Zuordnung

von IP-Adressen durchführen kann.

Da die geographische Zuordnung der Internetteilnehmer ein sehr interessantes Thema ist,

wurden bereits einige Vorschläge zu dem Thema veröffentlicht.

Geopriv

Der derzeit vielversprechendste Ansatz ist das Projekt Geopriv1, welches von der

gleichnamigen Workgroup der IETF2 (Internet Engineering Task Force) entwickelt wird. Im

Gegensatz zu anderen Projekten wird bei Geopriv die Lokalisierung durch ein spezielles

Protokoll durchgeführt. Dies ermöglicht eine genaue Ortsbestimmung, ist jedoch aufwendig in

der Implementation.

Metro-Bases AddressingDas Metro-Based Addressing3 (Abbildung 24) sieht eine Struktur ähnlich dem Aufbau der

Telefonnummern vor. Dieses Verfahren ist jedoch nie bis zu den Standardisierungsgremien

vorgedrungen, da es den Routern kaum Hilfen bietet und die Routingtabellen sehr groß

werden würden.

Präfix Land-ID Stadt-ID Subnetz-ID Subnetzinterne Aufteilung / lokaler Bereich

Abbildung 24: Metro-Based Addressing

Provider-Independent Address Format

Der von [HAIN] entwickelte Vorschlag für ein providerunabhängiges Adressformat

(Abbildung 25) hat die gleichen Schwächen wie das Metro-Based Adressing. Das Internet

1 [GEOPRIV]

2 [IETF]

3 [METADD]


folgt nicht immer den geographischen Strukturen und der nächstgelegenste Weg ist nicht

immer der beste. Dieses Adressformat erlaubt eine Lokalisierung auf 10 m genau. Die Angabe

des Ortes erfolgt in Längen- und Breitengraden.

4 Bit 44 Bit 16 Bit 64 Bit

Präfix geographische Zuordnung Subnetz-ID Interface-ID

Abbildung 25: Providerunabhängiges Adressformat

4.2. Der Local Area Code

Der Local Area Code (LAC) richtet sich nach den aktuellen Orts- und Landesvorwahlen im

Ortsnetz. Da die Ortsnetzkennzahl in einigen Ländern zur Zeit sehr große Gebiete abdeckt,

kann die Auflösung beim LAC auch höher sein als im Telefonnetz. In Deutschland gibt es

derzeit 5205 Ortsvorwahlen1. 13 Bit würden 8192 Ortsvorwahlen erlauben. Da eine einfache

Umsetzung der Zahlenwerte 16 Bit benötigen würde (Bsp: Vorwahl 039405 für Hötensleben),

muss hier auf eine Korrespondenztabelle zurückgegriffen werden, welche national genormt

ist.

Es wird vorerst angenommen, dass die Anzahl von 8192 Ortsvorwahlen in allen Ländern

ausreicht. Wenn ein Land mehr als 8192 Ortsvorwahlen benötigen sollte, wird diesem eine

zweite Landesvorwahl zugeteilt. Es gibt derzeit 248 Ländervorwahlen2. Da die Reserve bei 8

Bit nur minimal wäre, werden hierfür mindestens 9 Bit benötigt. Somit können 512

Ländervorwahlen genutzt werden. Bei ausreichend Spielraum ist eine Reservierung von 14 Bit

für den nationalen LAC sowie 10 Bit für den internationalen LAC wünschenswert. Die Größe

des LAC wird im Folgenden „m“ genannt.

4.3. Adressierungskonzepte

Die Adressierung soll das Formatpräfix „100“ erhalten, das ursprünglich schon für ein rein

geographisches Adressierungschema vorgesehen war. Es wurden in der Arbeitsgruppe

verschiedene Konzepte betrachtet und diskutiert.

1 [TELVOR]

2 [TELVOR]


Konzept AIn diesem Konzept wird der LAC in den ersten 64 Bit zwischen der Subnet-ID und der

Interface-ID eingefügt (Abbildung 26). Unter der Voraussetzung, dass die Provider den

Adressraum für Subnetze variabel gestalten können, lassen sich einige Bits einsparen und für

die geographische Zuordnung verwenden.

Bit 64 – (n + m) n m 64Art desInhalts globales Präfix Subnetz-ID LAC Interface-ID

Werte: 100 Präfix aus dem Wertebereich desProviders

Subnetzbildungdes Endkunden

geographischeZuordnung


Abbildung 26: Konzept A

Diese Adressierungsform geht sparsam mit den Reserven des Adressraumes um. Der Aufbau

gestaltet sich einfach. Eine Änderung an den IPv6-fähigen Endgeräten ist nicht notwendig.

Wenn Endkunden eine Subnetzbildung durchführen dürfen, haben sie auch die Möglichkeit,

ihren LAC selbst zu wählen. Ein Missbrauch muss durch Überprüfung des LAC durch den

Provider verhindert werden.

Konzept BEine Alternative wäre ein Tausch der Positionen von LAC und Subnetz-ID (Abbildung 27).

Bit 64 – (n + m) m n 64Art desInhalts globales Präfix LAC Subnetz-ID Interface-ID

Werte: 100 Präfix aus dem Wertebereich desProviders

geographischeZuordnung

Subnetzbildungdes Endkunden


Abbildung 27: Konzept B

Ein Missbrauch des LAC ist hier nicht möglich. Eine Änderung an den IPv6-fähigen

Endgeräten ist auch hier nicht notwendig.

Da eine variable Größe des Bereiches zur Subnetzbildung nicht mehr möglich ist, muss eine

maximale Anzahl von Subnetzen festgelegt werden. Ein überregionales Firmennetzwerk mit

gleichem globalen Präfix ist ebenfalls nicht mehr möglich. Wie die folgende Rechnung zeigt,

schränkt ein ausreichend großer Bereich zur Subnetzbildung das globale Präfix in seinem

Wertebereich stark ein.


vorhandener Adressraum: 64 BitFormatpräfix: -3 BitSubnetzbildung: -16 BitLAC (günstigster Fall) -22 Bit---------------------------------globales Präfix: 23 Bit

Konzept C

Eine andere Möglichkeit ist, die Interface-ID zu verkürzen und den freigewordenen

Adressraum in den letzten 64 Bit zu nutzen. Die 64 Bit der Interface-ID können in der Mitte

geteilt und durch eine XOR-Verknüpfung auf eine einzelne 32 Bit lange Zahl abgebildet

werden (Abbildung 28). Ein Zurückrechnen auf die originale Interface-ID ist nicht möglich

und meist auch nicht erwünscht.

... 64 Bit

... alte Interface-ID

... 32 bits

... Teil 1 (32 Bit) Teil 2 (32 Bit)

... 32 Bit 32 Bit

... frei neue Interface-ID

Abbildung 28: Kürzen der Interface-ID

Beispiel mit gekürzten IDs:original Interface-ID (64 Bit): 0101 0010 1100 1010 0101 0101 0101 0010Zweiteilung der ID: 1: 0101 0010 1100 1010

2: 0101 0101 0101 0010XOR-Verknüpfung: 0000 0111 1001 1000

Neue Interface-ID (32 Bit): 0000 0111 1001 1000

Um einem möglichen Missbrauch wie bei Konzept A vorzubeugen, wird der LAC nicht vor

die Interface-ID gesetzt, sondern vor den Subnetzbereich (Abbildung 29).

Bit 64-m m 32-n n 32Art desInhalts globales Präfix LAC frei Subnetz-ID Interface-ID

Werte: 100 Präfix aus dem Wertebereich des Providers geographischeZuordnung

frei Subnetzbildung desEndkunden


Abbildung 29: Konzept C


Bei dieser Adressierungsart stehen genügend Bit zur Verfügung, um den LAC mit Reserven

unterzubringen. Ein freier Bereich ist ebenfalls noch vorhanden.

Die Möglichkeit einer Kollision zweier Adressen ist höher, allerdings auch in großen

Subnetzen immer noch sehr unwahrscheinlich. Die Funktionen zur Autokonfiguration aller

IPv6-fähigen Endgeräte müssen überarbeitet werden. Dieses Verfahren ist mit den heutigen

IPv6-Implementierungen nicht kompatibel.

4.4. Auswahl

Im Folgenden wird das Konzept C mit einigen Änderungen weiterentwickelt. Auch wenn

diese Adressierung Änderungen in der Software erfordert, ist sie langfristig die bessere

Alternative, da sie Adressraum sparend ist. Die IPv6-Adresse wird dort beschnitten, wo sie

am meisten Reserven hat. Das Kürzen der Interface-ID hat keine nennenswerten

Auswirkungen auf die Autokonfiguration und die Kollisionsresistents im Subnetz.

Das Adressformat

Die Größe des Subnetzes wird auf 16 Bit festgelegt. Um die bereits vergebenen globalen

Präfixe einfach mit dem neuen Formatpräfix weiterverwenden zu können, wird die Trennung

zwischen den beiden 64 Bit langen Blöcken aufgelöst (Abbildung 30 und 31).

Da der Local Area Code auf 24 Bit festgelegt wird, bleiben 8 Bit frei. Dieser Platz steht

zukünftigen Optionen zur Verfügung.

Bit 48 16 64Art desInhalts globales Präfix Subnetz-ID Interface-ID

Werte: 001 Präfix aus dem Wertebereich des Providers Subnetzbildungdes Endkunden


Abbildung 30: Das derzeitige Adressformat

Bit 48 24 16 8 32Art desInhalts globales Präfix LAC Subnetz-ID frei Interface-ID

Werte: 100 Präfix aus dem Wertebereich des Providers geographische Zuordnung Subnetzbildungdes Endkunden

frei Abbildung der MAC-Adresse des Interfaces

Abbildung 31: Das neue Adressformat mit integriertem LAC


Um den verfügbaren Platz sparsam zu verwenden, ist es notwendig, den Adressraum

(Abbildung 32) für den Ortscode flexibel zu gestalten. Dies ist sinnvoll, da die Länder sehr

unterschiedlich groß sind.

Bit m n 24-(m+n)Art desInhalts ... Local Area Code ...

Werte: Ländergrößenpräfix Länderpräfix Ortscode

Abbildung 32: Der LAC

Es wurde eine Größenklassenaufteilung vorgenommen, die die Anzahl der Telefonanschlüsse1

weltweit als Bezug nimmt. Diese Liste soll nur eine grobe Aufteilung darstellen. Das

Wachstumspotential in den Ländern wurde ignoriert. Ebenfalls wurde die Anzahl der Telefon-

anschlüsse pro qm nicht beachtet. Für diese Aufteilung wurden etwa 220 Länder betrachtet.

Zusätzlich wurden je 2 Bit als Reserve addiert.

Bei einer Annahme von durchschnittlich 5000 Anschlüssen pro Ortscode kam die in Tabelle 6

zu sehende Größenaufteilung heraus.

Bit Anzahl Bit Anzahl Bit Anzahl17 2 12 19 7 1916 2 11 11 6 2115 7 10 22 max. 5 5714 9 9 2513 10 8 16

Tabelle 6: Bedarf der einzelnen Länder an Bits für die Ortscodes

Um die Ländergrößen kenntlich zu machen, wurden 8 Präfixe ausgewählt, die insgesamt 576

Ländern 10 bis 17 Bit große Ortscodes zur Verfügung stellen (Tabelle 7). Wenn ein Land

tatsächlich mehr als 131072 Ortscodes benötigen sollte, bekommt es ein weiteres Präfix.

Ebenso wird mit Ländern verfahren, die unerwartet mehr Ortscodes benötigen als sie in ihrer

Größenklasse nutzen können.

1 [WORLDFACT]


Anzahl der möglichen Ortscodespro Land

AnteilOrtscode

Anzahl derLänder

Länderpräfix Adressanteil

131072 17 Bit 64 0 1/265536 16 Bit 64 10 1/432768 15 Bit 64 110 1/816384 14 Bit 64 1110 1/168192 13 Bit 64 11110 1/324096 12 Bit 64 111110 1/642048 11 Bit 64 1111110 1/1281024 10 Bit 128 1111111 1/128Tabelle 7: Einteilung der Größenklassen

4.5. Draft für die IETF

Um das Konzept des in die Adresse eingebetteten LAC durchzusetzen, muss das Konzept erst

der Öffentlichkeit vorgestellt werden.

Wenn man einen neuen Vorschlag für ein neues Protokoll oder ein neues Verfahren

veröffentlichen möchte, geschieht dies in der Regel durch ein Draft bei der Internet

Engineering Task Force (IETF)1.

Ein Draft ist ein Dokument, das einen neuen Vorschlag beinhaltet. Jeder darf seine

Vorschläge als Draft bei der IETF veröffentlichen. Wenn Änderungen nötig sind, wird ein

neues Draft mit einer neuen Versionsnummer erstellt. Wenn das Draft von der

Internetgemeinde als gut befunden wurde, wird daraus ein sogenanntes RFC (Request for

Comment). Dies ist auch meist der Zeitpunkt zu dem die ersten Implementationen erfolgen.

Sollte ein Draft innerhalb von sechs Monaten weder aktualisiert noch zu einem RFC ernannt

werden, wird es gelöscht.

Drafts werden in Englisch veröffentlicht. Um eine größtmögliche Kompatibilität zu

gewährleisten, muss das Dokument im ASCII-Format mit 72 Zeichen pro Zeile und 58 Zeilen

pro Seite erstellt werden.

1 [IETF]


Die Version 00 des Drafts zeigt alle wichtigen Punkte des Adressierungskonzeptes.

INTERNET_DRAFT A. MarikarDecember 15, 2004 University of Applied Sciences Cologne

IPv6 Global Unicast Address Format with a mapping of Local Area Code (LAC)

Document: draft-marikar-ipv6-addr-local-area-code-00.txt

Status of this Memo

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

This internet draft expires on June 18, 2005.

Abstract

This document describes a Global Unicast Address Format for IPv6 with a mapping of worldwide Local Area Code (Country Code + Area Code, LAC) which provides geographical localisation capabilities to Voice over IP (VoIP) and other applications. This proposed address format is designed e.g. for calling the LOCAL emergency hotline via VoIP, even for nomadic users. Accounting of value-added and geographical dependent services becomes possible. The LAC supports local services with at least the same accuracy as the telephone network.

Marikar [Page 1]


INTERNET-DRAFT Address Format with LAC December 2004 Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current Unicast Address Format . . . . . . . . . . . . . . . 2 3. New Unicast Address Format with LAC . . . . . . . . . . . . 3 3.1 The Local Area Code . . . . . . . . . . . . . . . . . . . . 3 3.1.1 Composing the LAC . . . . . . . . . . . . . . . . . . . . 3 3.2 Clearing space for the LAC . . . . . . . . . . . . . . . . 3 3.3 The address format . . . . . . . . . . . . . . . . . . . . 4 4. Applications which benefit from the LAC . . . . . . . . . . 5 4.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Search engines, virtual market places and other sites . . . 6 5. Goals of this address format . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

At the beginning of the development of IPv6, one goal of the address format was a reference to the geographical location. Because the construction of the Internet is different from the geographical structure, it was never implemented.

Today, there is no 100% working solution to identify a user's geographical location. Using VoIP prevents to reach the local emergency hotline, especially when the user is not connected to his home network. Introduction of LAC provides these capabilities.

A user can not change his LAC. LAC is validated by the provider, this makes it reliable. LAC in VoIP is not following E.164/E.165 numbers' plans, the implementation should be done as an LAC counter. The table of the codes should be agreed worldwide.

2. Current Unicast Address Format

The standard Global Unicast Address Format is divided into two parts, the first 64 bits and the last 64 bits. The first 64 bits are used for routing. It is split into the format prefix, the global prefix given by the provider and the subnet ID. The last 64 bits are used for the interface ID. The interface ID must be unique in each subnet. 64 bits were chosen to use MAC-addresses or other unique numbers to form the interface ID. But for protection of data privacy the Privacy Extension for Stateless Address Autoconfiguration was developed (specified in [RFC3041]). Using this extension, it is not possible to get the MAC-address through the interface ID.

Marikar [Page 2]


INTERNET-DRAFT Address Format with LAC December 2004 The currently used address format described in [RFC 3177] and [RFC3587]:

| 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+---------+-----------------------------+ |001|global routing prefix|subnet ID| interface ID |

3. New Unicast Address Format with LAC

To differ between the current address format with the prefix "001", the prefix "100" was chosen for this new format.

3.1 The Local Area Code

The Local Area Code depends on the area code used by the telephone network. As some countries have only few different area codes (e.g. USA), it is better to use more accurate LACs. At least each city could get it's own LAC. To estimate the amount of LACs, it is useful to regard the area codes in the current telephone network. There are 248 country area codes, 8 bits would be needed for these codes. E.g. in Germany there are 5205 area codes which could be coded by 13 bits. To implement a worldwide valid Local Area Code 24 bits are recommended.

3.1.1 Composing the LAC

As all countries have different sizes, the countries should be arranged into size classes. address scheme: .....| m bits | n bits | 24-m-n bits |..... -----+---------------------+----------------+-------------+----- .....| country size prefix | country code | area code |..... table: amount of area codes amount of country size per country countries prefix 131072 (17 bits) 64 0 65536 (16 bits) 64 10 32768 (15 bits) 64 110 16384 (14 bits) 64 1110 8192 (13 bits) 64 11110 4096 (12 bits) 64 111110 2048 (11 bits) 64 1111110 1024 (10 bits) 128 1111111 3.2 Clearing space for the LAC

Using the Privacy Extension for Stateless Address Autoconfiguration (specified in [RFC3041]), the interface ID has no effect to identify an interface which has no permanent IPv6-address.Marikar [Page 3]


INTERNET-DRAFT Address Format with LAC December 2004

To get more free space in the address format it is necessary to limit the interface ID. The easiest way is to reduce the interface ID to 32 bits. To use the whole 64 bits for generating a 32 bits Interface ID, it is recommended to divide the 64 bits in two parts with 32 bits. The 32 bits Interface ID is just a XOR-assignment of these two parts. Software which already supports address autoconfiguration, only needs a few changes to support 32 bits interface IDs.

It is possible to use 2^64 addresses in each subnet, more than expected to be necessary. Even 2^32 possibilities should be sufficient for one subnet.

An example with shorter IDs:

orig. interface-ID (64 Bit): 0101 0010 1100 1010 0101 0101 0101 0010

dividing into two parts: 1. 0101 0010 1100 1010 2. 0101 0101 0101 0010 ------------------- XOR-assignment: 0000 0111 1001 1000

new interface-ID (32 Bit): 0000 0111 1001 1000

scheme:

.....| 64 bits | -----+---------------------------------+ .....| old interface ID |

.....| 64 bits | -----+---------------------------------+ .....|part 1 (32 bits)|part 2 (32 bits)|

..| 32 bits | 32 bits | => --+----------------+----------------+ ..| freed |new interface ID|

3.3 The address format

To avoid manipulations on the LAC it is necessary to place the LAC between the global prefix and the subnet ID.

| 3 | 45 bits | 24 bits | 16 bits | 8 | 32 bits | +---+---------------------+-----------+---------+----+------------+ |100|global routing prefix| LAC |subnet ID|free|interface ID|

Users having a /48-address with the "001" prefix, would get a new /72-address with the "100" prefix.

Marikar [Page 4]


INTERNET-DRAFT Address Format with LAC December 2004 4. Applications which benefit from the LAC

With a coded LAC in the IP-address there are many new possibilities for applications in the Internet. Especially for accounting and roaming.

4.1 VoIP

Today, companies providing VoIP cannot locate their users if they are not connected to their home network. Using a IPv6-backbone makes it possible to identify the user's position through the IPv6-address of the local IPv6/IPv4-gateway, even if it is a nomadic user. Using IPv6 for the whole Internet makes positioning possible without the provider's help. Nomadic users can be located through the forwarding address given by their home agent.

example 1:

IPv6 used by the providers, IPv4 used by end users:

----------- | | | VoIP- | | server | provider | | ----------- \ server connected via IPv6 \ \ ------------------------------------------------------------------- | | | IPv6-backbone | | | ------------------------------------------------------------------- / connected through local IPv6/IPv4-Gateway / / DSL or similar connection ------------------- | | /-------\ | local IPv4 | /_/-----\_\ | network |--------/ ... \ end user | | | ... | ------------------- ------- IP-phone

The LAC is known by the VoIP-server through the local gateways IPv6-address. It is unimportant whether the IP-phone is connected to its home network or not.

example 2:

IPv6 used by the providers and by end users: Marikar [Page 5]


INTERNET-DRAFT Address Format with LAC December 2004 ----------- | | | VoIP- | | server | provider | | ----------- \ server connected via IPv6 \ \ ------------------------------------------------------------------- | | | IPv6-backbone | | | ------------------------------------------------------------------- / / DSL or similar connection / ------------------- | | /-------\ | local IPv6 | /_/-----\_\ | network |--------/ ... \ end user | | | ... | ------------------- ------- IP-phone

The LAC is known by the IP-phones IPv6-address. If it is not the home network the phone is connected to, the LAC is known by the telephone's care-of-address.

4.2 Search engines, virtual market places and other sites

All kinds of services which need to know the area the user is connected to become feasible without knowing anything more: Search engines and market places could provide local offerings. Any kind of services like hotlines can benefit from LAC.

5. Goals of this address format

The new IPv6 Global Unicast Address Format with included Local Area Code should be a substitution for the current IPv6 Global Unicast Address Format.

To provide new local based services it is necessary to use the LAC by all Internet service providers at least within one national market.

6. IANA Considerations

The IANA is instructed to assign the 8000::/3 prefix for global IPv6 unicast addresses with included local area code. Making this concept work, the IANA should allocate the addresses to all local Internet registries. Marikar [Page 6]


INTERNET-DRAFT Address Format with LAC December 2004 7. References

[RFC3041] T. Narten, R. Draves, Januar 2001 RFC 3041 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC3177] IAB, IESG, September 2001 RFC 3177 - IAB/IESG Recommendations on IPv6 Address Allocations to Sites [RFC3587] R. Hinden, S. Deering, E. Nordmark, August 2003 RFC 3587 - IPv6 Global Unicast Address Format

further reading literature:

[GEOVIPA] GEOVIPA TECON Technologies AG, December 2004 Lars Weyerstrass & Horst Fröhlich http://www.tecon.de mail: [email protected]

8. Author's Address

University of Applied Sciences Cologne Achim Marikar IWZ W 8-16 Betzdorferstr. 2 50679 Koeln Germany

email: [email protected]

IPR Disclosure Acknowledgement

By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.

Copyright Notice

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This internet draft expires on June 18, 2005.

Marikar [Page 7]


5. Aufbau eines IPv6-Subnetzes für VoIP-Verbindungstests

5.1. Aufbau

Es gibt zwei Anforderungen, die das IPv6-Netz im Experimentiernetz der Fachhochschule

erfüllen soll. Zur Unterstützung des GeoVIPA-Konzeptes sollen die möglichen Übergänge

von IPv4-Netzen in das IPv6-Netz für VoIP-Telefonate getestet und der aktuelle

Entwicklungsstand von IPv6 beurteilt werden können. Unabhängig davon soll das IPv6-Netz

alle gängigen Dienste anbieten, um den Studenten im Fach Datennetze einen Einblick in das

zukünftige Internetprotokoll zu gewähren. Zuletzt hängt der Aufbau des Netzes von der

verfügbaren Hard- und Software ab.

Das IPv6-Netz besteht aus mehreren Subnetzen, die durch Router miteinander verbunden

sind, um die hierarchische Struktur der IPv6-Adressen nutzen zu können. Die

Adressverteilung erfolgt wahlweise über eine manuelle Vergabe oder über eine statuslose oder

statusbehaftete Autokonfiguration (DHCPv6). Neben den gängigen Diensten wie DNS- oder

Webserver wurden SIP-Server und Tunnelgateways implementiert. Soweit wie möglich

wurden bestehende Rechner zur Ergänzung des Netzes verwendet, dadurch konnten insgesamt

8 PCs und 3 Router in das IPv6-Netz integriert werden.

Da das in dieser Diplomarbeit vorgestellte Adressierungskonzept Änderungen an der Software

nötig macht, wurde eine herkömmliche Unicast-Adressierung gewählt. Die Server und Router

sollten feste Unicast-Adressen bekommen. Die IP-Adressen der Clients dürfen dynamisch

vergeben werden.

Da bei einer Anbindung über ein IPv4-Netz ein IPv6-Tunnel genutzt werden muss, wurden

zwei verschiedene Tunnelgateways implementiert. Über einen Cisco Router aus der 4500er

Serie wurde ein SIT-Tunnelgateway implementiert. Da aber etliche SOHO-Router diesen

Tunnel nicht über NAT unterstützen, wurde ebenfalls ein OpenVPN-Tunnel eingerichtet und

getestet. Auf eine Implementation von NAT-PT wurde verzichtet, da es aus VoIP-Sicht keine

Vorteile gegenüber einem SIP-Proxy hat. Eine Protokollumsetzung ist bereits im SIP-Proxy

möglich. Informationen zu einer Umsetzung mit NAT-PT finden sich unter [ATJIDA].


5.2. Betriebssysteme

Bis auf das auf Debian basierende IPv6Gateway laufen alle Router mit dem IOS von Cisco.

Das Einrichten der vorhandenen Router der 4500er Serie gestaltete sich kompliziert, da die

neueren Versionen von IOS nicht mehr auf den betagten Geräten laufen und die älteren

Versionen noch kein IPv6 unterstützen. Mit etwas Mühe gelang es jedoch die von Cisco

zurückgenommene IOS-Version 12.2(4)T zu bekommen, die die Basisfunktionen von IPv6

versteht. Mangels Unterstützung des Betriebssystems konnten jedoch nicht alle geplanten

Funktionen implementiert werden.

Für die Server und Clients wurde als Betriebssystem Debian Gnu/Linux gewählt, da diese

Linuxdistribution dem Anwender einen großen Spielraum bei der Konfiguration des Systems

gewährt. Für Debian gibt es eine große Auswahl an Softwarepaketen, die fortwährend

aktualisiert und gepflegt werden. Die Pakete können einfach über die Paketverwaltung apt-get

installiert werden.

Für die Rechner im Datennetzlabor wurde mit Sarge die aktuelle Version aus dem Testing-

Zweig des Betriebssystems gewählt. Lediglich einer der SIP-Server läuft unter Red Hat, da

dieser bereits für eine weitere Diplomarbeit verwendet wurde.

Die Konfiguration eines großen Teils des IPv6-Netzes wurde im Rahmen einer Studienarbeit

von sechs Studenten aus dem aktuellen Kurs Datennetze übernommen.

Für die Adressierung wurden IP-Adressen mit dem noch nicht vergebenen Präfix 3000::/48

verwendet, welches bei einer Anbindung an das IPv6-Internet zuvor geändert werden muss.

5.3. Installation und Konfiguration der Dienste

Die Basisinstallation von Debian erfolgt ohne größere Schwiergkeiten und ist mittlerweile

sehr komfortabel. Um den Rechner IPv6-fähig zu machen, müssen lediglich die passenden

Kernelmodule geladen werden. Unter Debian geht dies komfortabel mit dem Programm

modconf. Die Module finden sich im Ordner kernel/net/ipv6.

Die Konfiguration der Netzwerkinterfaces erfolgt über die Datei /etc/network/interfaces1. Die

Zuweisung der Interfaces zu den einzelnen Adressen entscheidet über die Arbeitsweise mit

zwei getrennten Netzwerken oder einem mit Dual Stack.

1 Konfiguration siehe Anhang Seite 75


Weitere Software wurde mit Hilfe von apt-get installiert. Um die statuslose Autokonfiguration

zu nutzen, muss der Router in regelmäßigen Abständen eine Nachricht mit dem verwendeten

Präfix versenden. Unter Debian benötigt man das Paket radvd, um Router Advertisements zu

verschicken. In der Konfigurationsdatei /etc/radvd.conf muss lediglich ein Präfix zu den

einzelnen Interfaces zugeordnet werden. Da der DHCPv6-Server und -Client nur in einer sehr

frühen Version vorliegen, mussten diese erst kompiliert und dann per Hand in das System

eingebunden werden. Der SIP-Express-Router von [IPTEL] wird bei [BERLIOS] als Debian-

Paket angeboten und läßt sich einfach über das Programm dpkg installieren. Der dazugehörige

RTP-Proxy muss separat kompiliert und installiert werden. Der ebenfalls erhältliche

Mediaproxy wurde wegen der fehlenden IPv6-Unterstützung nicht verwendet. Einige gängige

Anwendungen wie Bind9 (DNS) und Apache2 (Webserver) enthalten bereits seit längerem

eine IPv6-Unterstützung und können in den aktuellen Versionen der Distribution verwendet

werden.

Die für den OpenVPN-Server benötigten Pakete sind ebenfalls bereits in der

Standarddistribution enthalten. Die für die Authentifizierung und die Verschlüsselung

benötigten X.509-Zertifikate wurden mit OpenSSL erzeugt. Der Server besitzt eine

selbstsignierte Root-CA. Die Clients benötigen ein von dieser Root-CA signiertes Zertifikat.

Die Konfiguration der Tunnel geschieht für jede Verbindung einzeln. Als Client wurde eine

Workstation gewählt, die keine direkte Anbindung an das IPv6-Netz besitzt. Der SIT-Tunnel wurde über einen Cisco-Router aufgebaut. Man benötigt hier weder auf der

Router- noch auf der Clientseite zusätzliche Software.

Die Konfigurationsdateien der verwendeten Software finden sich im Anhang auf den Seiten

76-89. Eine kurze Anleitung zu apt-get findet sich auf Seite 75.

Bis auf zwei Router und dem IPv6Client1 wurden alle Rechner an das IPv4- und an das IPv6-

Netz angeschlossen, wodurch die Möglichkeit besteht, wahlweise IPv4 oder IPv6 zu nutzen.

Der Backbone des IPv6-Netzes besteht aus den Routern Rome und Oslo, welche über das

IPv6Gateway an das IPv6-Internet angeschlossen werden können. Über den IPv6Server1

können einzelne Rechner oder gesamte Netzwerke über OpenVPN an das IPv6-Netz

angeschlossen werden. Der Router London stellt die gleiche Möglichkeit über SIT zur

Verfügung. Eine IPv6-Verbindung zwischen den Clients Phil und Kermit erfolgt über beide

Tunnel (Abbildung 33).


Eine Übersicht der IPv6-fähigen Geräte zeigt Abbildung 34. Eine Komplettansicht des

Experimentiernetzes findet sich im Anhang auf Seite 92.

Abbildung 34: IPv6-Netz im Experimentiernetz

Abbildung 33: Tunnel im IPv6-Netz


5.4. Entwicklungsstand

Allgemein kann man sagen, dass einer Migration nach IPv6 mit Betriebssystemen auf Linux-

und IOS-Basis kaum etwas entgegensteht. Die Handhabung der einzelnen Geräte ist durch die

statuslose Autokonfiguration wesentlich einfacher geworden. Der Einsatz von DHCPv6 ist in

den meisten Fällen unnötig. Die Anbindung an ein IPv6-Netz über einen Tunnel stellt keine

größere Hürde da. Hier gibt es mehrere Varianten, welche in der Regel ohne größere

Schwierigkeiten eingerichtet werden können. Bis auf einige wichtige Anwendungen wie NFS

sind viele gängige Anwendungen mit IPv6-Unterstützung erhältlich. Für reine IPv4-

Programme gibt es Software wie tunnel6, die eine begrenzte Kompatibilität mit IPv6

ermöglicht.

Mittlerweile gibt es zahlreiche Tunnelbroker, die dem interessierten Nutzer die Möglichkeit

bieten, sich über einen Tunnel an ein IPv6-Netz anzubinden. Diese Netze sind meist Teil des

6Bone-Testnetzes und ermöglichen die Kommunikation mit Netzwerken anderer Tunnel-

broker. Durch den großen Adressraum können sich Endkunden häufig ein bis zu 48 Bit langes

Präfix geben lassen. Das Tool TSPC zur automatischen Anbindung an das freenet6 von

[HEXAGO] ist bereits in Debian enthalten.

Im Internet finden sich zahlreiche Anleitungen1 zur IPv6-Konfiguration von Betriebssystemen

und Anwendungen. Eine einfache IPv6-Funktionalität kann so auch von unerfahrenen

Anwendern genutzt werden.

Das Betriebssystem Windows wurde nicht getestet. Hier gibt es laut [BSTOCKE] und

[HPDIT] eine funktionierende IPv6-Unterstützung. Es mangelt allerdings noch an IPv6-

fähigen Anwendungen.

1 Siehe unter anderem [JOIN] und [BIERINGER]

6. VoIP und IPv6 51

6. VoIP und IPv6

6.1. VoIP-Soft- und -Hardware

Die IPv6-Unterstützung der VoIP-Anwendungen ist sehr unterschiedlich. Der SIP-Express-

Router unterstützt IPv6 vollständig. Der verwendete RTP-Proxy hingegen ist noch nicht

ausgereift. Hier fehlt es anscheinend noch an der Nachfrage nach erhöhter Kompatibilität und

einer Lastverteilung. Es war leider nicht möglich, ein IPv6-fähiges Hardware-Telefon zu

bekommen und die verwendeten Softwarelösungen kommen mit IPv6 noch nicht gut zurecht.

Linphone weigerte sich über IPv6 RTP-Pakete zu versenden, Kphone stürzt in der IPv6-

Ausführung regelmäßig ab und zwingt dabei den X-Server gelegentlich zu einem Neustart.

Die verwendeten Hardware-Telefone verstehen sich mit dem RTP-Proxy, weigern sich aber

über den Proxy mit einem IPv6-Telefon zu kommunizieren. Eine Verbindung zwischen einem

IPv4- und einem IPv6-Telefon funktioniert nur mit Kphone in der IPv4- und IPv6-

Ausführung. Ein fehlerfreier Verbindungsabbau ist aber auch mit Kphone nicht möglich.

6.2. Leistungsfähigkeit der Migrationstechniken

Um die Verwendung von Tunnel- und Transitionstechniken für VoIP zu testen, muss das

dadurch hinzukommende Delay und der Jitter bestimmt werden. Bei dem Cisco-Router gab es

leider nicht die Möglichkeit, die Verarbeitungszeit und das Verhalten unter Volllast

verbindlich zu testen. Die verwendete Modemstrecke zwischen den Routern beschränkt die

Übertragungskapazität auf 2 MB, und ein Mitlesen der Daten ist an der seriellen Schnittstelle

mangels passender Hardware nicht möglich. Da es sich um ein veraltetes Gerät mit einer

noch nicht ausgereif

Diplomarbeit · GSM-Netze werden hier als Teil des PSTN betrachtet. UMTS ist in den neueren...

Documents

Transcript of Diplomarbeit · GSM-Netze werden hier als Teil des PSTN betrachtet. UMTS ist in den neueren...