32
Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

Embed Size (px)

Citation preview

Page 1: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

Mobile IPv6

Dr. Hannes Hartenstein

NEC Europe Ltd., Heidelberg

Sommersemester 2001,

Universität Mannheim

Page 2: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 2

Struktur der Vorlesung

• Ausgangspunkt:– IPv6: viele Verbesserungen gegenüber IPv4.– IPv6: bessere Unterstützung von Mobilität.

• Deshalb: Kurze Einführung in IPv6:– Motivation– Adressen-Raum– Extension Headers– Nachbar-Erkennung– Adressen Autokonfiguration

• Mobile IPv6:– Wesentliche Änderungen gegenüber MIPv4– Details

Page 3: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 3

Warum IPv6?• Skalierungsprobleme mit IPv4 Unicast-Adressen:

– ‘Class C’ Adressen Blöcke für viele Sites zu klein.

– Jeder versucht, ‘Class B’ Blöcke zu bekommen; dadurch “address depletion problem”.

– Werden viele ‘Class C’ Adressen vergeben, wachsen die Routing Tables schnell an: “scaling in routing problem”.

– Kurzfristige Lösungen: CIDR (supernetting) und NAT.

• Hauptmotivation für IPv6 deshalb die Einrichtung eines grösseren Adress-Raumes.

• Gleichzeitig: ‘Fehler’ in IPv4 können behoben werden.• Wesentliche Entscheidungen schon 1992-1994.• “The next generation of the Internet Protocol (IPv6) is intended to support

Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service.”

Page 4: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 4

IPv6 Adressen Architektur

• IPv6 Adresse: 128 bits für ein Interface.• (340282366920938463463374607431768211456 addresses)

• Typische Schreibweisen:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

1080:0:0:0:8:800:200C:417A

• Kurzschreibweisen:

1080::8:800:200C:417A

• Unicast/Anycast/Multicast Adressen.– Keine Broadcast Adresse.

• IPv4 Adressen in IPv6: ‘96 trailing zeros’.

Page 5: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 5

Format Prefix

Allocation Prefix Fraction of (binary) Address Space ----------------------------------- -------- ------------- Reserved 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 Unassigned 0000 010 1/128 Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Aggregatable Global Unicast Addresses 001 1/8 Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link-Local Unicast Addresses 1111 1110 10 1/1024 Site-Local Unicast Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256

Page 6: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 6

‘Link-local’ und ‘Site-local’

• ‘Link-local’ Adressen: when kein Router vorhanden ist oder während Adressen Autokonfiguration.

• ‘Site-local’ Adressen: für Sites, die (noch) nicht am Internet angeschlossen sind.

1111 1110 10 0 interface

1111 1110 11 0 subnet interface

... Pakete, die zu diesen Adressen gesendet werden, werden von einem Router nicht weitergeleitet.

• Bemerkung: ‘multi-homing’ wird Standardsituation in IPv6.

Page 7: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 7

Aggregatable Global Unicast AddressesThe aggregatable global unicast address format is as follows:

| 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+

<--Public Topology---> Site <--------> Topology <------Interface Identifier----->

Where

FP Format Prefix (001) TLA ID Top-Level Aggregation Identifier RES Reserved for future use NLA ID Next-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier INTERFACE ID Interface Identifier

aus: RFC 2374

Page 8: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 8

Besondere Adressen

• unspecified address: 0:0:0:0:0:0:0:0• loopback: 0:0:0:0:0:0:0:1• multicast addresses: z.B.:

– ‘all nodes’– ‘all routers’– ‘solicited node’; wird von Unicast Adresse

abgeleitet.

| 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+

Multicast address format:

Page 9: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 9

IPv6 Header Format

v class

next headerpayload length

flow label

hop limit

128 bitssource address

128 bitsdestination address

0 4 8 16 24 31123

7

10

Version HLen TOS Length

Ident Flags Offset

TTL Protocol Checksum

SourceAddr

DestinationAddr

Options (variable) Pad(variable)

0 4 8 16 19 31

Data

IPv4 IPv6

