DE19809824A1 - Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des Verfahrens - Google Patents
Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des VerfahrensInfo
- Publication number
- DE19809824A1 DE19809824A1 DE19809824A DE19809824A DE19809824A1 DE 19809824 A1 DE19809824 A1 DE 19809824A1 DE 19809824 A DE19809824 A DE 19809824A DE 19809824 A DE19809824 A DE 19809824A DE 19809824 A1 DE19809824 A1 DE 19809824A1
- Authority
- DE
- Germany
- Prior art keywords
- vpn
- address
- data packet
- network
- vpns
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Description
Die Erfindung betrifft ein Verfahren zum Betreiben von virtuellen privaten Netzen auf
einem gemeinsamen Datenpaketvermittlungsnetz und eine Vorrichtung zum
Durchführen des Verfahrens.
Bekannt ist die Verwendung eines Intranets für die interne Kommunikation in einem
Unternehmen. Der Begriff Intranet wird uneinheitlich verwendet und reicht von der
Netzwerkebene (OSI-Schicht 3) bis zu höheren Ebenen. Teilnehmer des Intranet
können über das Intranet eines Unternehmens mit anderen Teilnehmern des Intranets
unternehmensintern kommunizieren. Ferner ist eine Kommunikation mit außerhalb
des Intranets befindlichen Teilnehmern über nach außengehende Anschlüsse des
Intranets, wie beispielsweise Internet-Anschlüsse, möglich. Da unternehmensinterne
Daten in der Regel vor unbefugtem Zugriff geschützt werden sollen, werden
zumindest sicherheitsrelevante Daten eines Unternehmens in der Regel nicht über
das Internet übertragen und das unternehmensinterne Intranet wird durch
Schutzmechanismen vom öffentlichen Internet getrennt. Die Vermittlung von
Datenpaketen über ein firmeninternes Datenpaketvermittlungs-Intranet erfolgt auf der
OSI-Protokoll-Schicht 3 in Netzwerkknoten (routern). Bei größeren Netzen werden
mehrere Vermittlungsebenen verwendet, wobei die oberen Vermittlungsebenen mit
leistungsfähigen Vermittlungssystemen (routern) und Leistungsbandbreiten
ausgestattet sind, um eine Bündelung von Datenverkehr über sie zu ermöglichen.
Dienste (Services) werden bei einem in ein öffentliches Telekommunikationsnetz
abgeschirmt eingebundenen Intranet eines Unternehmens gegen Zugriffe aus einem
anderen Netz (insbesondere Internet) abgeschirmt realisiert; derartige Dienste sind
beispielsweise Name-Server, Mail, WWW, Firewall etc.
Ein derartiges Intranet zu realisieren ist relativ aufwendig. Aufgabe der vorliegenden
Erfindung ist eine möglichst universelle, kostengünstige, gegen externe Zugriffe
gesicherte Intranet-Realisierung. Die Aufgabe wird durch die Gegenstände der
unabhängigen Ansprüche gelöst.
Erfindungsgemäß wird für einen Teilnehmer (der mehrere räumlich getrennte
Einzelteilnehmer (Einzelrechner und/oder LANS) umfaßt), beispielsweise einen
Teilnehmer wie ein Unternehmen mit mehreren räumlich getrennten Niederlassungen,
ein Intranet für die räumlich getrennten Einzelteilnehmer des Teilnehmers realisiert
durch ein virtuelles privates Netz für den Teilnehmer auf einem gemeinsamen
Datenpaketvermittlungsnetz (wie beispielsweise Datenvermittlung über ein
öffentliches Telefonnetz eines oder mehrerer Betreiber, dem Internet, oder beiden) für
mehrere Teilnehmer.
Dabei wird dem virtuellen privaten Netz eines Teilnehmers (wie beispielweise einer
Firma mit mehreren räumlich getrennten Niederlassungen) ein Teiladressraum des
vorgegebenen, homogenen Gesamtadressraumes des Datenpaketvermittlungsnetzes
zugewiesen. Das virtuelle private Netz eines Teilnehmers ist dabei von den virtuellen
privaten Netzen anderer Teilnehmer des Datenpaketvermittlungsnetzes getrennt.
Hierzu wird in der Adresse jedes Einzelteilnehmers innerhalb eines virtuellen privaten
Netzes ein bestimmter Bereich für eine VPN-ID (Identifizierungs-Bitsequenz für dieses
virtuelle private Netz VPN) festgelegt. Die VPN-ID eines virtuellen privaten Netzes ist
für jeden Einzelteilnehmer innerhalb des virtuellen privaten Netzes (auch an räumlich
getrennten Orten) identisch. Das Trennen der virtuellen privaten Netze erfolgt
aufgrund der Filterung von Datenpaketen und von Routing-Informationen anhand der
VPN-ID-Bits. Die VPN-Trennung erfolgt dabei auf der OSI Network-Schicht 3 (Layer
3-VPN).
Dabei sind die virtuellen privaten Netze einzelner Teilnehmer derart getrennt, daß
wenn ein Teilnehmer eines virtuellen privaten Netzes ein Datenpaket mit einer
Zieladresse absendet, in welcher die ID seines virtuellen privaten Netzes enthalten ist,
das Datenpaket innerhalb des virtuellen privaten Netzes bleibt. Jedoch können aus
einem virtuellen privaten Netz Tore nach draußen, also zum Internet, zu anderen
virtuellen privaten Netzen etc. eingerichtet sein.
Erfindungsgemäß ist es möglich, zentralen Dienste für ein virtuelles privates Netz
getrennt von zentralen Diensten eines anderen virtuellen privaten Netzes
einzurichten, diese Prozesse jedoch dabei für unterschiedliche virtuelle private Netze
auf gemeinsamen Einrichtungen (aber getrennt) laufen zu lassen. Beispielsweise
können Name-Server zweier virtueller privater Netze in einer gemeinsamen
Vorrichtung realisiert sein, jedoch dabei als getrennte, gegenseitig nicht sichtbare
Prozesse ablaufen. Dann ist es möglich, einen zentralen Dispatcher-Prozeß zu
implementieren, der Dienstanfragen aus unterschiedlichen VPNs aufgrund der
VPN-ID jeweils einem VPN-spezifischen Serviceprozeß zuordnet. Einzelteilnehmer im
Sinne der Anmeldung ist insbesondere jedes LAN etc. Teilnehmer im Sinne der
Anmeldung ist eine Einzelteilnehmergruppe, z. B. ein Unternehmen etc.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der nachfolgenden
Beschreibung eines Ausführungsbeispiels anhand der Zeichnung. Dabei zeigt
Fig. 1 die Übermittlung von Daten zwischen einer Niederlassung Lokation 1
(= LOC1) und einer Niederlassung Lokation 2 (=LOC2) eines
Teilnehmers des Datenpaketvermittlungsnetzes durch ein virtuelles
privates Netz, realisiert für verschiedene VPNs (VPN-A und VPN-B) auf
einem gemeinsamen OSl-Schicht-3-Datenpaketvermittlungsnetz (Arcor
IP Backbone), wobei die Trennung der VPNs erfolgt durch Filterung von
Datenpaketen und Routing-Informationen an den Zugangspunkten zum
Backbone-Netz (Network Access Point),
Fig. 2 den Aufbau einer Datenpaketvermittlungsnetz-Adresse,
Fig. 3 den räumlich integrierten, funktionell getrennten Aufbau gemeinsamer
zentraler Dienste für die virtuellen privaten Netze eines
Datenpaketvermittlungsnetzes am Beispiel der Domain-Name-Services.
Fig. 1 zeigt ein erfindungsgemäßes Paketvermittlungsnetz 1 mit zwei virtuellen
privaten Netzen VPN A, VPN B. Ein virtuelles privates Netz VPN A umfaßt alle
lokalen Einzelteilnehmer und lokalen Netze 2, 3 und 4; das virtuelle Netz VPN B
umfaßt und verbindet alle räumlich getrennten lokalen Netze 5, 6 und 7.
Die Zugänge von lokalen Netzen 2 bis 7 zum Datenpaketvermittlungsnetz 1 sind
jeweils durch Kreise (= Network Access Point) am Rande des
Datenpaketvermittlungsnetzes 1 dargestellt. Datenpakete, welche über das
Datenpaketvermittlungsnetz laufen, sind entlang Verbindungen zwischen den
Lokalnetzen und dem Paketvermittlungsnetz jeweils als Rechtecke dargestellt, wobei
hier beispielhaft der Weg für die Datenpakete 8 (VPN-A) vom lokalen Netz VPN-A-
Loc1 (= 2) zum lokalen Netz VPN-A-Loc2 (= 3) und 9 (VPN-B) von 5 nach 6
dargestellt ist.
Die Bezeichnung erfindungsgemäßer VPNs als Layer-3-VPN bedeutet lediglich, daß
auf der OSI-Schicht 3 (network layer) = L3 eine Trennung von VPNs aufgrund von
Filterung von Datenpaketen und Routing-Informationen mit den VPN-Bits einer
Adresse eines Paketes erfolgt.
Dabei ist die Vernetzung der Niederlassungen (2-4) des ersten Teilnehmers A und die
Vernetzung der Niederlassungen (5-7) des zweiten Teilnehmers B über ein
gemeinsames Datenpaketvermittlungsnetz 1 realisiert, wobei jedoch eine virtuelle
Trennung der Netze der beiden Teilnehmer hinsichtlich der Weitervermittlung und der
Inanspruchnahmeberechtigung für Dienste etc. dadurch realisiert ist, daß im
gesamten Datenpaketvermittlungsnetz für den ersten Teilnehmer ein virtuelles
privates Netz VPN A und für den zweiten Teilnehmer ein virtuelles privates Netz VPN
B geschaffen wird.
Im vorliegenden Fall sind nur zwei virtuelle Netze VPN A und VPN B für je einen
Teilnehmer auf dem Datenpaketvermittlungsnetz 1 realisiert; jedoch ist auch die
Realisierung virtueller privater Netze für mehr als zwei Teilnehmer möglich.
Das Datenpaketvermittlungsnetz 1 ist in L3-VPNs aufgegliedert, also in virtuelle
private Netze auf der Schicht 3 des OSI-Referenzmodells.
Die Trennung der virtuellen privaten Netze VPN A des ersten Teilnehmers und VPN B
des zweiten Teilnehmers erfolgt durch Zuordnung disjunkter (nicht überlappender)
Teiladreßräume des vorgegebenen Gesamtadreßraums (des Datenpaketvermittlungs
netzes 1) zu den Teilnehmern des Datenpaketvermittlungsnetzes. Dem virtuellen
privaten Netz VPN A des ersten Teilnehmers ist somit ein Teiladreßraum des
Gesamtadreßraumes des Datenpaketvermittlungsnetzes 11 zugeordnet; dem
virtuellen privaten Netz VPN B des zweiten Teilnehmers ist ein den ersten
Teiladreßraum nicht überlappender Teiladreßraum des Gesamtadreßraumes
zugeordnet.
Die VPN-Trennung ist auf der Schicht 3 des OSI-Referenzmodells (=OSI-Layer 3 =
OSI-L3) realisiert, also auf der Netzwerkschicht. Zur Trennung der virtuellen Netze A
und B erfolgt eine Filterung von Datenpaketen und Routing-Informationen anhand der
VPN-ID. Die VPN-ID ist in einem Header eines Paketes enthalten, welches zwischen
zwei räumlich getrennten lokalen Netzen 2, 3 eines virtuellen privaten Netzes A
übermittelt wird. Die Weiterübermittlung eines Paketes 8 auf dem Weg von einem Ort
2 eines virtuellen Netzes VPN A zu einem anderen Ort 3 des virtuellen Netzes VPN A
erfolgt im Datenpaketvermittlungsnetz 1 über Router 10, 11, 15, 17, 21 (oder alternativ
beispielsweise über 10, 11, 14, 17, 21).
Die Trennung der virtuellen privaten Netze VPN A und VPN B voneinander kann in
unterschiedlicher Weise konkret ausgestaltet werden. So ist es möglich, daß von
Einzelteilnehmern eines virtuellen privaten Netzes VPN A ebenso wie von Einzel-
Teilnehmern eines anderen virtuellen privaten Netzes VPN B auf einen teilweise
gemeinsamen Adreßraum (common adress space) zugegriffen werden kann, der für
alle Einzelteilnehmer dieser beiden virtuellen privaten Netze VPN A und VPN B
sichtbar ist. In diesem gemeinsamen Adreßraum kann kostensparend eine
gemeinsame Infrastruktur für zentrale Dienste für beide virtuelle private Netze VPN A
und VPN B realisiert werden. Dabei kann die gemeinsame Infrastruktur hinsichtlich
Zugriffsberechtigungen auf Prozesse und/oder Daten für die beiden virtuellen privaten
Netze VPN A und VPN B dennoch strikt getrennt sein.
Beispielsweise ist es möglich, für zwei oder mehr virtuelle private Netze A, B einen
gemeinsamen Name-Server zu implementieren, auf welchem jedoch für die virtuellen
privaten Netze VPN A und VPN B ganz oder teilweise getrennte Prozesse ablaufen.
Beispielsweise können aus dem virtuellen Netz VPN A andere Adressen sichtbar sein
als aus dem virtuellen Netz VPN B.
Bei der Übermittlung von einem Einzelteilnehmer über das
Datenpaketvermittlungsnetz zu einem anderen Einzelteilnehmer erfolgt das Routing
insbesondere hinsichtlich deren VPN-Bits ihres VPNs zwischen dem Dristribution-
Layer und dem Access-Layer. Die Kontrolle der Routing-Informationen und Paketfilter
erfolgt durch zentrales Konfigurationsmanagement automatisch mit einer Datenbank-
Applikation.
Die Filterung von Routinginformationen erfolgt mittels Route-Maps und Distribute-Lists
auf den entsprechenden Interfaces der Distribution Layer-Router oder Point of
Presence-Router oder lokalen Zugängen zum Datenpaketvermittlungsnetz für
Einzelteilnehmer bzw. lokale LANs. Insbesondere hochfrequentierte
Vermittlungsstellen sind mit leistungsstarken Routern ausgestattet. Auf den Zugängen
des Datenpaketvermittlungsnetzes ist keine Default-Route in der Routingtabelle
eingetragen für Pakete mit unbekannter Adresse.
Fig. 2 verdeutlicht die Aufteilung des Gesamtadreßraumes eines
Datenpaketvermittlungsnetzes mit einer Adreßlänge von 20 bit (IETF-Class A
10.0.0.0) in Teiladreßräume für virtuelle private Netze VPN1 bis VPN5 sowie weiteren
Teiladreßraum. Der Aufbau einer Datenpaketvermittlungsadresse, bestehend aus
Netzwerk-Teil (NET-ID), VPN-Teil (VPN-ID) und Subnetzen und Hosts, wird am
Beispiel der IP-Adressierung dargestellt. Das Beispiel enthält einen 4-Bit Regional-
Routing-Anteil, der für alle VPNs gleich aufgeteilt ist. Der verbleibende 20-Bit-
Adressraum wird mit der VPN-ID in disjunkte Teiladressräume aufgeteilt. Das Beispiel
zeigt 4 VPNs mit unterschiedlicher VPN-ID-Länge mit der zugehörigen Anzahl
möglicher Hostadressen.
In Fig. 2 oben ist eine Aufgliederung der IP-Adresse in eine Netzwerkkennung 10 (=
IETF-Class A 10.0.0.0), Regionale-Routing-Bits (hier 4 bits), VPN-Bits und
Einzelteilnehmer-Bits (bzw. EinzeIteilnehmer-Host-Bits) dargestellt. Der Beginn der
VPN-ID innerhalb der Adressen eines Datenpaketvermittlungsnetzes ist fest. Die
Länge der VPN-ID kann fest oder variabel sein. Bei langer VPN-ID sind relativ wenige
Bits für Einzelnehmer (bzw. deren Hosts) übrig, während bei einer kurzen VPN-ID
relativ viele Bits für die Einzelteilnehmer-ID bzw. die Einzelteilnehmer-Host-ID
übrigbleiben. Beispielsweise sind 16 Bits VPN-ID und vier Bits Host-ID möglich oder
12 Bits VPN-ID und 8 Bits Host-ID oder vier Bits VPN-ID und 16 Bits Host-ID. Statt der
Host-ID kann auch eine Subnet-ID vorgesehen werden. Die VPN-ID steht vor der
Host-ID oder Subnet-ID.
Ferner ist in Fig. 2 dargestellt, wie groß der Adreßraum (für die Host-ID) in
Abhängigkeit von der Länge der VPN-ID ist. Dabei sind links in Fig. 2 von oben nach
unten 20 Adreß-Bits (für VPN-ID + Host-ID) dargestellt. Der linke Rand der Pyramide
entspricht jeweils im n-ten (n=1. .20) Bit einer "0", der rechte Rand einer "1". Bei einer
langen VPN-ID, also einem VPN-Adreßraum, der in Fig. 4 relativ weit unten beginnt,
ist der Adreßraum des VPN klein. Bei einer kurzen VPN-ID, also einem
VPN-Adreßraum, der (für die Einzel-Teilnehmer-Host-Adresse) in Fig. relativ weit oben
beginnt, existieren relativ viele mögliche Einzel-Teilnehmer-Adressen in diesem VPN.
Für das virtuelle Netz VPN1 beträgt die VPN-ID-Länge 4 Bits und damit der Teil-
Adreßraum 16 Bits für die Host-ID, jeweils in den 16 Regionen. Für das kleinere
virtuelle private Netz VPN2 beträgt die VPN-ID-Länge 6 Bit und damit der Teil-
Adreßraum für die Host-ID 14 Bits in den Regionen. Für das noch kleinere VPN 3
beträgt die Länge der VPN-ID 12 Bits und damit die Länge der Host-ID 8 Bits, also ein
8-Bit-Adreßraum innerhalb des virtuellen privaten Netzes 3. Wie Fig. 4 zeigt, steht
bei einer kurzen VPN-ID für das VPN ein großer Adreßraum zur Verfügung.
Die Authorisierung eines VPNs (bzw. jedes Einzelteilnehmers eines Lokalnetzes
dieses VPNs) für bestimmte zentrale Dienste kann aufgrund der VPN-ID in der
Absenderadresse eines Einzel-Teilnehmers geprüft werden. Die Absenderadresse
des Einzelteilnehmers eines VPNs, welch er einen bestimmten zentralen Dienst im
Datenpaketvermittlungsnetz in Anspruch nehmen möchte, wird als Absenderadresse
mit der Dienstinanspruchnahme-Anfrage an den zentralen Dienst übertragen und
kann so überprüft werden.
Ferner ist es insbesondere möglich, als zentralen Dienst einen Dispatcher-Prozeß für
ein virtuelles privates Netzwerk im Datenpaketvermittlungsnetz zu realisieren, welcher
Dienstanfragen aus dem virtuellen privaten Netz anhand der VPN-ID VPN-
spezifischen Service-Prozessen zuordnet.
Ein Domain-Name-Server-Dispatcher-Prozeß (33) kann eine Domain-Name-Service-
Anfrage (DNS-Anfrage) anhand der VPN-ID des Absenders der Abfrage einem
VPN-spezifischen Name-Server-Prozeß (34, 35) zuordnen. Dieser Ablauf ist in Abbildung
Fig. 3 dargestellt. Die Prozesse können auf einer gemeinsamen Infrastruktur
implementiert werden. Der named VPNB Prozeß (34) wird dem VPNB (30)
zugeordnet und entsprechend der named VPNA Prozeß (35) dem VPNA (31).
Claims (7)
1. Verfahren zum Betreiben von virtuellen privaten Netzen des Layers 3 (= VPN A,
VPN B) auf einem gemeinsamen Datenpaketvermittlungsnetz (OSI-L3-
Datenpaketvermittlungsnetz 1),
wobei eine logische Trennung dieser Layer-3-VPNs (=VPNA, VPNB) voneinander durch Zuordnung disjunkter Teiladressräume eines vorgegebenen, homogenen Gesamtadressraums zu diesen L-3-VPNs erfolgt,
wobei einem L-3-VPN jeweils eine bestimme VPN-ID zugeordnet ist, die zur Kennzeichnung des disjunkten Teiladressraums des L-3-VPNs dient und die Teil der Adresse jedes Einzelteilnehmers des L-3-VPNs ist,
wobei eine ein L3-VPN kennzeichnende VPN-ID an einer festen Bitposition in einer Einzelteilnehmeradresse eines Einzelteilnehmers des L3-VPNs beginnt und variable oder feste Länge aufweist,
wobei die Realisierung der L3-VPNs-Trennung durch Filterung von Datenpaketen und Routing-Informationen in Routern des Datenpaketvermittlungsnetzes anhand der VPN-ID erfolgt.
wobei eine logische Trennung dieser Layer-3-VPNs (=VPNA, VPNB) voneinander durch Zuordnung disjunkter Teiladressräume eines vorgegebenen, homogenen Gesamtadressraums zu diesen L-3-VPNs erfolgt,
wobei einem L-3-VPN jeweils eine bestimme VPN-ID zugeordnet ist, die zur Kennzeichnung des disjunkten Teiladressraums des L-3-VPNs dient und die Teil der Adresse jedes Einzelteilnehmers des L-3-VPNs ist,
wobei eine ein L3-VPN kennzeichnende VPN-ID an einer festen Bitposition in einer Einzelteilnehmeradresse eines Einzelteilnehmers des L3-VPNs beginnt und variable oder feste Länge aufweist,
wobei die Realisierung der L3-VPNs-Trennung durch Filterung von Datenpaketen und Routing-Informationen in Routern des Datenpaketvermittlungsnetzes anhand der VPN-ID erfolgt.
2. Verfahren nach Anspruch 1,
gekennzeichnet durch eine
gemeinsame Nutzung einer Infrastruktur für zentrale Dienste, auf die
Einzelteilnehmer aller oder mehrerer L3-VPNs durch Sichtbarmachen eines
gemeinsamen Adressraums (common adress space) für alle oder mehrere
VPNs zugreifen können.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet,
daß die Prüfung der Authorisierung eines Einzelteilnehmers eines L3-VPNs für
bestimmte zentrale Dienste und die Trennung dieser Dienste für verschiedene
L3-VPNs anhand der VPN-ID in der Absenderadresse des Einzelteilnehmers
und der Zieladresse des zentralen Dienstes gewährleistet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet,
daß ein OSI-, IPv4-, IPv6 oder IPX-Protokoll im Datenpaketvermittlungsnetz
(19) verwendet wird.
5. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß ein zentraler Dienst implementiert wird, in dem ein Prozeß (Dispatcher-
Prozeß) Dienstanfragen anhand der VPN-ID VPN-spezifischen
Serviceprozessen zuordnet.
6. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß ein Domain-Name-Server-Dispatcher-Prozeß eine DNS-Anfrage (Domain
Name-Service-Anfrage) anhand der VPN-ID des Absenders den
VPN-spezifischen Name-Server-Prozessen zuordnet.
7. Vorrichtung zum Durchführen des Verfahrens nach einem der vorhergehenden
Ansprüche oder nach Teilmerkmalen mindestens eines der vorhergehenden
Ansprüche.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19809824A DE19809824C2 (de) | 1997-03-12 | 1998-02-27 | Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des Verfahrens |
FR9802956A FR2761843B1 (fr) | 1997-03-12 | 1998-03-11 | Procede d'exploitation de reseaux virtuels prives dans un reseau commun de commutation de paquets de donnees et dispositif pour la mise en oeuvre de ce procede |
US09/041,292 US6438127B1 (en) | 1997-03-12 | 1998-03-12 | Process and apparatus for the operation of virtual private networks on a common data packet communication network |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19711977 | 1997-03-12 | ||
DE19809824A DE19809824C2 (de) | 1997-03-12 | 1998-02-27 | Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des Verfahrens |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19809824A1 true DE19809824A1 (de) | 1998-09-17 |
DE19809824C2 DE19809824C2 (de) | 2003-01-16 |
Family
ID=7824223
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19809824A Expired - Fee Related DE19809824C2 (de) | 1997-03-12 | 1998-02-27 | Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des Verfahrens |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE19809824C2 (de) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10111036A1 (de) * | 2001-03-07 | 2002-09-12 | Gloocorp Ag | Übergreifendes Authentifizierungskonzept für Teilnehmer in öffentlichen Telefonnetzen und dem Internet |
EP1298853A1 (de) * | 2000-06-16 | 2003-04-02 | Fujitsu Limited | Kommunikationsgerät mit vpn-ermöglichungsfunktion |
WO2018036659A1 (de) * | 2016-08-26 | 2018-03-01 | Telefónica Germany GmbH & Co. OHG | Endanwenderspezifisches virtuelles globales netzwerk |
EP2260402B1 (de) * | 2008-03-31 | 2020-05-06 | Amazon Technologies, Inc. | Konfiguration der kommunikation zwischen rechenknoten |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9217059D0 (en) * | 1992-08-12 | 1992-09-23 | Plessey Telecomm | Atm network addressing |
US5416842A (en) * | 1994-06-10 | 1995-05-16 | Sun Microsystems, Inc. | Method and apparatus for key-management scheme for use with internet protocols at site firewalls |
US5802320A (en) * | 1995-05-18 | 1998-09-01 | Sun Microsystems, Inc. | System for packet filtering of data packets at a computer network interface |
-
1998
- 1998-02-27 DE DE19809824A patent/DE19809824C2/de not_active Expired - Fee Related
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2375644A1 (de) * | 2000-06-16 | 2011-10-12 | Fujitsu Limited | Kommunikationsvorrichtung mit VPN-Akkomodationsfunktion |
US8423669B2 (en) | 2000-06-16 | 2013-04-16 | Fujitsu Limited | Communication device having VPN accommodation function |
EP1298853A4 (de) * | 2000-06-16 | 2003-08-13 | Fujitsu Ltd | Kommunikationsgerät mit vpn-ermöglichungsfunktion |
EP1758311A1 (de) * | 2000-06-16 | 2007-02-28 | Fujitsu Limited | Kommunikationsgerät mit VPN-Ermöglichungsfunktion |
EP2276204A1 (de) * | 2000-06-16 | 2011-01-19 | Fujitsu Limited | Kommunikationsvorrichtung mit VPN-Akkomodationsfunktion |
EP2288083A1 (de) * | 2000-06-16 | 2011-02-23 | Fujitsu Limited | Kommunikationsvorrichtung mit VPN-Akkomodationsfunktion |
EP1298853A1 (de) * | 2000-06-16 | 2003-04-02 | Fujitsu Limited | Kommunikationsgerät mit vpn-ermöglichungsfunktion |
EP2375643A1 (de) * | 2000-06-16 | 2011-10-12 | Fujitsu Limited | Kommunikationsgerät mit VPN-Ermöglichungsfunktion |
US9413657B2 (en) | 2000-06-16 | 2016-08-09 | Fujitsu Limited | Communication device having VPN accommodation function |
US8489767B2 (en) | 2000-06-16 | 2013-07-16 | Fujitsu Limited | Communication device having VPN accommodation function |
EP2858309A1 (de) * | 2000-06-16 | 2015-04-08 | Fujitsu Limited | Kommunikationsvorrichtung mit VPN-Akkomodationsfunktion |
DE10111036A1 (de) * | 2001-03-07 | 2002-09-12 | Gloocorp Ag | Übergreifendes Authentifizierungskonzept für Teilnehmer in öffentlichen Telefonnetzen und dem Internet |
EP2260402B1 (de) * | 2008-03-31 | 2020-05-06 | Amazon Technologies, Inc. | Konfiguration der kommunikation zwischen rechenknoten |
WO2018036659A1 (de) * | 2016-08-26 | 2018-03-01 | Telefónica Germany GmbH & Co. OHG | Endanwenderspezifisches virtuelles globales netzwerk |
DE102016010359B4 (de) | 2016-08-26 | 2023-08-17 | Telefónica Germany GmbH & Co. OHG | Endanwenderspezifisches virtuelles globales Netzwerk |
Also Published As
Publication number | Publication date |
---|---|
DE19809824C2 (de) | 2003-01-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6438127B1 (en) | Process and apparatus for the operation of virtual private networks on a common data packet communication network | |
DE69837691T2 (de) | Lastverteilung zwischen Servern in einem TCP/IP-Netz | |
DE69734019T2 (de) | Verfahren und vorrichtung für dynamische paketfilterzuweisung | |
DE69720351T2 (de) | Verfahren und Vorrichtung zum Begrenzen des Zugriffes an privater Information in Domänennamensystemen durch Umleitung von Abfrageanforderungen | |
DE10022431B4 (de) | Integriertes IP-Netzwerk | |
DE60311297T2 (de) | Gemeinsame port adressenumsetzung in einem router der als nat & nat-pt gateway agiert | |
DE69727447T2 (de) | Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung | |
DE69727930T2 (de) | Zusammenfassung von verbindungen in vermittlungskommunikationsnetzen | |
EP1779637B1 (de) | Verfahren zur vermittlung von ip-paketen zwischen kundennetzen und ip-provider-netzen über ein zugangsnetz | |
DE69827201T2 (de) | Verfahren und system zur server-netzwerkvermittlung-mehrverbindung | |
DE19740547B4 (de) | Vorrichtung und Verfahren zum Sicherstellen sicherer Kommunikation zwischen einer anfordernden Entität und einer bedienenden Entität | |
DE69933417T2 (de) | Vorrichtung und Verfahren zur routerfreien Schicht 3 Wegelenkung in einem Netz | |
DE602004011219T2 (de) | Anordnung und verfahren zur behandlung von geteilten diensten durch eine adressenumsetzung mit weiterleitung von virtual routes | |
DE60212289T2 (de) | Verwaltung privater virtueller Netze (VPN) | |
DE60121755T2 (de) | Ipsec-verarbeitung | |
DE602005000990T2 (de) | Verfahren zum Austauschen von Datenpaketen | |
DE19741239A1 (de) | Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren | |
DE60018913T2 (de) | Verfahren und Apparat um mit Apparate zu kommunizieren die nicht zum selben virtuellen privaten Netzwerk (VPN) gehören | |
DE10305413B4 (de) | Verfahren und Anordnung zur transparenten Vermittlung des Datenverkehrs zwischen Datenverarbeitungseinrichtungen sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium | |
DE19809824C2 (de) | Verfahren zum Betreiben von virtuellen privaten Netzen auf einem gemeinsamen Datenpaketvermittlungsnetz und Vorrichtung zum Durchführen des Verfahrens | |
DE60316158T2 (de) | Filter zur verkehrstrennung | |
WO2007147424A1 (de) | Vorrichtung und verfahren zum adress-mapping | |
DE69932535T2 (de) | Adressierungsverfahren und namen- und adressen- server in einem digitalen netz | |
DE69734179T2 (de) | Verfahren und Vorrichtung zum Begrenzen des Zugriffs auf private Information in Domain Name Systemen durch Informationsfilterung | |
DE69921776T2 (de) | Mobiles IP mit Dienstqualität für fremdes Netz mit fremdem Agent und mehreren mobilen Knoten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8125 | Change of the main classification |
Ipc: H04L 12/56 |
|
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee | ||
R079 | Amendment of ipc main class |
Free format text: PREVIOUS MAIN CLASS: H04L0012560000 Ipc: H04L0012749000 |