Christophe Jelger – CS221 Network and Security - Universität Basel - 20051 Christophe Jelger Post-doctoral researcher [email protected] IP Multicasting

Christophe Jelger – CS221 Network and Security - Universität Basel - 2005 1

Christophe Jelger

Post-doctoral researcher

[email protected]

IP Multicastingand

Mobile IP

2 Christophe Jelger – CS221 Network and Security -

Universität Basel - 2007

Plan

IP MulticastGeneral conceptSubscriptions (IGMP, MLD)Multicast routing Shared trees Source-based trees

Mobile IPGeneral conceptMobile IPv4Mobile IPv6



IP Multicast

Group communications at the network layer

IP Multicast Mobile IP



Unicast streaming

011010011010011010

011010



Multicast streaming

011010

011010011010 011010011010

011010011010Multicast Tree



IPv4Class-D addresses: 224.0.0.0 to 239.255.255.255 (224.0.0.0/28, or 16 Class-A networks !)Some special addresses … 224.0.0.1 = all multicast-capable hosts 224.0.0.2 = all multicast routers 224.0.0.13 = all PIM routers

IPv6ff0x::/8 where x is the scope (2=local, 5=site, e=global)Some special addresses … ff02::1 all nodes on link, ff02::2 all routers on link ff02::16 all MLDv2 multicast routers ff02::d all PIM multicast routers

IP Multicast: address range (see http://www.iana.org)



IPv4Ethernet multicast (first 24 bits): 01:00:5E + 0 for 25th bit 23 bits available to map the IPv4 address to an Ethernet address the least significant bits are mapped Ex: 224.129.47.23 01:00:5E:01:2F:17

IPv6Ethernet multicast (first 16 bits): 33:33 32 bits available to map the IPv6 address the least significant bits are mapped Ex: ff05::207:85ff:fe92:7ff8 33:33:fe:92:7f:f8

In both cases, the Ethernet layer acts as an imperfect filter

IP Multicast: IP to Ethernet mapping



IPv4 : Internet Group Membership Protocol (IGMP)IPv6 : Multicast Listener Discovery (MLD)

Objective: a multicast router must periodically discover nodes that want to join a certain group

The router can then join the appropriate multicast delivery treeThe router only needs to know if there is some interest for a group: it does not need to know exactly how many nodes are interestedThere exists different versions of IGMP and MLD: the main difference is the ability to perform "source-filtering" (so that only the traffic sent by a (some) given source(s) is received)

IP Multicast: Step 1 group subscription



IP Multicast: group subscription with MLD(subscription with IGMP is similar)

Group: ff0e::1234:5678/64 MAC : 33:33:12:34:56:78

MLDQuery

Multicast router

MLD Reportff0e::1234:5678

JOIN multicast groupff0e::1234:5678

Multicast DATA sent to 33:33:12:34:56:78 / ff0e::1234:5678



Objective is to build the multicast delivery tree(s)Two families of trees:

Shared-trees (*,G): the tree is shared by all (*) multicast sources sending to group GSource-based trees (S,G): only a given source S can send multicast data on the delivery tree for group G

There has been many protocols for multicast routing, but today the only protocol deployed is PIM:

Protocol Independent MulticastPIM-SM: Sparse-Mode (shared trees)PIM-SSM: Source-Specific Multicast (source-based trees)

IP Multicast: Step 2 Multicast routing



1

4

3

2 5

6

7

1

5

6

7

Shared tree (PIM-SM)

IP Multicast: Step 2 Multicast routing

1

4

3

2 5

6

7

1

5

6

7

Source-based tree (PIM-SSM)

1

2

3

4 6

7

Source S1

PIM router with group member(s)

PIM JOIN message

Source S1

Source S2

1

2

3

4 6

7

Rendez-VousPoint

(S1,G)(S1,G)

(S2,G)

(*,G)



IP Multicast is very suitable forGroup communications with multiple sources and receivers (shared tree): known as N-to-M communication Video-conferencing, network games

Group communications with one source and multiple receivers (source-based tree): known as 1-to-M communication TV and radio streaming, content distribution

Current deployment of IP Multicast is not largeLack of security: a misbehaving user can create forwarding states by joining hundreds of groupsBilling: who should pay for what ?Source discovery accross AS (Autonomous Systems) is complex

IP Multicast: some conclusions



Mobile IP

Adding mobility at the network layer

IP Multicast Mobile IP



Users are becoming mobile

World-wide availability of popular wireless communication technologies

More and more portable wireless devices are also available, and they become really powerful



Problems introduced by mobilityWhen a mobile node moves to a visited network, how is it possible to reach it again ? What about current on-going connections ? (with TCP, IP addresses partly identifies a connection)

Objectives of Mobile IPTo permit that a mobile node becomes reachable when it is in a visited networkTo allow on-going connections to be maintained when the mobile node is moving

Mobile IP



Mobile IPv6: basic mechanisms

Home networkIntern

et

Binding UpdateMessage (H@

CoA)

Visited network

Home agent

Correspondant

Sending to H@

Access point

The mobile node main address is the home

address (H@)The mobile node

obtains an address in the visited network: the care-of address (CoA)



Mobile IPv6: route optimization

Home networkIntern

et

Visited network

Home agent

Correspondant

Access point

Correspondant

Sending to H@

via CoA

Binding Update

Message (H@ CoA)



IPv4: tunnelingA packet sent by or to the mobile node's home address is encapsulated in another packet sent by or to the CoA

IPv6: routing header and home address optionVia the home agent, tunneling is usedWith route optimization, a packet sent to the mobile node's home address is replaced by a packet sent to the CoA which also contains a routing header equal to the H@A packet sent by the mobile node always uses the CoA as source address, and it contains a home address option equal to H@

Mobile IP: maintaining TCP connections



DeploymentMobile IP has failed to be widely deployed because until recently it suffered from serious security problems: authentication is indeed critical so that a malicious user cannot register a bogus CoA with a home agent

UsageThe "always-on" paradigm is not a reality yetThe need for Mobile IP is not mature enough

Mobile IP: some conclusions

Documents

Christophe Jelger – CS221 Network and Security - Universität Basel - 20051 Christophe Jelger Post-doctoral researcher [email protected] IP Multicasting