IPv4 header: 20 Bytes ohne Optionen, IPv6 header: 40 bytes.

Page 10: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 10

Extension Headers

• ‘Options’ jetzt in Extension Headers.– Vermeidung von unnötigem Prozessierungs-Aufwand bei

zwischenliegenden Routern.

• Extension Header Typen:– Hop-by-Hop Options: Information, die von jedem

zwischenliegenden Router prozessiert werden soll.– Routing (Type 0): verbessertes ‘source routing’ von IPv4.– Fragment: IPv6 Router fragmentieren nicht; Fragmentierung

muss an der Quelle geschehen.– Destination Options: Information für den ‘destination node’.– Authentication– Encapsulating Security Payload

IPsec header

Page 11: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 11

Reihenfolge der Extension Headers

• IPv6 Header• Hop-by-Hop Options Header• Destination Options Header(*)• Routing Header• Fragment Header• Authentication Header• ESP Header• Destination Options Header• Upper Layer Header

Page 12: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 12

Extension Header Beispiel

IPv6 headernext: UDP

UDP header+ data

IPv6 headernext: FragHdr

UDP header+ data

Frag. headernext: UDP

IPv6 headernext: FragHdr

UDP header+ data

Frag. headernext: DestHdr

Destination headernext: UDP

Page 13: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 13

Authentication Header

• Teil der allgemeinen IPsec Architektur (RFC 2401).

• AH ‘verantwortlich’ für– Daten-Integrität.– Authentication.– Replay Protection.

• Wichtig für uns: Integrity Check Value umfasst IPv6 Source und Destination Adress!

• Also: ein ‘geschütztes’ Paket darf nicht verändert werden.

Page 14: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 14

Neighbor Discovery

• Neighbor:Knoten am selben Link.• IPv6 Neighbor Discovery (RFC 2461) “fasst

IPv4 ARP + IPv4 Router Discovery zusammen.”

• Adressen Auflösung:– Knoten sendet eine neighbor solicitation message an die

entsprechende solicitated node multicast address.– (FF02:0:0:0:0:1:FF00:0/104 + die letzten 24 bits der IPv6

Adresse).– Entsprechende Link-Layer Multicast Adresse wird durch

einen Link-spezifischen Algorithmus bestimmt.

• Vorteil: ‘höheres’ Abstraktionsniveau!

Page 15: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 15

Adressen Autokonfiguration

• ‘Stateful autoconfiguration ‘ via DHCPv6.• ‘Stateless autoconfiguration’ (RFC 2462):

– Generieren einer ‘link-local’ Adresse durch Interface ID und ‘link-local’ Prefix.

– Duplicate Address Detection• Senden einer ‘Neighbor Solicitation’ mit der generierten

Adresse als Ziel-Adresse.

– Falls ‘host’: ‘Router advertisement’ abwarten bzw. anfordern. Falls ‘stateless autoconfig’ erlaubt, kann aus Prefix Information eine ‘site-local’ oder ‘global’ Adresse generiert werden.

Page 16: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 16

Quellen für IPv6 Informationen

• www.ietf.org: Working Group ‘ipng’.• Christian Huitema: “IPv6 -The New Internet

Protocol”, Prentice-Hall, 1998.

Page 17: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 17

Mobile IPv6

Siehe:

draft-ietf-mobileip-ipv6-13.txtDave Johnson (Rice University)Charles Perkins (Nokia)17. November 2000

Page 18: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 18

MIPv6: Routen-Optimierung integriert

• Annahme: CN kennt CoA des Kommunikations-Partners.• Dann: CN schickt Pakete direkt an CoA mittels ‘Routing

Header’.• Vorteil Routing Header gegenüber Tunneling: weniger

Overhead.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 header:dest. address=

CoA

= home address

weitere Header+ Payload

Page 19: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 19

MIPv6: Wie lernt CN die CoAs?

• Jeder CN unterhält einen ‘binding cache’, in dem CoAs von Kommunikations-Partnern verwaltet werden.

• Falls für einen MN kein Eintrag in dem binding cache vorhanden ist, schickt der CN das Paket als ‘Standard-IPv6’ Paket an die ‘home address’.

• Der Home Agent im Heimatnetz tunnelt das Paket zum MN.– Wegen AH/ESP kann kein source routing (routing header)

verwendet werden.

• Der MN bemerkt, dass der CN keinen bindig cache Eintrag hat, und schickt ein ‘binding update’ (BU).

Page 20: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 20

MIPv6: HAs und CNs

• MIPv6 HA und CN ‘ähnlich’:– beide verwalten ‘mobility bindings’.

• Deshalb: statt ‘registration requests’ (IPv4) jetzt nur noch ‘binding updates’, sowohl für HA als auch CN.

• Aber: an HA werden höhere Anforderungen gestellt.– muss ‘primary care-of-address’ verwalten!– muss Pakete abfangen & verkapseln können.– muss ‘dynamic home agent discovery’ unterstützen.

• schützt vor ‘single-point-of-failure’ Problem.

• Um sicher zu gehen, dass der HA ein Binding unterhält, gibt es zu dem BU ein BU ACK.

Page 21: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 21

MIPv6: BU, BU ACK, BU Request (1)

BU, BU ACK und BU Request sind IPv6 Destination Options. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|Reservd| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+-

+-+-+-+-+-+-+-+-+ | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+-

BU

BU ACK

Page 22: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 22

• Mit einem BU Request kann ein CN die derzeit gültige CoA eines MN anfordern.

• Da BU, BU ACK und BU Request IPv6 Destination Options sind, können diese Nachrichten per ‘piggybacking’ Mechanismus transportiert werden.

• Kein UDP wie in IPv6!• Müssen mit AH gesichert werden.

MIPv6: BU, BU ACK, BU Request (2)

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Option Type | Option Length | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

BU Request

Page 23: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 23

MIPv6: Home Address Option

• Zur Umgehung des Ingress-Filtering Problems.• CoA als ‘source address’; home address in Home Address

Option, eine IPv6 Destination Option.• ‘... making the use of the care-of address transparent to the

corresponding node.’• Jeder IPv6 Knoten muss diese Option prozessieren können.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+-

Page 24: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 24

Movement Detection

• In MIPv6 gibt es keine FAs mehr, da ‘Stateless Autoconfiguration’ und ‘Neighbor Discovery’ die nötigen Aufgaben beherrschen.

• Die Movement Detection basiert auf:– ‘lower protocol layers’, nicht Teil des MIPv6 Drafts.– Router Advertisements wie in IPv6 Neighbor Discovery

definiert; Router Advertisements beinhalten on-link subnet prefixes.

– MN kann Router Solicitation senden.• Drahtlose Kanäle oft asymmetrisch: Kontrolle nötig, dass beide

Richtungen MN Default Router funktionieren.– Default Router zu MN: via periodische Router Adv.– MN zu Default Router: ‘Neighbor Unreachability Detection’.

Page 25: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 25

Bilden der CoA

• Router Advertisements beinhalten subnet prefix.

• ‘Statefull’ oder ‘Stateless’ Autoconfiguration.– Auch ‘pre-assigned’ IPv6 Adresse möglich.

• Duplicate Address Detection:– Tradeoff zwischen ‘Sicherheit’ und ‘Overhead’

bzw. Geschwindigkeit.– Draft erlaubt das Verwenden eine IPv6 Adresse

ohne vorherige DAD.

Page 26: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 26

Dynamic Home Agent Discovery

• Für den Fall, dass MN keinen HA im Heimatnetz kennt.– Z.B. wenn eigentlicher HA vorübergehend nicht

arbeitet.

• Discovery Request an ‘Mobile IPv6 Home-Agents anycast address.’

Page 27: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 27

Smooth Handoff

• Aufsetzen eines ‘Bindings’ zwischen vorheriger CoA und aktueller CoA.

• Verhinder Paketverlust von ‘packets on the fly’.

• MN schickt BU an HA am vorherigen Link.– Durch die Router Adv. am ‘alten’ Link sollte der

MN den HA kennen.

Page 28: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 28

Zusammenfassung MIPv6 (1)• 4 neue IPv6 Destination Options:

– BU– BU ACK– BU Request– Home Address Option

• Signalisierung in L3 integriert; MIPv6 echter L3 Entwurf.• I.A. kein ‘triangle routing’.• I.A. ‘source routing’ statt ‘tunneling’.• Keine Ingress Filtering Probleme.• CN, HA, vorheriges Netz werden ‘gleichbehandelt’.• Keine FAs nötig.• Bottleneck Problem bzgl. HA durch HA address discovery

gelöst.• Sicherheit durch IPsec.

Page 29: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 29

• Wesentlicher Unterschied zu MIPv4: Nach Handoff muss nicht nur der HA über neue CoA informiert werden.

• Dafür effizienter durch’piggybacking’.

Zusammenfassung MIPv6 (2)

Page 30: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 30

Kommt MIPv6?

• Jeder IPv6 Knoten muss ‘home address option’ prozessieren können. Jeder IPv6 Knoten sollten einen ‘binding cache’ haben.

• Kommt IPv6?• ‘Killer App könnte 3G/4G sein (aber frühestens Rel x).

– Die Anzahl von Cell Phones kann nicht mit IPv4 adressiert werden ...

– Rel 5 *ohne* Mobile IPv6!!!• 3GPP2 arbeitet bislang aktiver mit IETF zusammen als 3GPP...

– aber neues ‘Agreement’: “3GPP-IETF Standardization Collaboration”, RFC 3113, June 2001.

• MWIF (Mobile Wireless Internet Forum) arbeitet an IP-basierter Architektur für 3G.

Page 31: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 31

S35

S19

S14Global NameServer

Directory ServicesS26

S16

S25

S13

S53

PolicyRepository

S57S55

AAA Functional Entities

S15

S44B10S31 S43

S33

S39

S37

S11

S47

Operations, Administration, Maintenance & Provisioning

S67

BillingManagemen t

S63 S64 S66 S65

Con figu rationManagemen t

FaultManagemen t

PerformanceManagemen t

SecurityManagemen t

Access Network

B08User

IdentityModule

S68

Core Network Functional Entities

MAPNetwork

S45S46

SignallingGateway

B06

PSTN

MediaGateway

B05 B05B05

IntranetInternet

EnterpriseNetwork

CollectiveNetwork

Funct ionalEntity

Network

KeySnn Bnn

R eference Poi n t(Signall ing)

R eference Poi n t(User Dat a B ea re r)

A reference poi n t t o a co ll ect ive goes to e ve ry net work funct ional en ti ty wi th in t he c ol le cti ve

S30

S41

S41

S41

ServiceDiscovery

Server

LocationServer

S58

B01

Prof ileServer

IPAddressManager

S36

GeographicLocationManager

S38

Transport Gateway FEs

S40

S34 MobileAttendant

Home IPAddressManager

Access Gateway

S23

B03

MultimediaResourceFunct ion

B02

B07

Router

Core NetworkApplication

Application Funct ional Ent it ies

AuthorisationServer

ResourceDirectory

S24

S12

S42

S52

AccountingServer

S56

AuthenticationServer

Third PartyApplication

AccessTransportGateway

S28

ResourceManager

S21

S27

B09IP

GatewayB04

S59

S41

S41 S41

S41S29

S32

S54

S20

S17

S51HomeMobilityManager

S50

SessionAnchor

S48

S49

SessionProxy

S18

MediaGateway

Controller

MultimediaResourceController

CommunicationSession

Manager

S62S61S60

Terminal

CN Inter worki ng Functi ons

S22

MWIFArchitektur-Vorschlag

Page 32: Mobile IPv6 Dr. Hannes Hartenstein NEC Europe Ltd., Heidelberg Sommersemester 2001, Universität Mannheim

June 2001 H. Hartenstein: MobileIPv6 32

Kommt MIPv6?

• Sicherheit das wohl grösste Problem.• Derzeitige Hauptarbeitsgebiete in IETF:

– Localized Mobility Management– Fast Handoffs– Paging