DE602004007301T2

DE602004007301T2 - Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten

Info

Publication number: DE602004007301T2
Application number: DE602004007301T
Authority: DE
Inventors: Patrik Salmela; Jorma Wall; Petri Jokela
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2004-02-13
Filing date: 2004-02-13
Publication date: 2008-02-28
Anticipated expiration: 2024-02-14
Also published as: WO2005081466A1; JP2007522744A; CN1938999A; ES2287697T3; US20070274312A1; EP1714434B1; US7827313B2; EP1714434A1; JP4579934B2; CN1938999B; DE602004007301D1; ATE366017T1

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Verfahren für ein mindestens teilweises Sicherstellen von Kommunikationsvorgängen zwischen einem Host, der nicht HIP-fähig ist und einem anderen Host, der HIP-fähig ist. Die vorliegende Erfindung betrifft auch ein Kommunikationssystem und ein HIP-Proxy, die solch ein Verfahren verwenden.
2. Beschreibung der verwandten Technik
Als die Erfindung ursprünglich entwickelt wurde, waren Hosts fest an einem Ort, und es gab ein implizites Vertrauen zwischen den Benutzern, trotz dem Mangel an reeller Sicherheit oder Host-Identifizierungsprotokollen, und diese Situation ist so weiter gegangen, selbst bei einer größeren Aufnahme und Verwendung der Technologie. Es gab wenig Bedarf, Techniken zu betrachten zum Handhaben einer Host-Mobilität, da Computer relativ groß und unbeweglich waren.
Mit der Revolution in der Telekommunikation und Computerindustrie in den frühen 1990-igern wurden kleinere Kommunikationsgeräte und Computer in größerem Ausmaß verfügbar, und die Erfindung des World Wide Web und alle die Dienste, die mit ihm aufgekommen sind, habe das Internet attraktiv für die durchschnittliche Person gemacht. Die Kombination eines Erhöhens in der Verwendung des Netzwerks und von Mobiltelekommunikationsvorgängen erzeugte den Bedarf für eine sichere Mobilitätsverwaltung in dem Internet.
Die sich erhöhende Anzahl der involvierten Parteien und die Zahlungstransaktionen, die für gewisse Dienste benötigt wurden, erzeugte auch einen Bedarf für eine zusätzliche Anwendungsniveausicherheit. Gegenwärtig laufen die am verbreitetesten verwendeten Verschlüsselungsprotokolle, beispielsweise SSL/TLS, innerhalb der oberen Netzwerkschichten, beispielsweise der TCP.
Unter Betrachtung der obigen Mobilitätsverwaltung und Sicherheitserfordernisse wurde der Mobil-IP-Standard (C. Perkins, "IP Mobility Support for IPv4", RFC 3220, IETF, 2002) und der Mobile IPv6-Standard (D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", Internet Draft, work in Progress, draft-ietf-mobileip-ipv6-24.txt, IETF, 2003) eingeführt. Zusammen wurde es geplant, dass diese Spezifizierungen eine Mobilitätsunterstützung für die nächste Generation Internet bereitstellen. Eine Sicherheitsarbeit entwickelt sich in der Form von IPsec, und verwandten Aktivitäten, wie zum Beispiel verschiedenen Schlüsselaustauschprotokollen, mit dem Ziel, in der Lage zu sein, eine Sicherheit in der IP-Schicht bereitzustellen. Jedoch hat die Erfahrung gezeigt, dass es ziemlich schwer ist, eine kombinierte Sicherheit und Mobilität zu erreichen, unter Verwendung der gegenwärtigen Standards.
Eine IP-Adresse beschreibt einen topologischen Ort eines Knotens in dem Netzwerk. Die IP-Adresse wird verwendet zum Leiten bzw. Routen des Pakets von dem Quellenknoten an das Ziel. Zur gleichen Zeit wird die IP-Adresse auch verwendet zum Identifizieren des Knotens, bereitstellend zwei verschiedene Funktionen in einer Entität bzw. Element. Dies ist ähnlich für eine Person, die mit ihrer Heimadresse antwortet, wenn sie gefragt wird, wer sie ist. Wenn eine Mobilität auch betrachtet wird, wird die Situation sogar komplizierter, da IP-Adressen als Host-Identifizierer in diesem Schema agieren, dürfen sie nicht geändert werden; jedoch müssen sie sich, da IP-Adressen auch topologische Orte beschreiben, notwendigerweise ändern, wenn ein Host seinen Ort in dem Netzwerk ändert. Klarerweise ist es unmöglich, sowohl Stabilität und dynamische Änderungen zur gleichen Zeit zu erreichen.
In dem Fall einer Mobile-IP ist die Lösung, einen festen Heimort zu verwenden, bereitstellend eine "Heimadresse" für den Knoten. Die Heimadresse macht beides, sie identifiziert den Knoten und stellt einen stabilen Ort für ihn bereit, wenn er zuhause ist. Die gegenwärtige Ortsinformation ist verfügbar in der Form einer Care-Of-Adresse, die verwendet wird für Umleitungszwecke, wenn der Knoten weg von zu Hause ist.
Eine andere Lösung für das Problem ist es, die Identifizierung und Ortsfunktion voneinander zu trennen, und dies ist der Ansatz, der von dem Host-Identitätsprotokoll-(HIP, Host Identity Protocol)-Vorschlag unternommen wird (R. Moskowitz, P. Nikander, P. Jokela, "Host Internet Protocol", Internet Draft, work in Progress, draft-moskowitz-hip-07.txt, IETF, 2003). HIP trennt den Ort und Identitätsrollen von IP-Adressen durch Einführen eines neuen Namenraums, die Host-Identität (HI, Host Identity). In HIP ist die Host-Identität im Grunde nach ein öffentlicher kryptographischer Schlüssel eines Öffentliche-Private-Schlüsselpaars. Der öffentliche Schlüssel identifiziert die Partei, die die einzige Kopie des privaten Schlüssels hält. Ein Host, der den privaten Schlüssel des Schlüsselpaars verarbeitet, kann direkt nachprüfen, dass er den öffentlichen Schlüssel "besitzt", der verwendet wird zum Identifizieren desselben in dem Netzwerk. Die Trennung stellt auch eine Einrichtung zum Handhaben einer Mobilität und einem Multi-Homing auf eine sichere Art und Weise bereit.
HIP wird detaillierter unten beschrieben, aber es ist nicht der einzige Vorschlag, basierend auf der Idee einer Orts- und Identitätstrennung. FARA (D. Clark, R. Graden, A. Falk, V. Pingali, "FARA: Reorganizing the Addressing Architecture", ACM SIGCOMM 2003 Workshops, August 25 & 27, 2003) ist ein verallgemeinertes Modell von Ideen, das einen Rahmen bereitstellt, von dem die tatsächliche Architektur abgeleitet werden kann. FARA könnte das HIP verwenden, wenn die Knotenidentifizierungen verifiziert werden, und daher könnte HIP ein Teil von einer bestimmten FARA-Instantiierung sein. Der PeerNet-Vorschlag (J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS '03, Februar 20–21, 2003) diskutiert auch die Orts- und Identitätstrennung. Die Internet Indirection Infrastucture, I³ (I. Stoica, et.al, "Internet Indirection Infrastructure", ACM SIGCOMM '02, August 19–23, 2002) definiert auch eine Trennung zwischen der Identitäts- und Umleit-Information.
Über dies hinaus ist ein Adressieren in teilweise HIP-basierten Verbindungen zwischen Legacy und HIP-fähigen Knoten offenbart in L. Eggert, "Host Identity Protocol (HIP) Rendezvous Mechanisms", Internet Draft, drafteggert-hip-rendezvous.txt, IETF, 2004.
Das Host-Identitätsprotokoll führt eine Trennung ein zwischen der Orts- und Identitätsinformation bei der IP-Schicht. Zusätzlich zu der Trennung wird ein Protokoll definiert zum Aushandeln von Sicherheitsassoziierungen (SAs, Security Associations) zwischen HIP-fähigen Knoten.
Bei HIP hat jeder Knoten eine oder mehrere Identitäten, die eine lange Zeit oder kurze Zeit darstellen können, die verwenden werden können zum Identifizieren desselben in dem Netzwerk. Bei HIP ist ein Identifizierer der öffentliche Schlüssel eines Öffentliche-Private-Schlüsselpaars. Wenn der Host den privaten Schlüssel besitzt, kann er nachprüfen, dass er tatsächlich diese Identität "besitzt", die der öffentliche Schlüssel repräsentiert, dies ist ähnlich zum Vorzeigen einer ID-Karte.
Jeder Host kann kurzeitige Schlüssel erzeugen, die nur für eine kurze Zeit zu verwenden sind. Diese sind nützlich, wenn es nicht notwendig ist für den Knoten, identifiziert zu werden mit der gleichen Identität zu einer späteren Zeit. Beispielsweise kann ein Kaufen von Büchern von einem Buchladen eine Langzeitbeziehung darstellen, während ein einmaliges Kontaktieren eines Servers zum Sammeln von Benutzerprofilen als eine kurzzeitige Aktion betrachtet werden kann. In dem späteren Fall kann eine kurzzeitige Identität erzeugt werden, um eine weitläufigere Verbreitung von Langzeitidentitäten zu vermeiden.
Die HIP-Host-Identität (HI), die ein öffentlicher Schlüssel ist, kann ziemlich lang sein und ist deshalb nicht in allen Situationen praktisch. In HIP wird die HI repräsentiert mit einem 128-Bit langen Host-Identitäts-Etikett (HIT, Host Identity Tag), das erzeugt wird von der HI durch Hashen bzw. Zerstückeln derselben. Deshalb identifiziert das HIT eine HI. Da das HIT 128 Bit lang ist, kann es verwendet werden für IPv6-Anwendungen direkt, da es exakt die gleiche Länge, wie IPv6-Adressen hat.
Wenn HIP verwendet wird, sind die oberen Schichten, einschließlich der Anwendungen, nicht länger die IP-Adresse. Anstatt dessen sehen sie das HIT als die "Adresse" des Ziel-Hosts. Die Ortsinformation ist versteckt bei einer neuen Schicht, die unten zu beschreiben ist. Die IP-Adressen identifizieren nicht länger die Knoten; sie werden nur verwendet für ein Routen bzw. Umleiten der Pakete in dem Netzwerk.
Anwendungen sind typischerweise nicht interessiert in Ortsinformation, aber müssen die Identität ihrer Peers bzw. Partners kennen. Die Identität wird repräsentiert durch das HIT. Dies bedeutet, dass die IP-Adresse nur eine Wichtigkeit auf unteren Schichten besitzt, wo ein Routing betrachtet wird. Die HITs, die die Anwendungen verwenden, müssen abgebildet werden auf entsprechende IP-Adressen bevor irgendeines der Pakete den Host verlässt. Dies wird erreicht in einer neuen Host-Identitätsschicht, wie unten beschrieben.
1 der begleitenden Zeichnungen stellt die verschiedenen Schichten in HIP dar, umfassend die Standardtransportschicht 4, Netzwerkschicht 8 und Verbindungsschicht 10, mit einem Prozess 2, der mit der Transportschicht 4 unter ihr kommuniziert. Bei HIP ist eine neue Host-Identitätsschicht 6 angeordnet zwischen der Transportschicht 4 und der Netzwerkschicht 8.
Örtlich werden jede HI und ihr im Zusammenhang stehendes HIT abgebildet auf die IP-Adressen des Knotens. Wenn Pakete den Host verlassen, wird der korrekte Weg bzw. Route ausgewählt (durch irgendeine Einrichtung) und entsprechende IP-Adressen werden in das Paket als die Quelle und Bestimmungsadresse gegeben. Jedes Paket, das von der oberen Schicht ankommt, enthält das HIT der Peers als Zieladresse. Das Abbilden zwischen dem HIT und der Ortsinformation kann auf der HI-Schicht 6 gefunden werden. Deshalb wird die Bestimmungsadresse umgewandelt zu der abgebildeten IP-Adresse, und das Quellen-HIT wird umgewandelt zu der Quellen-IP-Adresse.
Das Abbilden zwischen einem Peer-HIT und einer IP-Adresse kann auf mehrere Arten zurückgewonnen werden, eine von ihnen ist ein DNS-Server. Die Ortsinformation kann aktualisiert werden durch den Peer-Knoten zu jeder Zeit. Die Aktualisierungsprozedur wird detaillierter in dem Mobilitätsverwaltungsunterabschnitt diskutiert.
Das HIP definiert einen Basisnachrichtenaustausch, enthaltend vier Nachrichten, Vier-Wegehandschlag bzw. Handshake, und dies wird benutzt zum Erzeugen einer Sicherheitsassoziierung (SA) zwischen HIP-fähigen Hosts. Während dem Nachrichtenaustausch wird die Diffie-Hellman-Prozedur verwendet zum Erzeugen eines Session-Schlüssels und zum Erstellen eines Paars von IPsec-einkapselnden Sicherheitsnutzlast-(ESR, Encapsulating Security Payload)-Sicherheitsassoziierungen (SAs) zwischen den Knoten.
2 der begleitenden Zeichnungen stellt den Betrieb eines Vier-Wege-Handshakes dar. Die aushandelnden Parteien werden als der Initiator, der die Verbindung startet, und der Antworter bzw. Antwortende bezeichnet. Der Initiator beginnt das Aushandeln durch Senden eines I1-Pakets, das die HITs der Knoten enthält, die in dem Aushandeln bzw. der Verhandlung partizipieren. Das Ziel-HIT kann auch auf Null gesetzt werden, falls das HIT des Antworters nicht von dem Initiator bekannt ist.
Wenn der Antworter das I1-Paket bekommt, sendet er ein R1-Paket zurück, das ein zu lösendes Puzzle für den Initiator enthält. Das Protokoll wird entworfen, so dass der Initiator am meisten der Berechnung des Puzzlelösens durchführen muss. Dies gibt einigen Schutz gegen DoS-Attacken. Das R1 initiiert auch die Diffie-Hellman-Prozedur, enthaltend den öffentlichen Schlüssel des Antorters zusammen mit den Diffie-Hellman-Parametern.
Sobald das R1-Paket empfangen ist, löst der Initiator das Puzzle bzw. Rätsel und sendet ein Antwort-Cookie in einem I2-Paket zusammen mit einem IPsec SPI-Wert und seinem verschlüsselten öffentlichen Schlüssel an den Antworter. Der Antworter verifiziert, dass das Puzzle bzw. Rätsel gelöst wurde, authentifiziert den Initiator und erzeugt die IPsec ESP SAs. Die letzte R2-Nachricht enthält den SPI-Wert des Antworters.
Die SAs zwischen den Hosts sind an die Host-Identitäten gebunden, repräsentiert durch die HITs. Jedoch enthalten die in dem Netzwerk laufenden Pakete nicht die tatsächliche HI-Information, aber das ankommende Paket wird identifiziert und abgebildet auf die korrekte SA, unter Verwendung des Sicherheitsparameterindex-(SPI)-Werts in dem IPsec-Header. 3 der begleitenden Zeichnungen zeigt die logischen und tatsächlichen Paketstrukturen, wenn es in dem Netzwerk herumläuft.
Aus dem Obigen wird klar, dass ein Ändern der Ortsinformation in dem Paket nicht irgendwelche Probleme für das IPsec-Verarbeiten erzeugt. Das Paket ist noch immer korrekt identifiziert, unter Verwendung von SPI. Falls aus irgendeinem Grund das Paket zu einem falschen Ort geleitet wird, ist der Empfänger nicht in der Lage, das Paket zu öffnen, da er nicht den korrekten Schlüssel hat.
Wenn ein ausgehendes Paket ankommt bei der HI-Schicht von der obigen Schicht, wird das Bestimmungs- bzw. Ziel-HIT verifiziert von dem IPsec SADE. Falls ein SA-Anpassen an das Ziel-HIT gefunden wird, wird das Paket verschlüsselt, unter Verwendung des Session-Schlüssels, der im Zusammenhang steht mit der SA.
Das HIT kann nicht verwendet werden zum Umleiten des Pakets. Deshalb müssen die Ziel-(und Quellen-)-Adressen verändert werden, um mit den IP-Adressen der Knoten überein zu stimmen. Diese Abbildungen werden gespeichert, wie vorher bemerkt, in der HI-Schicht. Nachdem die Adressen verändert wurden, kann das Paket gesendet werden an das Netzwerk, wo es umgeleitet wird an das Ziel, unter Verwendung der IP-Adressinformation.
Bei dem empfangenden Host wird der SPI-Wert verwendet, um die korrekte SA von dem IPsec SADB zu finden. Falls ein Eintrag gefunden wird, können die IP-Adressen verändert werden auf entsprechende HITs, und das Paket kann entschlüsselt werden, unter Verwendung des Session-Schlüssels.
Mobilität wird definiert, als die Situation, wo ein Host sich bewegt, während sein Kommunikationskontext aktiv bleibt, oder in anderen Worten, der Host ändert seinen topologischen Ort, beschrieben durch die IP-Adresse, während alle existierenden Verbindungen aktiv aufrechterhalten bleiben. Die Prozesse, die auf dem Host ablaufen, sehen die Mobilität nicht, außer möglicherweise, falls die bemerkte Qualität des Dienstes sich verändert.
Der mobile Host kann den Ort ändern innerhalb eines Zugangsnetzwerks, zwischen verschiedenen Zugangstechnologien oder selbst zwischen verschiedenen IP-Adressgebieten, beispielsweise zwischen dem IPv4- und IPv6-Netzwerk. In HIP bemerkt die Anwendung nicht die Änderung in der IP-Adressversion. Die HI-Schicht versteckt die Änderung vollständig von den oberen Schichten. Natürlich muss der Peer-Knoten bzw. Partnerknoten in der Lage sein, die Ortsaktualisierung handzuhaben, die die IP-Version ändert, und Pakete müssen umleitbar sein, unter Verwendung einer kompatiblen Adresse. Falls ein Knoten nicht sowohl IPv4- und IPv6-Konnektivität aufweist, kann er einen Proxy-Knoten verwenden, der die Adressversionsumwandlung ausführt und eine Konnektivität im Auftrag des Knotens bereitstellt.
Ein Multi-Homing bezieht sich auf eine Situation, wo ein Endpunkt mehrere parallele Kommunikationspfade aufweist, die er verwenden kann. Gewöhnlich ist ein Multi-Homing ein Ergebnis von entweder dem Host, der mehrere Netzwerkschnittstellen aufweist (end-host multi-homing) oder aufgrund eines Netzwerks zwischen dem Host und dem Rest des Netzwerks, das redundante Pfade aufweist (site multi-homing).
Bei HIP macht die Trennung zwischen der Orts- und Identitätsinformation es klar, dass die Paketidentifizierung und Routing sauber voneinander getrennt werden kann. Der Host, der ein Paket empfängt, identifiziert den Sender durch ein erstes Holen des korrekten Schlüssels und dann Entschlüsseln des Pakets. Deshalb sind die IP-Adressen, die in dem Paket sind, irrelevant.
Ein HIP-Mobile-Knoten (HMN, HIP Mobile Node), der sich in dem Netzwerk bewegt, kann den Punkt eines Anbringens an das Netzwerk konstant verändern. Wenn der Verbindungspunkt verändert wird, wird dies auch die IP-Adresse. Diese veränderte Ortsinformation muss an die Partner-Knoten gesendet werden, das heißt, HIP Correspondent Nodes (HCN), und diese ist in 4 der begleitenden Zeichnungen dargestellt. Die gleiche Adresse kann auch gesendet werden an einen Forwarding Agent bzw. weiterleitenden Agent (FA, Forwarding Agent) des HMN, so dass der HMN auch erreicht werden kann über einen stabileren Knoten. Das DNS-System ist zu langsam, um verwendet zu werden für ein konstantes Ändern der Ortsinformation. Deshalb muss es eine stabilere Adresse geben, die verwendet werden kann, um den HMN zu kontaktieren. Diese Adresse ist die Adresse, die bereitgestellt wird durch den FA.
Das HIP-Mobilitäts- und Multi-Homing-Protokoll (P. Nikander, J. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol" Internet Draft, work in Progress, draft-nikander-hip-mm-00.txt, IETF, 2003) definiert ein Readdress-(REA)-Paket, das die gegenwärtige IP-Adresse des HMN enthält. Wenn der HMN seinen Ort und IP-Adresse verändert, erzeugt er ein REA-Paket, signiert das Paket mit einem privaten Schlüssel, der zu dem verwendeten HI passt, und sendet das Paket an den Partnerknoten und an den FA.
Wenn der Partnerknoten ein REA-Paket empfängt, muss er einen Adressverifizierungsprozess für die IP-Adresse starten, die enthalten ist in dem REA-Paket. Die Adressverifizierung wird benötigt, um ein Akzeptieren von falschen Aktualisierungen von dem HMN zu vermeiden. Er sendet ein Adressüberprüfungs-(AC)-Paket an die Adresse, die in dem REA-Paket war. Wenn der HMN ein AC empfängt, das übereinstimmt mit dem REA, das früher gesendet wurde, antwortet er mit einem Adress-Check-Reply-(ACR)-Paket. Nachdem der Partnerknoten das ACR-Paket empfangen hat, wird die Adressverifizierung beendet, und die IP-Adresse kann hinzugefügt werden als Ortsinformation des HMN.
Weil der HMN sich zwischen Netzwerken bewegen kann, unter Verwendung von verschiedenen IP-Adressversionen, kann die durch den HCN empfangene Adresse auch von einer unterschiedlichen Adressfamilie sein, als die vorherige Adresse.
Der HCN kann nur eine IP-Adressversion unterstützen. In diesem Fall muss der HCN einen anderen Proxy-Knoten verwenden, der verwendet werden kann zum Umleiten von Paketen über das andere IP-Adressversionsnetzwerk.
Ein multi-homed HIP-Host (ein HIP-Host mit mehreren Heimen) mit mehreren IP-Adressen, konfiguriert auf verschiedenen Schnittstellen, verbunden mit verschiedenen Zugangsnetzwerken, hat viel mehr Möglichkeiten, Verkehr in Richtung eines Partnerknotens handzuhaben. Da er multiple bzw. mehrere IP-Adressen aufweist, die seine gegenwärtige Lokalisierung in dem Netzwerk darstellen, kann er alle diese Adressen seinen Partnerknoten mitteilen wollen. Um dies zu tun, erzeugt der multi-homed HIP-Knoten ein REA-Paket, das alle Adressen enthält, das in der Lage ist, verwendet zu werden in Richtung dieses bestimmten Knotens. Dieser Satz von Adressen kann alle Adressen enthalten, die er hat, oder einige Untersätze dieser Adressen. Wenn der Partnerknoten das REA-Paket mit den mehreren Adressen empfängt, muss er eine Adressverifizierung für jede dieser Adressen durchführen, um mögliche falsche Aktualisierung zu vermeiden.
Der HCN sendet einen Satz von AC-Paketen, die bestimmt sind für IP-Adressen, enthalten in dem REA-Paket. Wenn der HMN diese ACs empfängt, antwortet er auf jede dieser mit ACRs. Der HCN kann von den empfangenen ACR-Paketen bestimmen, welche dieser Adressen gültig war.
Falsche oder nicht umleitbare Adressen in dem REA-Paket können hervorgerufen werden entweder weil der HMN ein böswilliger Knoten ist, er einen Fehler in der Stack-Implementierung hat, oder der HMN innerhalb eines Netzwerks sein kann, das private Adressen verwendet, die nicht umleitbar in dem Internet sind.
Ein multi-homed HIP-Knoten ist in der Lage, alle der verfügbaren Verbindungen zu verwenden, aber effiziente Verwendung von den Verbindungen benötigt ein Regelungssystem, das ein Wissen von den grundlegenden Zugangsnetzwerken hat und die Verwendung dieser steuern kann. Solch ein Regelungssystem kann verschiedene Arten von Information benutzen: Benutzerpräferenzen, Betreiberpräferenzen, Eingabe von den Netzwerkverbindungen, wie zum Beispiel QoS, und so weiter.
Um den HIP-Austausch mit einem Mobilknoten bzw. mobilen Knoten zu starten, muss der Initiatorknoten wissen, wie der Mobilknoten zu erreichen ist. Obwohl dynamische DNS verwendet werden könnte für diese Funktion für nicht-häufige sich bewegende Knoten, ist eine Alternative zum Verwenden von DNS in dieser Art und Weise, das Stück der statischen Infrastruktur, oben eingeführt, zu verwenden, der Forwarding-Agent bzw. Weiterleitagent (auch bezeichnet als ein HIP-Rendezvous-Server). Anstatt eines Registrierens seiner gegenwärtigen dynamischen Adresse bei dem DNS-Server, registriert der Mobilknoten die Adresse bzw. Adressen seines Weiterleitagenten bzw. Weiterleitagenten. Der Mobilknoten hält den Weiterleitagenten bzw. die Weiterleitagenten kontinuierlich auf dem neuesten Stand mit seinen gegenwärtigen IP-Adressen. Ein Weiterleitagent weiterleitet einfach das Anfangs-HIP-Paket von einem Initiator an den Mobilknoten bei seinem gegenwärtigen Ort. Alle weiteren Pakete fließen zwischen dem Initiator und dem Mobilknoten. Es gibt typischerweise sehr wenig Aktivität bei einem Weiterleitagenten, hauptsächlich Adressenaktualisierung und ein Anfangs-HIP-Paket-Weiterleiten. Deshalb kann ein Weiterleitagent eine große Anzahl von potenziellen Mobilknoten unterstützen. Die Mobilknoten müssen dem Weiterleitagenten vertrauen, um richtig ihr HIT und IP-Adressabbilden aufrechtzuerhalten. Ein Weiterleitagent kann verwendet werden sogar für Knoten, die fest im Ort sind, da es oft der Fall ist, dass feste Knoten ihre IP-Adresse häufig ändern, beispielsweise wenn er allokiert wird, jedes Mal, wenn eine Internet-Verbindung eingerichtet wird, durch einen Dienstbereitstelle für diesen Knoten.
Der Weiterleitagent wird auch benötigt, falls beide der Knoten Mobil sind und sich zur gleichen Zeit bewegen. In diesem Fall werden sich die HIP-Readdress-Pakete miteinander in dem Netzwerk kreuzen, und nie den Partnerknoten erreichen. Um diese Situation zu lösen, sollten sich die Knoten an die Weiterleitagentadresse erinnern, und das HIP-Readdress-Paket an den Weiterleitagenten neu versenden, falls keine Antwort empfangen wird.
Der Mobilknoten hält seine Adresse aktuell bei dem Weiterleitagenten durch Einrichten einer HIP-Assoziierung mit dem Weiterleitagenten und einem Senden von HIP-Readdress-Paketen an ihn. Ein Weiterleitagent wird zwei Mobilsystemen erlauben, HIP zu verwenden, ohne irgendeine externe Infrastruktur (zusätzlich zu dem Weiterleitagenten selbst), einschließlich DNS, falls sie ein Verfahren haben, das verschieden ist von einer DNS-Abfrage bzw. DNS-Query, um jeweils ihr HI und HIT zu erhalten.
In dem Fall von Legacy-Geräten kann ein Host nicht-HIP-fähig sein, und die einzige Option ist es, Verbindungen zwischen Hosts zu identifizieren, die IP-Adressen verwenden. Dies ist nicht sicher. Die Situation kann verbessert werden durch Lokalisieren eines HIP-Proxy zwischen dem HIP-fähigen Host und dem Host, der HIP nicht verwenden kann. Ein typisches Szenario würde ein kleines geschäftliches LAN sein, wo die Client-Endgeräte nicht HIP-fähig sind. Verkehr wird umgeleitet zu entsprechenden Hosts (die HIP-fähig sind) über den HIP-Proxy.
Diese Anordnung wird in 5 der begleitenden Zeichnungen dargestellt. In 5 wird ein Legacy-Host 12 gezeigt, der kommuniziert mit einem HIP-fähigen Knoten 14 (mit dem Domain-Namen "hip.foo.com") über ein HIP-Proxy 16. Der Legacy-Host 12 greift auf den HIP-Proxy 16 über ein Zugangsnetzwerk 18 zu, während der HIP-Proxy 16 auf den HIP-Knoten 14 über das Internet 20 zugreift. Um teilweise die Verbindung zwischen dem Legacy-Host 12 und dem HIP-Knoten 14 zu sichern, werden alle Kommunikationen zwischen dem HIP-Proxy 16 und dem HIP-Knoten 14 durch eine Security Association bzw. Sicherheitsassoziierung eingerichtet zwischen dem HIP-Proxy 16 und dem HIP-Knoten 14 auf eine ähnliche Art und Weise, zu der mit Bezug auf 3 oben beschriebenen.
Jedoch tritt, selbst bevor die Sicherheitsassoziierung 22, gezeigt in 5, eingerichtet werden kann, um eine Kommunikation zwischen dem Legacy-Host 12 und dem HIP- Knoten 14 zu ermöglichen, ein Problem auf, wenn der Legacy-Host 12 versucht, die IP-Adresse des HIP-Knotens 14 zu finden, durch Senden einer Anfrage an einen DNS-Server 24- (und umgekehrt DNS-Server 24-2), wenn sich der HIP-Knoten 14 hinter einem Weiterleitagenten 26 befindet, wie oben beschrieben. Der DNS-Server 24-1 wird das HIT des HIP-Knotens 14 zusammen mit der IP-Adresse des Weiterleitagenten 26 zurückgeben. Da der Legacy-Host 12 nicht HIP-fähig ist, wird er das HIT nicht in Betracht ziehen, und ein Senden von Nachrichten an den Weiterleitagenten 26 starten. Ohne das HIT wird der Weiterleitagent 26 nicht in der Lage sein, die Zieladresse dieser Nachrichten aufzulösen bzw. zu finden, da es sehr wahrscheinlich ist, dass mehrere HIP-Knoten den gleichen Weiterleitagenten 26 verwenden werden. Ähnlich ist, da der Legacy-Host 12 das HIT verwirft und nur die IP-Adresse des HIP-Knotens 14 verwendet, bei einem Initiieren einer Verbindung, der HIP-Proxy 16 nicht in der Lage, ein HIP-Aushandeln zu initiieren zwischen sich selbst und dem HIP-Knoten 14, weil er das HIT von dem HIP-Knoten 14 nicht kennt.
Es ist erwünscht, ein Verfahren für ein mindestens teilweises Sicherstellen von Kommunikationsvorgängen zwischen einem ersten Host, der nicht-HIP-fähig ist, und einem zweiten Host, der HIP-fähig ist, bereitzustellen, über einen HIP-Proxy, der die obigen Probleme vermeidet.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem ersten Aspekt der vorliegenden Erfindung, wird ein Verfahren von mindestens einem teilweisen Sicherstellen von Kommunikationsvorgängen über ein HIP-Proxy bereitgestellt, zwischen einem ersten Host, der nicht-HIP-fähig ist, und einem zweiten Host, der HIP-fähig ist, wobei das Verfahren umfasst: Senden einer Anfrage von dem ersten Host zum Erlangen der IP-Adresse des zweiten Hosts; in Ansprechen auf die Anfrage, Wiedererlangen einer IP-Adresse und einem HIT, das in Verbindung steht mit dem zweiten Host; in Ansprechen auf die Wiedererlangung, Zurückgeben von dem Proxy, einer Substituts-IP-Adresse, die in Verbindung steht mit dem zweiten Host; Aufrechterhalten bei dem Proxy einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT; und bei Empfang einer Session-Initiierungs-Nachricht bei dem Proxy von dem ersten Host, einschließlich der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Aushandeln einer HIP-Verbindung zwischen dem Proxy und dem zweiten Host.
Das Verfahren kann umfassen ein Nachschlagen bzw. Nachschauen der wiedererlangten IP-Adresse und des wiedererlangten HIT von der Abbildung, basierend auf der Substituts-IP-Adresse in der Session-Initiierungs-Nachricht, und ein Ausführen des HIP-Aushandelns bzw. HIP-Verhandlung, unter Verwendung der wiedererlangten IP-Adresse und des wiedererlangten HIT, um den Antworter bzw. den Antwortenden in der HIP-Verhandlung zu lokalisieren und identifizieren, zusammen mit einer IP-Adresse und einem HIT von dem Proxy, zum Lokalisieren und Identifizieren des Initiators in der HIP-Verhandlung.
Die wiedererlangte IP-Adresse kann die IP-Adresse eines weiterleitenden bzw. Weiterleitagenten sein, die von dem zweiten Host verwendet wird, und ferner umfassend Initiieren der HIP-Verhandlung zwischen dem Proxy und dem zweiten Host durch Senden des Anfangs-HIP-Verhandlungspakets an den Weiterleitagenten.
Das Verfahren kann ferner umfassen, ein Nachfolgen des Empfangs der tatsächlichen IP-Adresse des zweiten Hosts an den Proxy, während der HIP-Verhandlung einschließlich der tatsächlichen IP-Adresse in der Abbildung, die aufrechterhalten wird bei dem Proxy. Die wiedererlangte IP-Adresse kann ersetzt werden in der Abbildung durch die tatsächliche IP-Adresse nach ihrem Empfang bei dem Proxy.
Die wiedererlangte IP-Adresse kann die tatsächliche IP-Adresse von dem zweiten Host sein.
Das Verfahren kann ein Erzeugen der Substituts-IP-Adresse bei dem Proxy umfassen.
Das Verfahren kann ferner umfassen, für eine ausgehende Nachricht, die empfangen wird bei dem Proxy, nachdem die HIP-Verbindung erstellt wurde, mit der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Umleiten der Nachricht über die HIP-Verbindung zu dem zweiten Host. Dies kann ein Nachschauen nach der tatsächlichen IP-Adresse und des wiedererlangten HIT von dem Abbilden enthalten, basierend auf der Substituts-IP-Adresse in der ausgehenden Nachricht, und ein Umleiten der ausgehenden Nachricht an den zweiten Host, unter Verwendung der tatsächlichen IP-Adresse und des wiedererlangten HIT zum Lokalisieren und Identifizieren des Ziels der Nachricht, und Verwenden einer IP-Adresse und eines HIT von dem Proxy zum Lokalisieren und Identifizieren der Quelle der Nachricht.
Das Verfahren kann ferner umfassen ein Vervollständigen bzw. Beenden des Einrichtens der Kommunikationsvorgänge zwischen dem ersten und zweiten Host durch Weiterleiten der Session-Initiierungs-Nachricht von dem Proxy an den zweiten Host über die HIP-Verbindung, Antworten mit einer Session-Bestätigungs-Nachricht von dem zweiten Host an den Proxy über die HIP-Verbindung und Leiten der Session-Bestätigungs-Nachricht an den ersten Host. Die Session-Bestätigungs-Nachricht kann eine TCP-ACK-Nachricht sein.
Die Session-Initiierungs-Nachricht kann eine TCP-SYN-Nachricht sein.
Das Verfahren kann umfassen, für eine ankommende Nachricht, die empfangen wird bei dem Proxy von dem zweiten Host über die eingerichtete HIP-Verbindung, Verwendung einer NAT-Funktion des Proxy zum Umleiten der Nachricht an den passenden Ziel-Host.
Die oben erwähnte Anfrage kann eine DNS-Anfrage sein. Der Proxy kann die DNS-Anfrage von dem ersten Host abfangen. Der Proxy kann den Schritt eines Wiedererlangens der IP-Adresse und des HIT, assoziiert mit dem zweiten Host, ausführen.
Der Proxy kann die IP-Adresse und HIT, assoziiert mit dem zweiten Host, von einem externen DNS-Server wiedererlangen. Oder der Proxy kann die IP-Adresse und HIT, assoziiert mit dem zweiten Host, von einem internen DNS-Server wiedererlangen.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Kommunikationssystem bereitgestellt, das einen ersten Host umfasst, der nicht HIP-fähig ist, sowie einen zweiten Host, der HIP-fähig ist, und einen HIP-Proxy, wobei: der erste Host eine Einrichtung umfasst zum Senden einer Anfrage zum Erlangen der IP-Adresse des zweiten Hosts; der Proxy eine Einrichtung umfasst zum Wiedererlangen, in Ansprechen auf die Anfrage einer IP-Adresse und eines HIT, im Zusammenhang stehend mit dem zweiten Host, zum Zurückgeben, in Ansprechen auf die Wiedererlangung, einer Substituts-IP-Adresse, die im Zusammenhang steht mit dem zweiten Host, zum Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT, und zum Verwenden der Abbildung, bei Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP-Adresse als seine Zieladresse, zum Aushandeln bzw. Verhandeln einer HIP-Verbindung zwischen dem Proxy und dem zweiten Host.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren bereitgestellt zum Verwenden durch ein HIP-Proxy von einem mindestens teilweise Sicherstellen von Kommunikationsvorgängen, über den Proxy, zwischen einem ersten Host, der nicht HIP-fähig ist, und einem zweiten Host, der HIP-fähig ist, wobei das Verfahren umfasst: Empfangen einer Anfrage von dem ersten Host zum Erlangen der IP-Adresse des zweiten Hosts; in Ansprechen auf die Anfrage, Wiedererlangen einer IP-Adresse und eines HIT, im Zusammenhang stehend mit dem zweiten Host; in Ansprechen auf die Wiedererlangung, Zurückgeben einer Substituts-IP-Adresse, im Zusammenhang stehend mit dem zweiten Host, und Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der erlangen IP-Adresse und des erlangten HIT; und beim Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Verhandeln einer HIP-Verbindung zwischen dem Proxy und dem zweiten Host.
Gemäß einem vierten Aspekt der vorliegenden Erfindung wird ein HIP-Proxy zur Verwendung in mindestens einem teilweise Sicherstellen von Kommunikationsverbindungen bereitgestellt, über den Proxy, zwischen einem ersten Host, der nicht HIP-fähig ist, und einem zweiten Host, der HIP-fähig ist, umfassend: eine Einrichtung zum Empfangen einer Anfrage von dem ersten Host zum Erlangen der IP-Adresse des zweiten Hosts; eine Einrichtung zum Wiedererlangen, in Ansprechen auf die Anfrage einer IP-Adresse und eines HIT, im Zusammenhang stehend mit dem zweiten Host, zum Zurückgeben, in Ansprechen auf die Wiedererlangung, einer Substituts-IP-Adresse, die im Zusammenhang steht mit dem zweiten Host, und Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT und eine Einrichtung zum Verwenden der Abbildung, beim Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP- Adresse als seine Zieladresse, zum Aushandeln einer Hip-Verbindung zwischen dem Proxy und dem zweiten Host.
Gemäß einem fünften Aspekt der vorliegenden Erfindung wird ein Computerprogramm bereitgestellt, das, wenn es auf einem HIP-Proxy läuft, bei dem Proxy hervorruft, ein Verfahren gemäß dem dritten Aspekt der vorliegenden Erfindung auszuführen.
Gemäß einem sechsten Aspekt der vorliegenden Erfindung wird ein Computerprogramm bereitgestellt, das, wenn es in einem HIP-Proxy geladen ist, bei dem Proxy hervorruft, alle Merkmale gemäß dem vierten Aspekt der vorliegenden Erfindung einzuschließen.
Das Computerprogramm kann auf einem Trägermedium ausgeführt werden, das ein Übertragungsmedium oder Speichermedium sein kann.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1, die vorher diskutiert wurde, stellt verschiedene Schichten in dem Host-Identitätsprotokoll dar;
2, die auch vorher diskutiert wurde, stellt den Betrieb des Vier-Wege-Handshakes in dem HIP-Protokoll dar;
3, die auch vorher diskutiert wurde, zeigt die logischen und tatsächlichen Paketstrukturen in HIP;
4, die auch vorher diskutiert wurde, stellt ein Handover bzw. Übergabe zwischen IPv6 und IPv4 dar;
5, die auch vorher diskutiert wurde, ist ein schematisches Diagramm, das die allgemeine Netzwerkanordnung für Kommunikationsvorgänge zwischen einem Legacy-Host und einem HIP-Knoten über ein HIP-Proxy darstellt;
6 zeigt ein Nachrichtenaustauschdiagramm, das schematisch ein Verfahren von mindestens einem teilweisen Sicherstellen von Kommunikationsvorgängen zwischen einem Legacy-Host und einem HIP-Host gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
7 stellt eine detailliertere schematische Darstellung von den Paketstrukturen bereit, die in TOP, UDP, ESP und HIP verwendet werden; und
8 bis 12 sind Nachrichtenaustauschdiagramme, die die Verfahrensschritte von 6 detaillierter zeigen.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Eine Ausführungsform der vorliegenden Erfindung wird nun beschrieben innerhalb des allgemeinen Rahmens des oben beschriebenen Systems mit Bezug auf 5. Eine Ausführungsform der vorliegenden Erfindung stellt ein Verfahren von mindestens einem teilweisen Sicherstellen von Kommunikationsvorgängen zwischen dem Legacy-Host 12, der nicht HIP-fähig ist, und dem HIP-Host 14, der HIP-fähig ist, über den HIP-Proxy 16 bereit. Ein Betrieb einer Ausführungsform der vorliegenden Erfindung wird nun beschrieben mit Bezugnahme auf das Nachrichtenaustauschdiagramm der 6. Die Schritte, die in 6 gezeigt sind, sind auch dargestellt in größerem Detail in den 8 bis 12, während 7 eine detailliertere Übersicht der Paketstrukturen gibt, die verwendet werden in TOP, UDP (User Datagram Protocol), ESP und HIP.
Es sei die Situation betrachtet, wo der Legacy-Host 12 eine Kommunikation zu initiieren wünscht, zwischen sich selbst und dem HIP-Host 14. Der Legacy-Host 12 kennt den Domain-Namen des HIP-Hosts 14, der "hip.foo.com" ist, und als ersten Schritt (markiert als "A" in 6 und 8) sendet der Legacy-Host 12 eine Domain-Namesystem-(DNS, Domain Name System)-Anfrage an seinen gewöhnlichen DNS-Server, um die IP-Adresse des HIP-Hosts 14 zu erlangen. Jedoch wird, anstatt eines direkten Empfangens bei einem DNS-Server, in einer Ausführungsform der vorliegenden Erfindung, die DNS-Anfrage abgefangen durch den HIP-Proxy 16, der selbst eine DNS-Anfrage an den DNS-Server 24-1 sendet (Dies ist markiert als "B" bei den 6 und 8).
In Ansprechen auf diese DNS-Anfrage kommuniziert der DNS-Server 24-1 mit dem "foo.com" DNS-Server 24-2, um eine IP-Adresse und HIT, in Verbindung stehend mit dem HIP-Host 14, wiederzuerlangen (markiert als "C" in 6 und 9). Da in diesem Beispiel der HIP-Host 14 den Weiterleitagenten (FA, Forwarding Agent) 26 als eine "Heimadresse", wie oben beschrieben, verwendet, ist die IP-Adresse und HIT, wiedererlangt von der DNS-Anfrage, die IP-Adresse 3ffe:200::1 (IP_fn) des Weiterleitagenten 26 und das HIT des HIP-Hosts 14, hier bezeichnet als HIT_hip. Es sei bemerkt, dass des nicht immer der Fall ist, dass mehrere DNS-Server benötigt werden würden, um eine IP-Adresse zu erlangen; falls die Information bei dem ersten Server gefunden wird, dann würde es keinen Bedarf geben, die zusätzlichen DNS-Server zu verwenden.
Da der HIP-Proxy weiß, dass der initiierende Host, der die DNS-Anfrage sendet, nicht HIP-fähig ist, gibt der HIP-Proxy 16 die DNS-Information {HIT_hip; IP_fn} nicht zurück. Anstatt dessen erzeugt der HIP-Proxy 16 eine Substituts-IP-Adresse IP_res, die in diesem Beispiel 3ffe:401::5 ist. Der HIP-Proxy 16 hält eine Abbildung {HIP_hip; IP_fn; IP_res} aufrecht zwischen dem HIT, das wiedererlangt wird von dem DNS-Server 24, der IP-Adresse, die wiedererlangt wird von dem DNS-Server 24, und der Substituts-IP-Adresse, die erzeugt wird von dem HIP-Proxy 16. Diese Abbildung wird benötigt, um ein Umleiten von nachfolgenden Kommunikationen handzuhaben, wie unten beschrieben wird. Die Erzeugung der Substituts-IP-Adresse IP_res und die Aufrechterhaltung der Abbildung wird markiert als "D" in den 6 und 9.
In der Zwischenzeit sendet der HIP-Proxy 16 eine DNS-Antwort bzw. DNS-Response zurück zu dem Legacy-Host 12, mit der Substituts-IP-Adresse IP_res, und dies wird markiert als "E" in den 6 und 9. Die Substituts-IP-Adresse IP_res wird von dem Legacy-Host 12 als die Zieladresse für alle nachfolgenden Kommunikationsvorgänge, die ausgesendet werden von dem HIP-Host 14, verwendet.
Wenn der Legacy-Host 12 bereit ist zum Initiieren einer Verbindung mit dem HIP-Host 14, sendet er eine Session-Initiierungs-Nachricht TCP SYN, die als ihre Zieladresse die Substituts-IP-Adresse IP_res aufweist; dies ist markiert als "F" in 6 und 10. Da die Substituts-IP-Adresse IP_res erzeugt wurde durch den HIP-Proxy 16, und auf aufrechterhalten wird in der Abbildung M, erkennt der HIP-Proxy 16 die Zieladresse der Initiierungsnachricht von dem Legacy-Host 12 (markiert als "F.1" in 10) und nimmt eine nachfolgende Verantwortung für ein Einrichten und Handhaben der Kommunikationsvorgänge zwischen dem Legacy-Host 12 und dem HIP-Host 14 an.
Der HIP-Proxy 16 verwendet dann die Abbildung M, um eine sichere HIP-Verbindung (Sicherheitsassoziierung) zwischen dem HIP-Proxy 16 und dem HIP-Host 14 zu verhandeln. Die Verhandlung, die ausgeführt wird zwischen dem HIP-Proxy 16 und dem HIP-Host 14 ist sehr ähnlich zu dem Vier-Wege-Handschlag bzw. Vier-Wege-Handshake, der oben beschrieben wird mit Bezug auf 2, wobei der Initiator in diesem Beispiel der HIP-Proxy 16 ist, und der Antwortende bzw. Antworter der HIP-Host 14. Der Start der HIP-Verhandlung wird markiert als "G" in den 6 und 10. Es sollte bemerkt werden, dass, wo der Ausdruck "Sicherheitsassoziierung" hierin verwendet wird, es angenommen werden sollte, dass dies den Fall enthält, wo ein Paar von Sicherheitsassoziierungen erzeugt wird zwischen den zwei Hosts, wobei eine Sicherheitsassoziierung den Verkehr in eine Richtung handhabt und die andere den Verkehr in der anderen Richtung handhabt. Logisch würde es eine SA-Leitung zwischen den zwei Hosts geben, aber physikalisch würde es zwei SAs geben.
Unter Verwendung der Abbildung M bestimmt der HIP-Proxy 16, dass das I1-Paket an die IP-Adresse IP_fa gesendet werden sollte, welches die IP-Adresse des Weiterleitagenten 26 ist, verwendet von dem HIP-Host 14. Das I1-Paket enthält die HITs der Knoten, die in der Verhandlung partizipieren, das heißt HIT_hip und HIT_proxy. Diese Abbildung ist markiert als "H" in den 6 und 10. Wenn das I1-Paket empfangen wird von dem Weiterleitagenten 26, führt es eine Abbildung von HIT_hip zu der tatsächlichen IP-Adresse IP_hip aus, und führt seine gewöhnliche Funktion eines Weiterleitens des empfangenen I1-Pakets an den HIP-Host 14 aus, der sich bei IP_hip befindet.
Einem Empfang des I1-Pakets bei dem HIP-Host 14 folgend, wird der Rest der Vier-Wege-Handshake-Verhandlung, wie oben beschrieben mit Bezug auf 2, gebildet durch das Senden der R1-, I2- und R2-Pakete. Nachdem diese Verhandlung abgeschlossen wurde, wurde die Sicherheitsassoziierung 22 zwischen dem HIP-Proxy 16 und dem HIP-Host 14 eingerichtet, und dies wird markiert durch "I" in 6 und 10.
Nachdem nun die Sicherheitsassoziierung 22 eingerichtet wurde, führt der HIP-Proxy 16 fort, durch Senden der TCP-SYN-Initiierungs-Nachricht an den HIP-Host 14. Die Abbildung und die Netzwerkadressumwandlungs-(NAT, Network Address Translation)-Funktion, die ausgeführt wird, wird detaillierter in dem unteren Teil der 11 gezeigt, und als "I.1" in dieser Figur markiert. Der HIP-Host 14 antwortet mit einer TCP-ACK-Nachricht, die an die IP-Adresse des HIP-Proxy 16 gerichtet ist, die in diesem Beispiel 3ffe:300::1 ist; diese zwei Schritte werden als "J" in den 6 und 11 markiert. Letztendlich gibt der HIP-Proxy 16 eine TCP-ACK-Nachricht an den Legacy-Host 12 als seine IP-Adresse 3ffe:400::50 zurück, um die TCP-Initiierungsprozedur zu beenden; dies wird markiert als "K" in den 6 und 12. Es wird bemerkt, dass die TCP-ACK-Nachricht, markiert als "J" in den 6 und 11, von dem HIP-Host 14 an den HIP-Proxy 16, als ihre Ziel-IP-Adresse die IP-Adresse des HIP-Proxy 16 und nicht die IP-Adresse des Legacy-Hosts 12 enthalten hat. Das Verfahren, durch das der HIP-Proxy 16 nachfolgend weiß, wie die TCP-ACK-Nachricht zu senden ist an den korrekten Legacy-Host 12, wird nun beschrieben.
Nur eine Sicherheitsassoziierung 22 wird eingerichtet zwischen dem HIP-Proxy 16 und dem HIP-Knoten 14, und diese Sicherheitsassoziierung 22 wird verwendet durch mehrere Legacy-Hosts, die kommunizieren mit dem gleichen HIP-Host 14. Die oben beschriebene Abbildung M steht im Zusammenhang mit einer Sicherheitsassoziierung und nicht mit einem bestimmten Legacy-Host, wie zum Beispiel dem Legacy-Host 12. Da die Sicherheitsassoziierung 22 und ihre im Zusammenhang stehende Abbildung M verwendet werden müssen durch eine Vielzahl von Legacy-Hosts, kann die Abbildung M nicht Information hinsichtlich eines bestimmten Legacy-Hosts enthalten, wie zum Beispiel die IP-Adresse des Legacy-Hosts, die anfangs verantwortlich war für ein Einrichten der Sicherheitsassoziierung 22. Anstatt dessen handhabt die Netzwerkadressübersetzungs(NAT, Network Adress Translation)-Funktion in dem HIP-Proxy die Abbildung der Pakete an die korrekte Legacy-Host-IP-Adresse.
Für diesen Zweck werden die Portnummern der oberen Schicht verwendet, bezüglich der gewöhnlichen NAT-Funktion. Für Verkehr zwischen dem HIP-Host 14 und dem Legacy-Host 12 über den HIP-Proxy 16, ist die Quellenadresse, wenn das IP-Paket bei dem HIP-Proxy 16 von dem HIP-Host 14 ankommt, ursprünglich die IP-Adresse des HIP-Hosts 14. Die Substituts-IP-Adresse IP_hip wird wiedererlangt von der Abbildung M, die in Verbindung steht mit der Sicherheitsassoziierung 22 und wird ersetzt als Quellenadresse des IP-Pakets. Das IP-Paket wird dann weitergegeben zu der NAT-Funktion des HIP-Proxy 16 und, unter Verwendung der Quellen-IP-Adressinformation und den Portnummern, kennt die NAT-Funktion den tatsächlichen Legacy-Host 12, wohin das IP-Paket zu senden ist. Die NAT-Funktion verwendet sowohl die IP-Adresse und die Portnummer für Adressabbildungszwecke. Die Portnummer alleine kann nicht verwendet werden, da zwei Legacy-Hosts die gleiche Quellenportnummer verwenden könnten. Die standardisierte NAT-Funktion führt auch eine Portabbildung aus, da sonst die Adressübersetzung nicht funktionieren wird, falls zwei Hosts die gleiche Quellenportnummer für Kommunikation in Richtung des gleichen externen Knotens verwenden. Beim Ausführen einer NAT-Abbildung wird auch das Protokoll nachgeschaut, da UDP und TCP die gleichen Portnummern verwenden können.
Beispielsweise ist für zwei Legacy-Hosts LH1 und LH2, die kommunizieren mit dem externen HIP-Host 14, zuhörend auf Port 10000:
LH1: Quellenport 5000, dst Port 10000, srcIP IP_Ih1, dstIP IP_res
LH2: Quellenport 5000, dst Port 10000, srcIP IP_Ih2, dstIP IP_res
Der HIP-Proxy 16 führt die Abbildung für die ausgehende (HIP-host-bound)-Verbindung, wie folgt durch:
LH1: neue Quelle 5001, dst port 10000, srcIP IP_proxy, dstIP IP_hip
LH2: neue Quelle 5002, dst Port 10000, srcIP IP_proxy, dstIP IP_hip
Das Obige ist deshalb nur die Standard-NAT-Funktion, außer dass die Zieladresse auch geändert wird von dem HIP-Proxy 16 von IP_res zu IP_hip.
Der HIP-Host 14 sieht zwei getrennte Verbindungen von dem HIP-Proxy 16 mit der gleichen IP-Adresse. Für den eingehenden (LH-bound)-Verkehr von dem HIP-Host 14 kann der HIP-Proxy 16 nun die Abbildung durchführen:
dstIP_proxy, srcIP_hip, dst port 5001, src port 10000 ⇒ dstIP_Ih1; srcIP_res; dst port 5000; src port 10000
dstIP_proxy, srcIP_hip, dst port 5002, src port 10000 ⇒ dstIP_Ih2; srcIP_res; dst port 5000; src port 10000
Die NAT-Funktion für ankommende Pakete wird auch detaillierter in dem unteren Teil der 12 dargestellt und wird als "K” markiert.
Sobald die HIP-Sicherheitsassoziierung 22 eingereichtet wird zwischen dem HIP-Proxy 16 und dem HIP-Host 14, gehen nachfolgende Kommunikationen zwischen dem Legacy-Host 12 und dem HIP-Host 14 nicht durch den Weiterleitagenten 26, der nur verwendet wird zum Weiterleiten des Anfangs-I1-Pakets, wie oben beschrieben. Deshalb ist, für eine eingerichtete Sicherheitsassoziierung 22, die IP-Adresse des Weiterleitagenten (IP_fa) nicht länger notwendig in der Abbildung M, im Zusammenhang stehend mit der Sicherheitsassoziierung 22. Anstatt dessen wird die gegenwärtige Ortsinformation (IP-Adresse IP_hip) des HIP-Hosts 14 benötigt.
Deshalb kann die IP-Adresse des Weiterleitagenten 26 (IP_fa) ersetzt werden in der Abbildung M mit der IP-Adresse des HIP-Hosts 14 (IP_hip). In anderen Worten wird die Abbildung M geändert von {HIT_hip; IP_fa; IP_res} auf {HIT_hip; IP_hip; IP_res}. Dies wird dargestellt in 10 durch "H.1". Durch dies können irgendwelche nachfolgenden Pakete, die gesendet werden von dem Legacy-Host 12 mit der Substituts-IP-Adresse IP_res als ihre Bestimmungs- bzw. Zieladresse, abgebildet werden durch den HIP-Proxy 16 auf die Sicherheitsassoziierung 22, unter Verwendung der modifizierten Abbildung M und weitergeleitet werden direkt an den HIP-Host 14 bei dem Ort IP_hip. Die Quellen- und Ziel-IP-Adressen werden abgebildet auf dem HIP-Proxy 16 von {dst = IP_res; src = IP_Ih} auf {dst = IP_hip; src = IP_proxy}, wobei die Abbildung genommen wird aus der modifizierten Abbildung M. Der HIP-Proxy 16 empfängt die tatsächliche IP-Adresse IP_hip des HIP-Hosts 14 von dem R1-Paket während der HIP-Verhandlung.
Obwohl eine Ausführungsform der vorliegenden Erfindung oben beschrieben wurde, in der sich der HIP-Host 14 hinter einem Weiterleitagenten 26 befindet, wird die vorliegende Erfindung auch angewandt, wenn kein Weiterleitagent verwendet wird von dem HIP-Host 14. Beispielsweise wird, falls der HIP-Host 14 (mit Domain-Name "hip.foo.com") eine feste IP-Adresse IP_fixed aufweist, mit keinem Weiterleitagenten, eine DNS-Anfrage die feste IP-Adresse IP_fixed und das HIT_hip des HIP-Hosts 14 zurückgeben. Wenn ein Legacy-Host 12 versucht, die IP-Adresse für "hip.foo.com" zu erlangen, wird der HIP-Proxy 16 diese DNS-Anfrage abfangen, und selbst IP_fixed und HIT_hip von dem DNS wiedererlangen. Der HIP-Proxy 16 kann im Allgemeinen nicht wissen, dass die IP-Adresse, die zurückgegeben wird von dem DNS-Server 24, die tatsächliche IP-Adresse des HIP-Hosts 14 ist und nicht die IP-Adresse eines Weiterleitagenten, die verwendet wird von dem HIP-Host 14, und deshalb erzeugt er eine Substituts-IP-Adresse IP_res, wie oben beschrieben, und gibt diese Substituts-IP-Adresse an den Legacy-Host 12 zurück, wie vorher. Der HIP-Proxy 16 hält die Abbildung {HIT_hip; IP_fixed; IP_res} aufrecht, hört nach einem TCP-SYN-Paket für IP_res, beim Empfang von diesem handelt er mit dem HIP-Host 14, basierend auf {HIT_hip; IP_fixed} von der Abbildung. Sobald die Sicherheitsassoziierung eingerichtet wird, werden für IP_res bestimmte Pakete von dem HIP-Proxy 16 aufgenommen und weitergeleitet an {HIT_hip; IP_fixed}, unter Verwendung der Abbildung. Dies ist ziemlich die gleiche Prozedur, wie oben beschrieben, außer dass IP_fa nie in der Abbildung gespeichert wird, und deshalb nie ersetzt wird. Anstatt dessen umfasst die Abbildung die IP-Adresse des HIP-Hosts 14 von dem Startpunkt.
Falls es für den HIP-Proxy 16 möglich wäre, zu bestimmen, dass die IP-Adresse, wiedererlangt von dem DNS-Server 24, die tatsächliche IP-Adresse des HIP-Hosts 14 war, dann würde eine Alternative zu einem Erzeugen einer Substituts-IP-Adresse einfach sein, die tatsächliche IP-Adresse des HIP-Hosts 14 an den Legacy-Host 12 zurückzugeben. Dies würde die Möglichkeit eröffnen, dass Kommunikationen zwischen dem Legacy-Host 12 und dem HIP-Host 14 den HIP-Proxy 16 ganz umgehen könnten, da der Legacy-Host 12 die tatsächliche IP-Adresse des HIP-Hosts 14 hat. Falls dies der Fall wäre, würden dann die Kommunikationen nicht sichergestellt werden durch das HIP-Protokoll, aber Kommunikationen würden nichts desto trotz möglich sein, basierend auf Standard-TCP/IP. Jedoch würde, in kleinen Netzwerken mit einem ausgehenden Weg von dem Legacy-Host 12 an den HIP-Proxy 16, es noch immer möglich sein, für den HIP-Proxy 16, als ein sicherer Gateway zwischen dem Legacy-Host 12 und dem HIP-Host 14 zu agieren, mit einer Sicherheitsassoziierung, die eingerichtet ist, ungefähr wie vorher, aber wobei keine Abbildung zwischen einer Substituts-IP-Adresse und der tatsächlichen IP-Adresse des HIP-Hosts 14 benötigt wird. Deshalb würde, in dem späteren Fall, die Abbildung M nur die IP-Adresse IP_hip des HIP-Hosts 14 und das HIT des HIP-Hosts 14, HIT_hip umfassen.
Obwohl es oben beschrieben wurde, dass der HIP-Proxy 16 eine DNS-Anfrage an einen externen DNS-Server 24 sendet, ist es möglich, dass der HIP-Proxy 16 selbst auch die Funktion eines DNS-Servers bedienen könnte, wobei keine externe DNS-Anfrage notwendig ist.
Es wird erkannt, dass ein Betrieb von einem oder mehreren der Legacy-Hosts 12, HIP-Proxy 16 und HIP-Host 14 gesteuert werden kann durch ein Programm, das auf dem Gerät arbeitet. Solch ein Betriebsprogramm kann auf einem computerlesbaren Medium gespeichert werden oder könnte beispielsweise in einem Signal verkörpert werden, wie zum Beispiel einem herunterladbaren Datensignal, das bereitgestellt wird von einer Internet-Webseite. Die anhängenden Ansprüche sind als ein Betriebsprogramm selbst abdeckend zu interpretieren, oder als eine Aufzeichnung auf einem Träger, oder als ein Signal oder in irgendeiner anderen Form.
Ein Fachmann wird erkennen, dass Ausführungsformen der vorliegenden Erfindung nicht notwendigerweise begrenzt sind auf irgendein bestimmtes Protokoll für jede der Schichten, beispielsweise in den Transport- oder Netzwerkschichten, und funktionieren wird innerhalb des HIP-Rahmens, was auch immer für ein Adressier- oder Transportprotokoll verwendet wird um diesen Rahmen.

Claims

Ein Verfahren für ein mindestens teilweise Sicherstellen von Kommunikationsvorgängen über ein Host-Identitätsprotokoll-, HIP (Host Identity Protocol), -Proxy (16) zwischen einem ersten Host (12), der nicht HIP-fähig bzw. nicht HIP-aktiviert ist und einem zweiten Host (14), der HIP-fähig bzw. HIP-aktiviert ist, wobei das Verfahren umfasst: Senden einer Anfrage von dem ersten Host zum Erlangen der Internet-Protokoll-, IP-, -Adresse des zweiten Hosts; in Ansprechen auf die Anfrage, Wiedererlangen einer IP-Adresse und einem Host-Identitäts-Tag, HIT (Host Identity-Tag), das in Verbindung steht mit dem zweiten Host; in Ansprechen auf die Wiedererlangung, Zurückgeben von dem HIP-Proxy, einer Substituts-IP-Adresse, die in Verbindung steht mit dem zweiten Host; Aufrechterhalten bei dem HIP-Proxy einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT; und bei Empfang einer Session-Initiierungs-Nachricht bei dem HIP-Proxy von dem ersten Host, einschließlich der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Aushandeln einer HIP-Verbindung zwischen dem HIP-Proxy und dem zweiten Host.
Ein Verfahren, wie in Anspruch 1 beansprucht, umfassend Nachschauen nach der wiedererlangten IP-Adresse und des wiedererlangten HIT von der Abbildung, basierend auf der Substituts-IP-Adresse in der Session-Initiierungs-Nachricht und Ausführen der HIP-Verhandlung, unter Verwendung der wiedererlangten IP-Adresse und des wiedererlangten HIT zum Lokalisieren und Identifizieren des Antwortenden in der HIP-Verhandlung zusammen mit einer IP-Adresse und HIT des Proxy zum Lokalisieren und Identifizieren des Initiators in der HIP-Verhandlung.
Ein Verfahren, wie in Anspruch 1 oder 2 beansprucht, wobei die wiedererlangte IP-Adresse die IP-Adresse eines weiterleitenden Agenten ist, die von dem zweiten Host verwendet wird, und ferner umfassend Initiieren der HIP-Verhandlung zwischen dem Proxy und dem zweiten Host durch Senden des Anfangs-HIP-Verhandlungspakets an den Weiterleitenden Agent bzw. Agenten.
Ein Verfahren, wie in Anspruch 3 beansprucht, ferner umfassend Nachfolgen des Empfangs der tatsächlichen IP-Adresse des zweiten Hosts an dem Proxy während der HIP-Verhandlung, einschließlich der tatsächlichen IP-Adresse in der Abbildung, die aufrechterhalten wird bei dem Proxy.
Ein Verfahren, wie in Anspruch 4 beansprucht, wobei die wiedererlangte IP-Adresse ersetzt wird in der Abbildung durch die tatsächliche IP-Adresse, nachfolgend von ihrem Empfang bei dem Proxy.
Ein Verfahren, wie in Anspruch 1 oder 2 beansprucht, wobei die wiedererlangte IP-Adresse die tatsächliche IP-Adresse des zweiten Hosts ist.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, umfassend ein Erzeugen der Substituts-IP-Adresse bei dem Proxy.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, ferner umfassend, für eine ausgehende Nachricht, die empfangen wird an dem Proxy, nachdem die HIP-Verbindung erstellt wurde, mit der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Umleiten der Nachricht über die HIP-Verbindung zu dem zweiten Host.
Ein Verfahren, wie in Anspruch 8 beansprucht, wenn abhängig von Anspruch 4, umfassend Nachschauen nach der tatsächlichen IP-Adresse und des wiedererlangten HIT von der Abbildung, basierend auf der Substituts-IP-Adresse, in der ausgehenden Nachricht, und Umleiten der ausgehenden Nachricht an den zweiten Host, unter Verwendung der tatsächlichen IP-Adresse und des wiedererlangten HIT zum Lokalisieren und Identifizieren des Ziels der Nachricht und Verwenden einer IP-Adresse und HIT des Proxy zum Lokalisieren und Identifizieren der Quelle der Nachricht.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, ferner umfassend Beenden des Einrichtens der Kommunikationsvorgänge zwischen dem ersten und zweiten Host durch Weiterleiten der Session-Initiierungs-Nachricht von dem Proxy zu dem zweiten Host über die HIP-Verbindung, Antworten mit einer Session-Bestätigungs-Nachricht von dem zweiten Host an den Proxy über die HIP-Verbindung, und Leiten der Session-Bestätigungs-Nachricht an den ersten Host.
Ein Verfahren, wie in Anspruch 10 beansprucht, wobei die Session-Bestätigungs-Nachricht eine TCP-ACK-Nachricht ist.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, wobei die Session-Initiierungs-Nachricht eine TCP-SYN-Nachricht ist.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, ferner umfassend für eine ankommende Nachricht, die empfangen wird bei dem Proxy von dem zweiten Host über die eingerichtete HIP-Verbindung, Verwenden einer NAT-Funktion des Proxy zum Umleiten der Nachricht an den passenden Ziel-Host.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, wobei die Anfrage eine DNS-Anfrage ist.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, wobei der Proxy den Schritt eines Wiedererlangens der IP-Adresse und HIT, im Zusammenhang stehend mit dem zweiten Host, ausführt.
Ein Verfahren, wie in Anspruch 15 beansprucht, wobei der Proxy die IP-Adresse und HIT, im Zusammenhang stehend mit dem zweiten Host, von einem externen DNS-Server wiedererlangt.
Ein Verfahren, wie in Anspruch 15 beansprucht, wobei der Proxy die IP-Adresse und HIT, im Zusammenhang stehend mit dem zweiten Host, von einem internen DNS-Server wiedererlangt.
Ein Verfahren, wie in einem der vorhergehenden Ansprüche beansprucht, wobei der Proxy die Anfrage von dem ersten Host abfängt.
Ein Kommunikationssystem, das einen ersten Host (12) umfasst, der nicht Host-Identitäts-Protokoll, HIP, aktiviert ist, sowie einen zweiten Host (14), der HIP-aktiviert bzw. HIP-fähig ist, und einen HIP-Proxy (16), wobei: der erste Host eine Einrichtung umfasst zum Senden einer Anfrage zum Erlangen der Internet-Protokoll-, IP, -Adresse des zweiten Hosts; der HIP-Proxy eine Einrichtung umfasst zum Wiedererlangen, in Ansprechen auf die Anfrage, einer IP-Adresse und eines Host-Identitäts-Tags, HIT, im Zusammenhang stehend mit dem zweiten Host, zum Zurückgeben, in Ansprechen auf die Wiedererlangung, einer Substituts-IP-Adresse, die im Zusammenhang steht mit dem zweiten Host, zum Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT, und zum Verwenden der Abbildung, bei Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP-Adresse als seine Zieladresse, zum Verhandeln einer HIP-Verbindung zwischen dem HIP-Proxy und dem zweiten Host.
Ein Verfahren zur Verwendung durch einen Host-Identitäts-Protokoll-, HIP, -Proxy (16), für ein mindestens teilweises Sicherstellen von Kommunikationsvorgängen, über den HIP-Proxy, zwischen einem ersten Host (12), der nicht HIP-aktiviert bzw. nicht HIP-fähig ist, und einem zweiten Host (14), der HIP-aktiviert bzw. HIP-fähig ist, das Verfahren umfassend: Empfangen einer Anfrage von dem ersten Host zum Erlangen der Internet-Protokoll-, IP, -Adresse des zweiten Hosts; in Ansprechen auf die Anfrage, Wiedererlangen einer IP-Adresse und eines Host-Identitäts-Tags, HIT, im Zusammenhang stehend mit dem zweiten Host; in Ansprechen auf die Wiedererlangung, Zurückgegeben einer Substituts-IP-Adresse, im Zusammenhang stehend mit dem zweiten Host, und Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der erlangten IP-Adresse und des erlangten HIT; und beim Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP-Adresse als seine Zieladresse, Verwenden der Abbildung zum Verhandeln einer HIP-Verbindung zwischen dem HIP-Proxy und dem zweiten Host.
Ein Host-Identitäts-Protokoll-, HIP, -Proxy (16) zur Verwendung in mindestens einem teilweise Sicherstellen von Kommunikationsvorgängen, über den HIP-Proxy, zwischen einem ersten Host (12), der nicht HIP-aktiviert bzw. nicht HIP-fähig ist, und einem zweiten Host (14), der HIP-aktiviert bzw. HIP-fähig ist, umfassend: eine Einrichtung zum Empfangen einer Anfrage von dem ersten Host zum Erlangen der Internet-Protokoll-, IP, -Adresse des zweiten Hosts; eine Einrichtung zum Wiedererlangen, in Ansprechen auf die Anfrage, einer IP-Adresse und eines Host-Identitäts-Tags, HIT, im Zusammenhang stehend mit dem zweiten Host, zum Zurückgeben, in Ansprechen auf die Wiedererlangung, einer Substituts-IP-Adresse, die im Zusammenhang steht mit dem zweiten Host, und Aufrechterhalten einer Abbildung zwischen der Substituts-IP-Adresse, der wiedererlangten IP-Adresse und des wiedererlangten HIT; und eine Einrichtung zum Verwenden der Abbildung, beim Empfang einer Session-Initiierungs-Nachricht von dem ersten Host mit der Substituts-IP-Adresse als seine Zieladresse, zum Verhandeln einer HIP-Verbindung zwischen dem HIP-Proxy und dem zweiten Host.
Ein Computerprogramm, das, wenn es auf einem HIP-Proxy läuft, bei dem Proxy hervorruft, ein Verfahren, wie in Anspruch 20 beansprucht, auszuführen.
Ein Computerprogramm, das, wenn es in ein HIP-Proxy geladen wird, bei dem Proxy hervorruft alle die Merkmale eines HIP-Proxy, wie in Anspruch 21 beansprucht, einzubeziehen.
Ein Computerprogramm, wie in Anspruch 22 oder 23 beansprucht, das ausgeführt wird auf einem Trägermedium.
Ein Computerprogramm, wie in Anspruch 24 beansprucht, wobei das Trägermedium ein Übertragungsmedium ist.
Ein Computerprogramm, wie in Anspruch 24 beansprucht, wobei das Trägermedium ein Speichermedium ist.