DE102006017940A1 - Verfahren zur Herstellung einer Verbindung - Google Patents

Verfahren zur Herstellung einer Verbindung Download PDF

Info

Publication number
DE102006017940A1
DE102006017940A1 DE102006017940A DE102006017940A DE102006017940A1 DE 102006017940 A1 DE102006017940 A1 DE 102006017940A1 DE 102006017940 A DE102006017940 A DE 102006017940A DE 102006017940 A DE102006017940 A DE 102006017940A DE 102006017940 A1 DE102006017940 A1 DE 102006017940A1
Authority
DE
Germany
Prior art keywords
assigned
node computer
ipv6 address
bits
bit pattern
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102006017940A
Other languages
English (en)
Other versions
DE102006017940B4 (de
Inventor
Dietmar Tölle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority to DE102006017940A priority Critical patent/DE102006017940B4/de
Priority to PCT/EP2007/003383 priority patent/WO2007121900A1/de
Publication of DE102006017940A1 publication Critical patent/DE102006017940A1/de
Application granted granted Critical
Publication of DE102006017940B4 publication Critical patent/DE102006017940B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/35Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zur Herstellung einer Verbindung eines Nutzergerätes mit einem Rechner (Server) eines Diensteanbieters über ein Zugangsnetz und ein Transportnetz. Derartige Verfahren werden insbesondere benötigt, um Nutzergeräte mit Serviceprovidern (Diensteanbietern) beispielsweise über das Internet als Transportnetz zu verbinden. Dabei sind die Nutzergeräte meistens über ein Zugangsnetz, beispielsweise ein Ethernet-basiertes Netz, mit dem Transportnetz verbunden. Das erfindungsgemäße Verfahren dient der Verbindung eines Nutzergerätes mit mindestens einem mit einem Transportnetz verbundenen Rechner eines Diensteanbieters über ein Zugangsnetz mit mindestens einem Zugangsknotenrechner und über das Transportnetz mit mindestens einem Übergangsknotenrechner vom Zugangsnetz zum Transportnetz, wobei dem Nutzergerät mindestens eine IPv6-Adresse zugeordnet wird. Es ist dadurch gekennzeichnet, dass jeder Paarung aus je einem Zugangsknotenrechner und je einem Übergangsknotenrechner ein eindeutiges Paar von Bitmustern zugeordnet wird und für die jeweilige Paarung dem Zugangsknotenrechner und dem Übergangsknotenrechner jeweils ein Topologiepräfix der IPv6-Adresse zugeordnet wird, das jeweils eines der beiden Bitmuster des Paares von Bitmustern enthält.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zur Herstellung einer Verbindung eines Nutzergerätes mit einem Rechner (Server) eines Diensteanbieters über ein Zugangsnetz und ein Transportnetz. Derartige Verfahren werden insbesondere benötigt, um Nutzergeräte mit Serviceprovidern (Diensteanbietern) beispielsweise über das Internet als Transportnetz zu verbinden. Dabei sind die Nutzergeräte meistens über ein Zugangsnetz, beispielsweise ein Ethernet-basiertes Netz mit dem Transportnetz verbunden.
  • Insbesondere gewinnen Ethernet-basierte Netze dank ihrer Eigenschaften, wie Leistungsfähigkeit, Einfachheit, Skalierbarkeit und Kosteneffizienz, auch im Zugangsbereich (Access) immer mehr Bedeutung. Als Beispiel hierfür kann die Standardisierung von Ethernet für VDSL-basierte Zugangssysteme bei der IEEE und des Ethernet in der First Mile Allianz (EFM) genannt wer den.
  • Ethernet eignet sich auch als Kandidat für Multi-Service-Plattformen zum Transport in aggregierenden Netzen, wie beispielsweise Metronetzen.
  • Um die von den Nutzern gewünschten Dienste realisieren zu können, ist es erforderlich, sowohl die Dienste (Service) als auch die Kunden (Nutzer) voneinander zu trennen und zu identifizieren. Nur so ist es möglich, dass viele Kunden von vielen verschiedenen Internet-Dienstanbietern über dasselbe Zugangsnetz, beispielsweise ein Ethernet, verschiedene Dienste nutzen können. Es ist nicht nur wichtig, die einzelnen Kundendatenströme voneinander zu trennen, sondern auch erforderlich, diese einzeln kundenspezifisch abzurechnen.
  • Die Kunden- bzw. Diensttrennung im Internet verläuft heutzutage sehr simpel: Der Kunde trägt in einem von ihm genutzten Gerät eine von seinem Internet-Dienstanbieter gelieferte Zugangskennung (Login und Passwort) ein. Diese Zugangskennung ist meist haushaltsspezifisch, d.h. es wird weder eine richtige Diensttrennung noch eine Kundentrennung durchgeführt. Wird die Zugangskennung eingegeben und aktiviert, so wird vom Netzbetreiber, von dem die Zugangskennung kommt, eine temporäre IP-Adresse vergeben. Die Abrechnung erfolgt nach Zeitdauer der Adressvergabe (Zeittarif), nach Datenvolumen, das über die vergebene IP-Adresse transferiert wird (Volumentarif), oder über eine Pauschale (Flatrate). Die anfallenden Kosten werden dem Eigner der Zugangskennung in Rechnung gestellt.
  • Eine richtige Diensttrennung wird mit diesem Schema nicht durchgeführt, da nur Internet-Zugänge verkauft werden, keine Dienste an sich. Der einzige zugeordnete Dienst ist der Internet-Zugang selbst, über den alle anderen Dienste laufen, welche als solche aber nicht erkennbar sind.
  • Der Datentransport zwischen Kunden und Netzbetreiber läuft heute noch meist über DSL (Digitale Teilnehmeranschlußleitung, Digital Subscriber Line) und ATM (Asynchroner Übertragungsmodus, Asynchronous Transfer Mode) bis zum Internet-Übergangsknotenrechner (IP Edge Router). Der Kunde authentifiziert sich mit seiner Zugangskennung beim IP Edge Router (meist gleichzeitig auch BRAS (Broadband Remote Access Server), welcher auch die IP-Adresse (Internet-Protokoll-Adresse) nach erfolgreicher Authentifizierung vergibt. Die eingesetzten Protokolle sind bei diesem Verfahren PPP (Punkt-zu-Punkt-Protokoll, Point-to-Point Protocol) und PPPoE (PPP über Ethernet, PPP over Ethernet). Das PPP dient dabei zur Kundentrennung im BRAS. Kundentrennung heißt in diesem Falle meist Kundenanschlusstrennung, da die Zugangskennung meist im DSL-Zugangsrechner (DSL-Router) zentral eingegeben wird. Somit kann nur der Kundenanschluss identifiziert werden, nicht aber der Dienst oder der einzelne Nutzer. Die 1 und 2 zeigen zwei Beispiele, wie die Kundenanschlüsse funktionieren.
  • 1 zeigt den Protokollstack und das Anschlussschema der Anbindung eines VoIP-Telefons 11 (Internettelefonie-Telefon, Voice-over-Internet-Protocol-Telefone) an einen DSL-Anschluss über ein DSL-Modem 7. Die DSL-Zugangskennung muss im Telefon 14 eingetragen werden, um vom Netzbetreiber eine IP-Adresse zugewiesen zu bekommen. Ebenso muss die VoIP- Zugangskennung eingetragen werden, um die VoIP-Telefonnummer vom VoIP-Dienstanbieter zugewiesen zu bekommen. Netzbetreiber und Dienstanbieter können dabei dieselbe Organisation sein oder zwei getrennte.
  • 2 zeigt einen heutzutage gebräuchlicheren Netzaufbau an. Die DSL-Zugangskennung wird zentral im DSL-Router 7 (enthält das DSL-Modem) eingegeben, womit auch der Router 7 (Vermittlungsrechner 7) die IP-Adresse enthält. Kundenseitig können jetzt beliebig viele Geräte an den Router 7 angeschlossen werden und über diese eine vergebene IP-Adresse kommunizieren. In den Endgeräten ist jetzt keine Eintragung der Zugangskennung mehr notwendig. Im VoIP-Telefon 11 muss jetzt nur noch die VoIP-Zugangskennung eingetragen werden. Die Vergabe der internen IP-Adresse (192.168.x.x) kann automatisch durch den Router 7 über DHCP (Dynamisches Rechner-Konfigurations-Protocol) erfolgen oder manuell durchgeführt werden. Der Router 7 übernimmt automatisch die Umsetzung der IP-Adressen und Ports (NAPT – Netzwerkadress- und – schnittstellen/Adresskomponenten-Übersetzung, Network Address and Port Translation).
  • PPP könnte auch zur Diensttrennung bzw. Kundentrennung eingesetzt werden. Jedes Endgerät könnte seine eigene DSL-Zugangskennung besitzen und zur Kommunikation eine eigene IP-Adresse erhalten. Zudem könnte jeder Nutzer seine eigene DSL-Zugangskennung erhalten, die er jedes Mal im Gerät eingetragen oder aktivieren muss. Dies ist allerdings sehr umständlich und wird nicht genutzt. Zudem ist mit IPv4 (Internetprotokoll Version 4) der Adressvorrat gering, so dass es vermieden wird, für jeden Kunden und jedes Endgerät eine eigene Zugangskennung und damit eine eigene IP-Adresse zu vergeben.
  • Das PPP hat noch eine weitere wichtige Aufgabe: Die Sicherstellung, dass die Dienstleistung dem richtigen Kunden in Rechnung gestellt wird. Die Rechnung geht jeweils an den Eigner der Zugangskennung. Die Eingabe und Aktivierung der Zugangskennung führt zu einem PPP-Kanal, der eindeutig diesen logischen Kanal mit dem Eigner der Zugangskennung verbindet. Diese Trennung der Kundenanschlüsse erfolgt also in Bezug auf die Abrechnung durch den PPP-Kanal und nicht durch die Ethernet- oder IP-Adresse des Kunden, die Trennung des Datenverkehrs aber durch die IP-Adresse.
  • Zwischenzeitlich wird IPv4 durch das Internetprotokoll Version 6 (IPv6) abgelöst. In IPv6 steht ein wesentlich größerer Adressvorrat zur Verfügung, da die IPv6-Adresse aus 128 Bit besteht gegenüber 32 Bit der IPv4-Adressen und 48 Bit der MAC-Adressen (Media Access Control, auch LAN-Adresse, Ethernet-ID oder Airport-ID genannt). Für diese IPv6-Adressen wurden auch einige zusätzliche Managementfunktionen eingeführt, die einen zusätzlichen Nutzen bringen.
  • 3 zeigt nun das IPv6-Adressformat. In der oberen Zeile ist die Aufteilung der 128 Bit der IPv6-Adresse in zwei logische Segmente dargestellt. Die erste Hälfte der 128 Bit dienen zur Netzwerkidentifizierung (IPv6-Netzwerkadresse, IPv6 Network Address), während die letzten 64 Bit der Schnittstellenidentifizierung dienen (IPv6-Schnittstellenidentifizierer, IPv6 Interface Identifier). In der zweiten Zeile ist dargestellt, dass sich die 64 Bit der IPv6-Netzwerkadresse wiederum in einen 48 Bit langen vorangestellten Public Topology Prefix und einen 16 Bit Site Topology Prefix untergliedern. Der sog. Public Topology Prefix ist zusammengesetzt aus weiteren Elementen, nämlich 3 Bit eines Format Prefix (FP), 13 Bit eines Top-Level-Aggregation-Identifizierers (TLA ID), 8 reservierten Bit (beispielsweise für eine Top Level Aggregation (TLA) oder eine NLA-Erweiterung (NLA Extension). Weiterhin enthält das Public Topology Prefix 24 Bit eines Next-Level-Aggregation-Identifizierers (NLA ID).
  • Die letzten 64 Bit der IPv6-Netzwerkadresse setzen sich zusammen aus einem vorangestellten 16-Bit-Zusatz und der nachfolgenden MAC-Adresse der Schnittstelle mit 48 Bit.
  • Damit sind bei einer IPv6-Adresse die ersten 48 Bit durch die Netzwerkadresse und die letzten 48 Bit durch die MAC-Adresse der Schnittstelle gewöhnlich belegt.
  • Die Benutzer-Authentifizierung und damit die Grundlage für die Überprüfung, ob der Kunde diesen Dienst überhaupt nutzen darf, und die Abrechnung der Dienste (AAA – Authentication, Authorisation, Accounting) erfolgt bei einem Public Ethernet 2 mittels IEEE 802.1X-Protokoll.
  • 4 veranschaulicht die Abläufe bei der Authentifizierung. Der Benutzer identifiziert sich zunächst bei dem genutzten Gerät (z.B. PC 12, TV 13 oder Telefon 14), indem er z.B. eine PIN (Persönliche Identifizierungsnummer) einträgt oder seine Nutzerkennung aktiviert. Über IEEE 802.1X wird nun die Zugangskennung an das nächste Netzelement des Betreibers (z.B. den Authentifizierungsdienstrechner, DHCP-Dienstrechner 11) transferiert und über ein Authentifizierungsprotokoll in Verbindung mit dem RADIUS-Protkoll mittels eines Radiusservers 10 werden die AAA-Prozeduren durchgeführt. Auf diese Weise wird ge währleistet, dass der Benutzer des jeweiligen Gerätes auch die Rechnung für die Inanspruchnahme des Dienstes bekommt. Wichtig ist hierbei, dass eine sichere Kommunikation zwischen Kunden und Dienstanbieter 6 erfolgt.
  • Die IEEE 802.1X Schnittstellenauthentifizierung (Port Authentication) sorgt für diese sichere Kommunikation und stellt sicher, dass der Zugangsrouter 11 (Access Node, AN) exakt zuordnen kann, welcher Nutzer an einem bestimmten Port des AN 11 authentifiziert ist. Die AAA-Prozeduren sorgen zunächst aber nur dafür, dass der Kunde überhaupt Dienste nutzen kann und diese dann auch abgerechnet werden. Die eigentliche Datenkommunikation ist noch nicht möglich, da der Kunde noch keine globale IP(v6)-Adresse besitzt. Die Vergabe der IPv6-Adresse erfolgt nach erfolgreicher Authentifizierung.
  • Hier setzt nun die vorliegende Erfindung ein, die es sich zur Aufgabe macht, eine Nutzer- und/oder Dienstetrennung innerhalb des Netzes zu ermöglichen. Weiterhin ist es Aufgabe der vorliegenden Erfindung, für eine gesicherte Kommunikation zwischen Nutzer und Dienstbetreiber zu sorgen, so dass eine gesicherte Nutzer- und/oder Dienstetrennung ermöglicht wird. Diese Aufgabe wird durch die Verfahren nach Anspruch 1, 11 und 19 gelöst. Vorteilhafte Weiterbildungen der erfindungsgemäßen Verfahren werden in den jeweiligen abhängigen Ansprüchen gegeben.
  • Die vorliegende Erfindung setzt an der Stelle ein, bei der die Vergabe der IPv6-Adresse nach erfolgreicher Authentifizierung erfolgt. Zentraler Gedanke dabei ist, dass die einzelnen Felder und Bereiche der IPv6-Adresse flexibel gedeutet werden können.
  • Um eine gesicherte Kommunikation zwischen einem Nutzer und einem Dienstbetreiber/Diensteanbieter (Serviceprovider) zu gewährleisten, wird jetzt in einem Zugangsnetz für jede Paarung aus einem Zugangsknoten und einem Übergangsknoten in das Transportnetz/Internet eine Paarung von Bitmustern vergeben, die einen Teil des Topologiepräfixes einer IPv6-Adresse bildet. Hierdurch ist es möglich, dass jeweils ein Zugangsknoten (auch als Zugangsknotenrechner bezeichnet) bezüglich eines Nutzers mit einem spezifischen eindeutig zugeordneten Übergangsknoten kommuniziert. Es wird also bewirkt, dass ein Übergangsknoten (auch als Übergangsknotenrechner bezeichnet) Datenpakete von einem bestimmten Nutzer, die zu einem bestimmten Dienstbetreiber gesandt werden, lediglich über einen über die Paarung eindeutig identifizierten Übergangsknotenrechner zu dem Dienstbetreiber gesandt werden können. In gleicher Weise ist der Transport von Datenpaketen vom Dienstbetreiber zum Nutzergerät über einen eindeutigen Pfad gesichert. Dies bedeutet also, dass jedem Übergangsknotenrechner für jeden mit ihm verbundenen Zugangsknotenrechner eine eigene zugangsknotenrechnerspezifische IPv6-Adresse zugeordnet ist, die sich in dem vorgenannten Bitmuster für jeden der Zugangsknotenrechner unterscheidet. Dasselbe gilt für den Zugangsknotenrechner, der so viele IPv6-Adressen aufweist, wie er mit Übergangsknotenrechnern verbunden ist. Es wird also bei der vorliegenden Erfindung die Eindeutigkeit der Zuordnung zwischen einem Knotenrechner und seiner IPv6-Adresse aufgehoben.
  • Das Bitmuster, mit dem jeweils eine Paarung unterschieden wird, kann eine unterschiedliche, den jeweiligen Netzanforderungen entsprechende Länge aufwei sen. Es ist möglich, dass das Bitmuster nur wenige Bits oder auch sehr viele Bits aufweist. Vorteilhaft, jedoch nicht notwendig, ist ein Bitmuster, das eine Länge von 16 Bit aufweist. In diesem Falle ist es möglich, dieses Bitmuster als Site Topology Prefix in den ersten 64 Bits der IPv6-Adresse unterzubringen, so dass die Kombination von Public Topology Prefix und diesem Bitmuster eine 64 Bit lange Netzwerkadresse bilden. Das Bitmuster kann jedoch auch kürzer oder länger sein, wobei auf die Länge des Public Topology Prefix den jeweiligen Bedürfnissen im jeweiligen Netz angepasst werden können.
  • Um auch die jeweilige Nutzung und auch den jeweiligen Nutzer eindeutig zuzuordnen und Nutzer und/oder Dienste voneinander zu trennen, um anschließend beispielsweise eine nutzer- und dienstspezifische Abrechnung durchzuführen, kann weiterhin jedem Nutzer und/oder jedem genutzten Dienst ein eindeutiges Bitmuster zugeordnet werden. Dieses Bitmuster kann nun ebenfalls bei der Zuweisung der IPv6-Adresse in die IPv6-Adresse eingebracht werden, so dass die IPv6-Adresse des Nutzergerätes zusätzlich den Nutzer als auch den genutzten Dienst oder auch nur eine dieser Komponenten codiert. Auch dieses Bitmuster kann unterschiedlich lang sein und an unterschiedlicher Position innerhalb der IPv6-Adresse untergebracht sein. Es ist jedoch besonders vorteilhaft, wenn für das Bitmuster zur Nutzer-/Dienstetrennung die ersten 16 Bit des IPv6-Schnittstellenidentifizierers verwendet werden. Diese 16 Bit können dann weiter aufgeteilt werden, beispielsweise jedoch nicht notwendigerweise in 8 Bit für die Nutzertrennung und 8 Bit für die Dienstetrennung. Dies würde ermöglichen, 256 Nutzer und 256 Dienste, d.h. insgesamt 65536 verschiedene Nutzer- und Dienstekombinationen eindeutig zu tren nen. Dies erscheint aus heutiger Sicht als ausreichend. Es ist jedoch auch möglich, beispielsweise 10 Bit für die Nutzertrennung und 6 Bit für die Dienstetrennung zu verwenden oder auch für das Bitmuster zur Nutzer- und/oder Dienstetrennung mehr oder weniger als 16 Bit zu verwenden. Es wäre beispielsweise auch möglich, das Bitmuster für die Paarungsidentifizierung wie oben beschrieben und das Bitmuster für die Nutzer-/Gerätetrennung gemeinsam mit einer Länge von 32 Bit (es ist auch mehr oder weniger möglich) vorzusehen, wobei diese 32 Bit den Anforderungen des jeweiligen Netzwerks flexibel unter die einzelnen Bitmuster verteilt werden.
  • Es ist weiterhin möglich, in die IPv6-Adressen nicht zwingend in den letzten 48 Bit die MAC-Adresse aufzunehmen. Es wäre auch möglich, dort mit einem Bitmuster die Nutzer- und Gerätetrennung durchzuführen, so dass sich dann innerhalb des Netzwerks logische MAC-Adressen bilden, die mittels des entsprechenden Protokolls in die realen MAC-Adresse aufgelöst werden müssen.
  • Mit den beschriebenen erfindungsgemäßen Verfahren kann nun eine eindeutige Nutzer- und Dienstetrennung ausschließlich über die Vergabe der IPv6-Adressen erfolgen. Insbesondere ist es auch möglich, eine Dienstebindung (Service Bindung) durchzuführen, da der Nutzer auch andere Geräte oder an anderen Orten sein eigenes Gerät nutzen kann, ihm aber trotzdem immer eindeutig sein Nutzer- und Dienstprofil mittels der IPv6-Adresse bzw. der jeweiligen Bitmuster zugeordnet werden kann. Auch die Inrechnungstellung erfolgt immer zugeordnet, egal ob der Nutzer an anderen Geräten oder an anderen Orten mit seinem eigenen Gerät tätig ist. Das jeweilige Profil und die jeweilige Abrechnung wird dazu einfach an eine andere Adresse gebunden (Service Bindung). Weiterhin wird durch die Paarbildung der IPv6-Adressen zwischen dem Zugangsknotenrechnern und den Übergangsknotenrechnern eine sichere Kommunikation auf Ethernetebene erzielt, da die Datenverbindung nicht mehr durch Identitätsklau manipuliert werden können. Auch die Datenbehandlung wird auf Ethernetebene durch diese Paarbildung verbessert. Hierzu kann jeder Kombination von IPv6-Topologiepräfixen ein spezielles Ethernet-Label, z.B. VLAN Tag oder MPLS Label, zugeordnet werden und z.B. durch GVRP (generic VLAN registration protocol) oder GARP (generic attribute registration protocol) im Public Ethernet bekanntgemacht werden.
  • Die Zuordnung der IPv6-Adressen wie oben beschrieben, beispielsweise durch DHCPv6, kann dynamisch erfolgen und nur für die Dauer der jeweiligen Authentifizierung gültig sein. Es ist jedoch auch eine statische Zuordnung der Bitmuster möglich. Die Authentifizierung des benutzten Gerätes bzw. Nutzers beim Dienstanbieter (Provider) in Kombination mit der eindeutigen Identifizierung des Benutzers am Gerät stellt also einen komfortablen Mechanismus zur Authentifizierung und damit zur Berechnung einer Dienstleistung bereit. Auf diese Weise fallen dann auch zusätzliche Authentifizierungsschritte, wie z.B. Eingabe der VoIP-Zugangskennung weg, da der Dienstanbieter bereits über die eindeutige IPv6-Adresse sowohl den Nutzer als auch den Dienst unterscheiden kann.
  • Einzig beim Wechsel des benutzten Gerätes muss die VoIP-Zugangskennung neu eingegeben werden, wenn beispielsweise ein Nutzer ein fremdes VoIP-Telefon, z.B. des Nachbarn, nutzen möchte, wobei das Gespräch jedoch auf Rechnung des konkreten Nutzers gehen soll.
  • Hier muss der Nutzer dem jeweiligen Dienstanbieter mitteilen, dass mit der IPv6-Adresse des Nachbarn temporär mit dem VoIP-Count des Nutzers zu assoziieren ist.
  • Im folgenden werden einige Beispiele eines erfindungsgemäßen Verfahrens gegeben. In dieser Beschreibung zeigen
  • 1 die Netzanbindung eines Endgerätes an einen Dienstanbieter nach dem Stand der Technik;
  • 2 eine Netzanbindung mehrerer Endgeräte an einen Dienstanbieter nach dem Stand der Technik;
  • 3 das Format einer IPv6-Adresse;
  • 4 ein Netzwerk eines Public Ethernet mit dem Mechanismus der Benutzerauthentifizierung;
  • 5 die Authentifizierung nach der vorliegenden Erfindung;
  • 6 ein Public Ethernet mit Darstellung der Vergabe der IPv6-Adressen; und
  • 7 Beispiele für Paarungen von IPv6-Präfixen für Zugangsknotenrechner (Access Node) und Übergangsknotenrechner (Edge Node).
  • In allen Figuren wurden für gleiche oder ähnliche Elemente gleiche oder ähnliche Bezugszeichen verwendet.
  • 5 zeigt das Authentifizierungsverfahren in einem Public Ethernet, wie es beispielsweise in 4 oder 6 dargestellt ist für die einzelnen Netzelemente und Kunden.
  • Das Kundennetzelement (Supplicant) startet eine IEEE 802.1X-Authentifizierung mit einem Zugangsknotenrechner (802.1X-Authentikator, AN). Der AN wiederum nimmt Kontakt mit einem Authentifizierungsdienstrechner (Radius-Server) 10 auf. Dieser Authentifizierungsdienstrechner 10 hat Zugriff auf eine Kundendatenbank, in der neben den Kontaktdaten (Authenticate) des Kunden auch die Tarifierungs- und Dienstinformationen gespeichert sind. Diese bezeichnen u.a. die einem Kunden zugänglichen Dienste und die vereinbarten Dienstprofile und die dazugehörigen Tarifinformationen. Die eigentliche Authentifizierung zwischen dem Supplicant (beispielsweise PC 12) und dem Authentifizierungsdienstrechner 10 läuft dann über das Extensible Authentication Protocol (EAP) sowie eine wählbare Authentifizierungsmethode. Diese Authentifizierungsmethode ist es, die für die die Verschlüsselung der Information bei der Authentifizierung sorgt. Sie ermöglicht auch, die zugeordnete IPv6-Adresse dieses Kunden zu speichern und zu reservieren, so dass die Adresse immer wieder verwendet werden kann. So ist neben einer dynamischen IPv6-Adressvergabe auch eine statische IPv6-Adressvergabe zu realisieren.
  • Je nachdem welches Gerät bzw. welcher Nutzer sich authentifizieren will, wird der Zugangsknotenrechner AN 11 einen anderen Authentifizierungsdienstrechner 10 kontaktieren. Die Auswahl des richtigen Authentifizierungsdientsrechners (Authentifizierungsservers) kann entweder über die Kontaktdaten des gewünschten Dienstanbieters erfolgen, beispielsweise SIP.Anbietername.de, oder auch über dessen IPv6-Adresse. Eine weitere Möglichkeit besteht in der Auswertung der Herkunftsadresse (Source Address) des dienstanfordernden Nutzers.
  • Die Authentifizierung kann auch wie sonst in zwei Schritten erfolgen, einmal beim Internetdienstanbieter (Internet Service Provider) und zum anderen beim gewünschten Dienstanbieter selbst. Die Authentifizierung sorgt in jedem Fall für die Assoziierung des authentisierten Ports/Schnittstelle mit einem Nutzer. Danach erfolgen separat die Vergabe der IPv6-Adresse und die Authentisierung des Dienstes und Nutzers mit der IPv6-Adresse bzw. Teilen hiervon.
  • 6 zeigt nun ein Public Ethernet 2, das mit ver- schiedenen Internet-Netzwerk-Dienstanbietern (Internet Network Service Provider, NSP) 4, 4' verbunden ist. Die NSPs 4, 4' haben unterschiedliche, weltweit eindeutige IPv6-Public-Topology-Präfixe. In diesem Beispiel hat jeder Übergangsknotenrechner (Edge Node Router, EN, nach heutigem Stand auch BRAS) 3a, 3b einen 48 Bit-Präfix. Es ist jedoch auch möglich, dass die Anzahl der Bits für die Public Topology Präfixe für die einzelnen logischen Segmente in der hierarchischen IP-Adressvergabe geändert werden kann. Die benötigte Anzahl wird von der benötigen Anzahl verschiedener Netzelemente im jeweiligen Netz bestimmt und lässt sich folglich bei der Netzplanung individuell anpassen. So kann beispielsweise das Präfix des Übergangsknotenrechners auch nur 46 Bit lang sein, womit weniger Übergangsknotenrechner angeschlossen werden können, allerdings im selben Netz viermal so viele Zugangsknotenrechner (Access Nodes, AN, 8a, 11).
  • Im Folgenden wird nun die Adressvergabe für den Netzwerkserviceprovider 4 dargestellt. Für den Netzwerkserviceprovider 4' des Netzwerks 1' erfolgt die Adressvergabe entsprechend.
  • Dabei ist zu beachten, dass für sämtliche Netzwerkelemente des Public Ethernet 2 sowohl von dem Netzwerkserviceprovider 4 als auch von dem Netzwerkserviceprovider 4' des Netzwerks 1' parallel Adressen vergeben werden, so dass ein Netzelement hier immer zwei Adress-Präfixe besitzt, von jedem der Netzwerkserviceprovider je eines.
  • Bei der vorliegenden Erfindung vergibt nun der Übergangsknotenrechner EN 3a (der Übergangsknotenrechner EN 3b handelt entsprechend) per IPv6-Adressdelegation für jeden im Netzwerk 2 angeschlossenen Zugangsknotenrechner AN 8a, 11 ein individuelles IPv6 64 Bit-Präfixpaar. Jedes Präfix eines derartigen Paares besteht aus einem 48 Bit Public Topology Prefix sowie einem selbstverwalteten Site Topology Prefix. Das 48 Bit lange Public Topology Prefix ist für jeden Übergangsknotenrechner EN 3a, 3b, 3a' weltweit eindeutig. Damit sind auch die 64 Bit-Präfixe für die mit einem bestimmten Übergangsknotenrechner verbundenen Zugangsknotenrechner 8a, 11 ebenfalls eindeutig, da die 16 Bit Site Topology von jedem Übergangsknotenrechner jeweils nur einem Zugangsknotenrechner zugewiesen wird. Jeder Übergangsknotenrechner vergibt also eine Paarung von Site-Topology-Präfixen nur einmal, wobei der eine Präfix dem Zugangsknotenrechner und der andere Präfix dem Übergangsknotenrechner zugeordnet wird.
  • 7 zeigt Paarungen von Topology-Präfixen mit einer Länge von 64 Bit für drei Zugangsknotenrechner AN 1, AN 2, AN 3 (diese können beispielsweise mit dem Zugangsknotenrechner 8a, 11 etc. in 6 gleichge- setzt werden). Für jeden der Zugangsknotenrechner AN 1, AN 2, AN 3 ist eine Paarung von Site-Topology-Präfixen mit 16 Bit Länge zugeordnet, beispielsweise für den Zugangsknotenrechner AN 1 die Paarung 0027 mit 0028, für den Zugangsknotenrechner 2 die Paarung 0044 mit 0045 und für den Zugangsknotenrechner 3 die Paarung 0063 mit 0064. Zusammen mit dem Public-Topology-Präfix des Übergangsknotenrechners 2 (2005:7BA9:3453) ergibt sich nun der Topology-Präfix für den Zugangsknotenrechner AN 1 und den entsprechenden Übergangsknotenrechner so wie in der ersten Zeile der 7 angegeben. Damit besteht eine eindeutige Zuordnung zwischen dem Zugangsknotenrechner 1 und dem zugehörigen Übergangsknotenrechner, der diese Site-Topology-Präfixe vergeben hat. In 7 kann der Übergangsknotenrechner in der dritten Spalte der Tabelle immer derselbe sein, der für die jeweilige Paarung mit einem Zugangsknotenrechner AN 1, AN 2, AN 3 folglich jeweils eine eigene definierte IPv6-Adresse erhält.
  • Da jeder Übergangsknotenrechner 3a, 3b, 3a' für jeden im Netz 2 befindlichen Zugangsknotenrechner 8a, 11 eine solche Paarung vergibt, wird das Netz in eine Vielzahl von eindeutigen Zweierbeziehungen zwischen Zugangsknotenrechnern und Übergangsknotenrechnern aufgelöst bzw. hierdurch definiert.
  • Von einem bestimmten EN erhalten die verschiedenen ANs im Public Ethernet 2 also je einen eigenen 64 Bit Access Node Prefix (siehe Tabelle). Gleichzeitig wird als Next Hop (in der Routing Tabelle) der 64 Bit Edge Node Prefix eingetragen. Diesen muss sich das Edge Node ebenfalls merken und für diesen Prefix nur Pakete akzeptieren, die vom Access Node mit dem korrespondierenden 64 Bit Access Node Prefix kommen. Die IPv6-Adressen sind zwar nicht direkt in den Datenpaketen zwischen AN und EN enthalten, aber sie sind indirekt in den MAC-Adressen enthalten. Dadurch, dass Ethernet die beiden Netzelemente verbindet, müssen aufgrund der Next Hop Einträge in den Routing-Tabellen von AN und EN die Next Hop IPv6-Adressen mittels ARP (Adressenauflösungsprotokoll, Address Resolution Protocol) aufgelöst werden. Damit sind die IPv6 Access/Edge Node Prefix Paare indirekt in den MAC-Source/Destination-Adressen enthalten. Die Netzelemente können zu diesem Zweck sich selbst logische MAC-Adressen für die verschiedenen IPv6-Adressen vergeben. Mittels dieser speziellen Adress-Vergabe ist die Kommunikation zwischen einem AN und einem EN damit eindeutig.
  • Die einzelnen Kundenanschlüsse, die an das AN angeschlossen sind, können über DHCPv6 voneinander eindeutig getrennt werden. Die Kundentrennung erfolgt über die Schnittstellen/Geräteauthentifizierung und dam darüber liegenden Authentifizierungsprotokoll. IEEE 802.1X bildet dabei nur den Kommunikationsmechanismus zwischen Kundengerät und AN. Das Authentifizierungsprotokoll sorgt dann dafür, dass der Dienst dem richtigen Kunden in Rechnung gestellt wird. ES gibt im Stand der Technik eine Vielzahl von Authentifizierungsprotokollen, die hier nicht weiter erläutert werden müssen. Je nach eingesetztem Protokoll wird die Nutzertrennung aber sehr einfach, komfortabel und sicher durchgeführt. Als Beispiel sei hier nur genannt, dass die Nutzer-Authentifizierung z.B. über das Benutzer-Login bei einem Mehrbenutzer- Betriebssystem (z.B. Windows XP) durchgeführt werden kann. Je nachdem, welcher Benutzer sich beim Betriebssystem anmeldet, wird über dieses Verfahren auch ein anderer Nutzer beim Dienstanbieter authentifiziert. Dieser Nutzer erhält dann auch die Rechnung für den Dienst. Ein Kunde authentifiziert sich mit seinem Gerät eindeutig beim AN mittels IEEE 802.1X Port Authentication. Mit dieser Authentifizierung wird auch automatisch dem Kunden ein 64 Bit Address Prefix zugeordnet. Danach wird per DHCPv6 die IPv6-Adresse vergeben. Die komplettierte IPv6-Adresse besteht aus dem 64 Bit Access Node Prefix des AN, an dem der Kundenanschluss realisiert ist, sowie einer 64 Bit Interface ID (IID), die aus der MAC-Adresse des Ports und einem 16 Bit Zusatz besteht.
  • Der Dienst, der in Anspruch genommen wird, kann ebenfalls über die IPv6-Adresse getrennt werden. Dazu kann der unveränderliche 16 Bit Zusatz im IDD-Feld genutzt werden, um die Dienste und ggf. auch verschiedenen Nutzer eines Gerätes eindeutig zu trennen.
  • Mit einem Gerät kann man 65536 verschiedene Nutzer- und Dienstekombinationen eindeutig trennen, was aus heutiger Sicht mehr als genug sein sollte. Wenn man 256 verschiedene Dienste nutzen würde, so könnten dieses Gerät 256 verschiedene Benutzer benutzen. Die Dienst- und Nutzertrennung könnte somit ausschließlich über die vergebene Adresse geprüft, authentifiziert und abgerechnet werden.
  • Um beispielsweise 256 verschiedene Benutzer, die jeweils 256 verschiedene Dienste nutzen, voneinander trennen zu können, werden als Bitmuster die Bits 65–72 der IPv6-Adresse verwendet, um die Nutzer zu trennen und als Bitmuster die Bits 73–80 zu verwenden, um deren Dienste zu trennen. Als Bits 81–128 werden die MAC-Adress-Bits des Computers eingesetzt. Im AN wird bei der Authentifizierung gleichzeitig der Bitbereich für den authentifizierten Benutzer fixiert und speziell überwacht.
  • Logt sich beispielsweise 149 im Betriebssystem ein, akzeptiert der AN nur noch diejenigen IP-Pakete von diesem Port, die im Bitbereich 65–72 den Wert 149 haben. Von diesem Gerät kann jetzt nur noch mittels 256 verschiedenen IPv6-Adressen als Source-Adresse kommuniziert werden, die zur Dienstetrennung genutzt werden können. Somit kann z.B. die VoIP-Zugangskennung entfallen, da diese IP-Adresse einem Kunden und der Nutzung von VoIP eindeutig zugeordnet ist. Würde ein anderer Nutzer, z.B. mit dem Bitmuster 173, eingeloggt und damit authentifiziert und würde er die IPv6-Adresse für VoIP vom Benutzer 149 nutzen, so würde jedes Paket mit dieser IPv6-Source-Adresse geblockt werden, da das AN einen anderen IPv6-Bereich der Bits 65–72 erwartet, nämlich 173, und diese daher als ungültig erkennt und verwirft. Die Aufteilung der 16 Bits in der IID ist wiederum flexibel einstellbar, man kann jede beliebige Nutzer-/Dienstekombination einstellen, sofern das Produkt aus Nutzer*Dienste pro Nutzer kleiner als 65536 bleibt. Bei Verwendung einer größeren oder kleineren Anzahl von Bits der IPv6-Adresse zur Nutzer-/Dienstetrennung können nahezu beliebige Anzahlen von Nutzern und/oder Diensten voneinander getrennt werden.
  • Bei diesem Verfahren authentifiziert sich jedes Gerät im Kundennetz beim AN mittels IEEE 802.1X. Zu diesem Zweck muss das Home Gateway (Gateway = Protokollumsetzer) eine 802.1X Weiterleitungsfunktion besitzen (802.1X Relay). Eine andere Möglichkeit besteht in der zentralen Authentifizierung durch das Home Gate way. Dann müssen sich die Geräte im Kundennetz jeweils beim Home Gateway authentifizieren. Dazu muss das Home Gateway eine 802.1X Proxy Server Funktion besitzen. Die Vergabe der Nutzungsrechte durch das Home Gateway könnte auch durch ein UBICOM-Verfahren erfolgen.
  • Im Fall, dass der Kunde den Computer mitnimmt (z.B. zum Nachbarn) und den dortigen Netzzugang nutzt, wird auch die Authentifizierung problemlos ablaufen, da der 64 Bit Prefix unverändert bleibt, da beide Netzzugänge (wahrscheinlich) am selben AN angeschlossen snid.
  • Wäre der Nachbar an einem anderen AN angeschlossen, würde sich die 16 Bit Site Topology der IPv6-Adresse ändern. Der Nutzer kann sich mit seinem Computer dennoch authentifizieren, da diese Prozedur über ein gesichertes Protokoll abläuft. Der Authentication Server kann bei erfolgreicher Authentifizierung die ursprüngliche 16 Bit Site Topology mit dem Nutzer und seinem Dienstprofil temporär assoziieren. Das Profil wird also temporär an eine andere Adresse gebunden (Service Binding).
  • Einzig beim Benutzen eines anderen Gerätes muss also der Nutzer eine separate Zugangskennung eingeben, um sich mit einer anderen IPv6-Adresse temporär zu assoziieren.
  • Es ist wesentlich bei der vorliegenden Erfindung, dass die Bitmuster, die zur Identifizierung der Paarungen aus Übergangsknotenrechner und Zugangsknotenrechner verwendet werden und auch die Bitmuster, die zur Dienste- und/oder Nutzertrennung verwendet werden in ihrer Länge und auch in ihrer Positionierung in nerhalb der IPv6-Adresse nicht festgelegt sind. Entscheidend ist hier, dass in Abhängigkeit von der Netzstruktur und den Bedürfnissen der jeweiligen Netzbetreiber die einzelnen Positionen der IPv6-Adresse flexibel interpretiert werden können. So ist beispielsweise auch eine Aufteilung möglich, bei der die innerhalb der IPv6-Adressen der Public Topology Prefix eine Länge von 40 Bit aufweist, der Site Topology Prefix 21 Bit, die Bitmuster zur Nutzertrennung und zur Dienstetrennung zusammen 19 Bit und sich daran die 48 Bit Ethernet-MAC-Adresse anschließt. Eine Trennung in 48 Bit Public Topology Prefix, 26 Bit Site Topology Prefix, 6 Bit für eines oder beide Bitmuster zur Nutzer- und/oder Dienstetrennung und anschließend 48 Bit Ethernet-MAC-Adresse sind ebenfalls möglich. Die Bits, die für die Bitmuster der Nutzer- und Dienstetrennung verwendet werden, können unter den beiden Bitmustern für die Dienste- und Nutzertrennung völlig flexibel aufgeteilt sein.
  • Durch die erfindungsgemäße Zuordnung von Bitmustern wird also eine hohe Flexibilität erreicht und dem Netzwerkarchitekten die Möglichkeit an die Hand gegeben, die spezifischen Gegebenheiten des jeweiligen Netzwerks bei der Aufteilung der IPv6-Adressbits auf die verschiedenen Bereiche zu berücksichtigen.

Claims (32)

  1. Verfahren zur Herstellung einer Verbindung eines Nutzergerätes mit mindestens einem mit einem Transportnetz verbundenen Rechner eines Diensteanbieters über ein Zugangsnetz mit mindestens einem Zugangsknotenrechner und über das Transportnetz mit mindestens einem Übergangsknotenrechner vom Zugangsnetz zum Transportnetz, wobei dem Nutzergerät mindestens eine IPv6-Adresse zugeordnet wird, dadurch gekennzeichnet, dass jeder Paarung aus je einem Zugangsknotenrechner und je einem Übergangsknotenrechner ein eindeutiges Paar von Bitmustern zugeordnet wird, und für die jeweilige Paarung dem Zugangsknotenrechner und dem Übergangsknotenrechner jeweils ein Topologiepräfix der IPv6-Adresse zugeordnet wird, das jeweils eines der beiden Bitmuster des Paares von Bitmustern enthält.
  2. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Bitmuster höchstens oder genau 16 Bit lang ist.
  3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die IPv6-Adresse als erste 64 Bit einen netzspezifischen Topologiepräfix, der sich aus 48 Bit eines für jedes Netzwerk spezifischen Public Topology-Präfix und 16 Bit eines Site Topology-Präfix zusammensetzt, und als letzte 64 Bit einen gerätspezifischen Schnittstellen-Identifizierer, der als letzte 48 Bit die MAC-Adresse der Schnittstelle enthält, aufweist.
  4. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Topologiepräfix das Bitmuster als Bit Nr. 49 bis Bit Nr. 64 des Site Topologie-Präfix der IPv6-Adresse enthält.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jedem Zugangsknotenrechner und/oder jedem Übergangsknotenrechner für jedes der zugeordneten Topologiepräfixe eine IPv6-Adresse zugeordnet wird.
  6. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass jeder Kombination von IPv6-Topologiepräfixen ein spezielles Ethernetlabel zugeordnet wird und im Public Ethernet bekanntgemacht wird.
  7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass mindestens einem oder jedem Zugangsknotenrechner und/oder mindestens einem oder jedem Übergangsknotenrechner für jede seiner IPv6-Adressen eine eigene MAC-Adresse zugeordnet wird.
  8. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass mindestens einem oder jedem Zugangsknotenrechner und/oder mindestens einem oder jedem Übergangsknotenrechner für jede seiner IPv6-Adressen in den letzten 48 Bit der IPv6-Adresse ein von seinen anderen IPv6-Adressen verschiedenes Bitmuster zugeordnet wird (logische MAC-Adresse).
  9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass dem Nutzerge rät seine IPv6-Adresse(n) nach Authentifizierung des Nutzers statisch und/oder dynamisch zugeordnet wird.
  10. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die zugeordnete IPv6-Adresse(n) des Nutzergeräts nur für die Dauer der Authentifizierung gültig ist/sind.
  11. Verfahren zur Herstellung einer Verbindung eines Nutzergerätes mit mindestens einem mit einem Transportnetz verbundenen Rechner eines Diensteanbieters über ein Zugangsnetz mit mindestens einem Zugangsknotenrechner und über das Transportnetz mit mindestens einem Übergangsknotenrechner vom Zugangsnetz zum Transportnetz, wobei dem Nutzergerät eine IPv6-Adresse zugeordnet wird, dadurch gekennzeichnet, dass jedem Nutzer und/oder jedem genutzten Dienst jeweils ein eindeutiges Bitmuster zugeordnet wird, und dem Nutzergerät jeweils ein Interface-Identifizierer der IPv6-Adresse zugeordnet wird, der dieses Bitmuster enthält.
  12. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Bitmuster höchs- tens oder genau 16 Bit lang ist.
  13. Verfahren nach einem der beiden vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Bitmuster ein erstes Teilbitmuster, das dem Nutzer zugeordnet ist, und/oder ein zweites Teilbitmuster, das dem genutzten Dienst zugeordnet ist, aufweist.
  14. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass je ein erstes und ein zweites Teilbitmuster vorgesehen sind, wobei beide Teilbitmuster zusammen höchstens oder genau 16 Bit lang sind.
  15. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das erste und/oder zweite Teilbitmuster höchstens oder genau 8 Bit lang sind.
  16. Verfahren nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, dass das Bitmuster Bestandteil der ersten 16 Bit des Interface-Identifizierers der IPv6-Adresse des Nutzergerätes ist.
  17. Verfahren nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, dass dem Nutzergerät seine IPv6-Adresse(n) nach Authentifizierung des Nutzers statisch und/oder dynamisch zugeordnet wird.
  18. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die zugeordnete IPv6-Adresse(n) des Nutzergeräts nur für die Dauer der Authentifizierung gültig ist.
  19. Verfahren zur Herstellung einer Verbindung eines Nutzergerätes mit mindestens einem mit einem Transportnetz verbundenen Rechner eines Diensteanbieters über ein Zugangsnetz mit mindestens einem Zugangsknotenrechner und über das Transportnetz mit mindestens einem Übergangsknotenrechner vom Zugangsnetz zum Transportnetz, wobei dem Nutzergerät eine IPv6-Adresse zugeordnet wird, dadurch gekennzeichnet, dass jeder Paarung aus je einem Zugangsknotenrechner und je einem Übergangsknotenrechner ein eindeutiges Paar von ersten Bitmustern zugeordnet wird, für die jeweilige Paarung dem Zugangsknotenrechner und dem Übergangsknotenrechner jeweils ein Topologiepräfix der IPv6-Adresse zugeordnet wird, das jeweils eines der beiden ersten Bitmuster des Paares von ersten Bitmustern enthält, und dass jedem Nutzer und/oder jedem genutzten Dienst jeweils ein zweites eindeutiges Bitmuster zugeordnet wird, und dem Nutzergerät jeweils ein Interface-Identifizierer der IPv6-Adresse zugeordnet wird, der dieses zweite Bitmuster enthält wobei sich die IPv6-Adresse des Nutzergerätes zusammensetzt aus dem Topologie-Präfix des mit dem Nutzergerät verbundenen Zugangsknotenrechners und dem dem Nutzergerät zugeordneten Interface-Identifizierer.
  20. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass mindestens eines der ersten und/oder zweiten Bitmuster höchstens oder genau 16 Bit lang ist.
  21. Verfahren nach einem der beiden vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die IPv6-Adresse als erste 64 Bit einen netzspezifischen Topologiepräfix, der sich aus 48 Bit eines für jedes Netzwerk spezifischen Public Topology-Präfix und 16 Bit eines Site Topology-Präfix zusammensetzt, und als letzte 64 Bit einen gerätspezifischen Schnittstellen-Identifizierer, der als letzte 48 Bit die MAC-Adresse der Schnittstelle enthält, aufweist.
  22. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Topologiepräfix das erste Bitmuster des Bitmusterpaares als Bit Nr. 49 bis Bit Nr. 64 des Site Topologie-Präfix der IPv6-Adresse enthält.
  23. Verfahren nach einem der Ansprüche 19 bis 22, dadurch gekennzeichnet, dass das zweite Bitmuster ein erstes Teilbitmuster, das dem Nutzer zugeordnet ist, und/oder ein zweites Teilbitmuster, das dem genutzten Dienst zugeordnet ist, aufweist.
  24. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass je ein erstes und ein zweites Teilbitmuster vorgesehen sind, wobei beide Teilbitmuster zusammen höchstens oder genau 16 Bit lang sind.
  25. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das erste und/oder zweite Teilbitmuster höchstens oder genau 8 Bit lang sind.
  26. Verfahren nach einem der Ansprüche 19 bis 25, dadurch gekennzeichnet, dass das zweite Bitmuster Bestandteil der ersten 16 Bit des Interface-Identifizierers der IPv6-Adresse des Nutzergerätes ist.
  27. Verfahren nach einem der Ansprüche 18 bis 25, dadurch gekennzeichnet, dass jedem Zugangsknotenrechner und/oder jedem Übergangsknotenrechner für jedes der zugeordneten Topologiepräfixe eine IPv6-Adresse zugeordnet wird.
  28. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass jeder Kombination von IPv6-Topologiepräfixen ein spezielles Ethernet label zugeordnet wird und im Public Ethernet bekanntgemacht wird.
  29. Verfahren nach Anspruch 27 oder 28, dadurch gekennzeichnet, dass mindestens einem oder jedem Zugangsknotenrechner und/oder mindestens einem oder jedem Übergangsknotenrechner für jede seiner IPv6-Adressen eine eigene MAC-Adresse zugeordnet wird.
  30. Verfahren nach Anspruch 27 oder 28, dadurch gekennzeichnet, dass mindestens einem oder jedem Zugangsknotenrechner und/oder mindestens einem oder jedem Übergangsknotenrechner für jede seiner IPv6-Adressen in den letzten 48 Bit der IPv6-Adresse ein von seinen anderen IPv6-Adressen verschiedenes Bitmuster zugeordnet wird (logische MAC-Adresse).
  31. Verfahren nach einem der Ansprüche 19 bis 30, dadurch gekennzeichnet, dass dem Nutzergeräte seine IPv6-Adresse(n) nach Authentifizierung des Nutzers statisch und/oder dynamisch zugeordnet wird.
  32. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die zugeordnete IPv6-Adresse(n) des Nutzergeräts nur für die Dauer der Authentifizierung gültig ist/sind.
DE102006017940A 2006-04-18 2006-04-18 Verfahren zur Herstellung einer Verbindung Expired - Fee Related DE102006017940B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102006017940A DE102006017940B4 (de) 2006-04-18 2006-04-18 Verfahren zur Herstellung einer Verbindung
PCT/EP2007/003383 WO2007121900A1 (de) 2006-04-18 2007-04-17 Verfahren zur herstellung einer verbindung mit einem diensteanbieter unter verwendung eines ipv6-topologiepräfixes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102006017940A DE102006017940B4 (de) 2006-04-18 2006-04-18 Verfahren zur Herstellung einer Verbindung

Publications (2)

Publication Number Publication Date
DE102006017940A1 true DE102006017940A1 (de) 2007-10-25
DE102006017940B4 DE102006017940B4 (de) 2009-12-17

Family

ID=38264715

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102006017940A Expired - Fee Related DE102006017940B4 (de) 2006-04-18 2006-04-18 Verfahren zur Herstellung einer Verbindung

Country Status (2)

Country Link
DE (1) DE102006017940B4 (de)
WO (1) WO2007121900A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1263171A1 (de) * 2000-03-08 2002-12-04 Hitachi, Ltd. Steuerungsgerät für paketbasierte kommunikation und steuerungsverfahren für paketbasierte kommunikation
EP1560396A2 (de) * 2004-01-29 2005-08-03 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung für die Behandlung von Authentifizierung im Netz IPv6
EP1628458A1 (de) * 2004-08-19 2006-02-22 Siemens Aktiengesellschaft Verfahren zur Vermittlung von IP-Paketen zwischen Kundennetzen und IP-Provider-Netzen über ein Zugangsnetz

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100474839C (zh) * 2004-10-12 2009-04-01 上海贝尔阿尔卡特股份有限公司 IPv6接入网中的网络服务选择和认证,及无状态自动配置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1263171A1 (de) * 2000-03-08 2002-12-04 Hitachi, Ltd. Steuerungsgerät für paketbasierte kommunikation und steuerungsverfahren für paketbasierte kommunikation
EP1560396A2 (de) * 2004-01-29 2005-08-03 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung für die Behandlung von Authentifizierung im Netz IPv6
EP1628458A1 (de) * 2004-08-19 2006-02-22 Siemens Aktiengesellschaft Verfahren zur Vermittlung von IP-Paketen zwischen Kundennetzen und IP-Provider-Netzen über ein Zugangsnetz

Also Published As

Publication number Publication date
WO2007121900A1 (de) 2007-11-01
DE102006017940B4 (de) 2009-12-17

Similar Documents

Publication Publication Date Title
DE602004012387T2 (de) System, verfahren und funktion zur ethernet-mac-adressenverwaltung
EP1779637B1 (de) Verfahren zur vermittlung von ip-paketen zwischen kundennetzen und ip-provider-netzen über ein zugangsnetz
DE10022431B4 (de) Integriertes IP-Netzwerk
DE602005000990T2 (de) Verfahren zum Austauschen von Datenpaketen
EP1743462A1 (de) Einrichtung zur session-basierten vermittlung von paketen
WO2007012559A1 (de) Netzknoteneinheit und verfahren zur weiterleitung von datenpaketen
DE102007039516A1 (de) Verfahren zum benutzerspezifischen Konfigurieren eines Kommunikationsports
DE60018913T2 (de) Verfahren und Apparat um mit Apparate zu kommunizieren die nicht zum selben virtuellen privaten Netzwerk (VPN) gehören
DE60211287T2 (de) Handhabung von Verbindungen, die zwischen Firewalls umziehen
DE602004002950T2 (de) Verfahren und Vorrichtung zur Zugriffssteuerung
WO2007147424A1 (de) Vorrichtung und verfahren zum adress-mapping
DE102006017940B4 (de) Verfahren zur Herstellung einer Verbindung
EP1378108B1 (de) Verfahren zur durchführung von überwachungsmassnahmen und auskunftsersuchen in telekommunikations - und datennetzen
EP1525714B1 (de) Konfiguration eines auf einem breitband kabelverteilnetz beruhenden telefoniezugangsnetzes und einer zugehörigen paketbasierten vermittliungsstelle
DE60202663T2 (de) System und Verfahren zum Zuteilen dynamischer IP-Adressen
EP1699181A1 (de) Verfahren und System zur automatisierten Konfiguration eines Subnetzwerks innerhalb eines Netzwerkes
EP1274198B1 (de) Verfahren und Anordnung zur Konfiguration eines Kommunikationsverbundes
WO2006081877A1 (de) Verfahren zum routen von internetverbindungen über netzübergänge
EP2067308B1 (de) Verfahren zur authentifizierung eines dsl-nutzers
DE102007030775B3 (de) Verfahren zum Filtern von Netzwerkdiensten und Netzwerkdiensteinhalten
DE10061128A1 (de) Verfahren zur Durchführung von Überwachungsmaßnahmen in Telekommunikation- und Datennetzen mit beispielsweise IP-Protokoll (Internet Protokoll)
DE602005000593T2 (de) Verfahren zur Konfiguration einer DSL-Verbindung in welcher eine Home-IP-Plug-Steuerung aktiviert ist, um eine Kommunikation mit einem Home-IP-Plug einzuleiten
AT406320B (de) Verfahren zur datenübertragung
DE102007046561A1 (de) Verfahren zur Auswahl von Dienstgüteklassen in Verbindungen zwischen Endgeräten und einem Internet Gateway
DE10244710A1 (de) Verfahren zur Protokollauswahl für eine Übermittlung von Datennpaketen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee