1 / 33

Network Layer and Mobile IP

Network Layer and Mobile IP. Motivation for Mobile IP. Routing based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet. Motivation for Mobile IP. Routing based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet

lynne
Télécharger la présentation

Network Layer and Mobile IP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Network Layer and Mobile IP

  2. Motivation for Mobile IP • Routing • based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet

  3. Motivation for Mobile IP • Routing • based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables

  4. Motivation for Mobile IP • Routing • based on IP destination address, network prefix (e.g. 129.13.42) determines physical subnet • change of physical subnet implies change of IP address to have a topological correct address (standard IP) or needs special entries in the routing tables • Keeping the IP address while moving • Specific routes to end-systems • change of all routing table entries to forward packets to the right destination • does not scale with the number of mobile hosts and frequent changes in the location, security problems • Changing the IP address • adjust the host IP address depending on the current location • almost impossible to find a mobile system, DNS updates take a long time • TCP connections break, security problems

  5. Requirements of Mobile IP (RFC 3344, was: 3220, was: 2002) • Transparency • mobile end-systems keep their IP address • continuation of communication after interruption of link possible • point of connection to the fixed network can be changed • Compatibility • support of the same layer 2 protocols as IP • no changes to current end-systems and routers required • mobile end-systems can communicate with fixed systems • Security • authentication of all registration messages • Efficiency and scalability • only little additional messages to the mobile system required (connection typically via a low bandwidth radio link) • world-wide support of a large number of mobile systems in the whole Internet

  6. Terminology • Mobile Node (MN) • system (node) that can change the point of connection to the network without changing its IP address • Home Agent (HA) • system in the home network of the MN, typically a router • registers the location of the MN, tunnels IP datagrams to the COA • Foreign Agent (FA) • system in the current foreign network of the MN, typically a router • forwards the tunneled datagrams to the MN, typically also the default router for the MN • Care-of Address (COA) • address of the current tunnel end-point for the MN • Foreign agent COA: Many MN using the FA can share this COA • Co-located COA: MN temporarily acquired an additional IP address which acts as COA (can be chosen, e.g., via DHCP) • actual location of the MN from an IP point of view • Correspondent Node (CN): communication partner

  7. Example network HA MN Internet router home network mobile end-system (physical home network for the MN) FA foreign network router (current physical network for the MN) CN end-system router

  8. Example network HA MN Internet router home network mobile end-system (physical home network for the MN) FA foreign network router (current physical network for the MN) CN end-system router

  9. Data transfer to the mobile system HA 2 MN Internet home network 3 receiver foreign network FA 1. Sender sends to the IP address of MN, HA intercepts packet (proxy ARP) 2. HA tunnels packet to COA, here FA, by encapsulation 3. FA forwards the packet to the MN 1 CN sender

  10. Data transfer from the mobile system HA 1 MN Internet home network sender FA foreignnetwork 1. Sender sends to the IP address of the receiver as usual, FA works as default router CN receiver

  11. Overview COA foreign network router FA MN home network router HA Internet CN router foreign network 3. router FA MN home network router HA 2. 4. Internet 1. CN router

  12. Network integration • Agent Advertisement • HA and FA periodically send advertisement messages into their physical subnets (ICMP packets) • MN listens to these messages and detects, if it is in the home or a foreign network (standard case for home network) • MN reads a COA from the FA advertisement messages • Registration (always limited lifetime!) • MN signals COA to the HA via the FA, HA acknowledges via FA to MN • these actions have to be secured by authentication • Advertisement • HA advertises the IP address of the MN (as for fixed systems), i.e. standard routing information • routers adjust their entries, these are stable for a longer time (HA responsible for a MN over a longer period of time) • packets to the MN are sent to the HA, • independent of changes in COA/FA

  13. ICMP Router Discover Message, RFC 1256: Enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. type = 9, code = 0; agent routes traffic from mobile & non-mobile nodes Lifetime : length of time this advertisement is valid Preference level : how eager the router is to get a new node ICMP packets type = 16; agent does not route anything other than mobile traffic length = 6 + 4 * #COAs Sequence Number: The count of Agent Advertisement messages sent since the agent was initialized. Registration Lifetime: The longest lifetime (in seconds) that this agent is willing to accept in any Registration Request. A value of 0xffff indicates infinity Agent advertisement 0 7 8 15 16 23 24 31 type code checksum #addresses addr. size lifetime router address 1 preference level 1 router address 2 preference level 2 . . . type = 16 length sequence number T registration lifetime R B H F M G r reserved COA 1 COA 2 R: registration required B: busy, no more registrations H: offers home agent services F: offers foreign agent services M: minimal encapsulation G: GRE encapsulation r: =0, ignored T: FA supports reverse tunneling reserved: =0, ignored

  14. Registration MN HA MN FA HA registration request registration request registration request registration reply registration reply t COA is co-located MN sends request directly HA and vice versa. Same registration procedure is used for MNs returning to their home network If the MN received an agent advertisement from the FA it should register via this FA if R bit is set in the advertisement registration reply t • COA is at the FA • MN sends registration request containing the COA to FA which forwards the request to HA • HA sets up a mobility binding • Mobile node’s home IP address and current COA • Lifetime of registration

  15. IP Packet Format • Datagram format (20 to 24 bytes) • Version • HLen: length of header in 32-bit words • TOS, Type of Service: allow packets to be treated differently based on application needs • Length: bytes of datagram (including header, max 65,535) • Indent, Offset , Flag: information used for fragmentation • TTL, time to live: discard looping packets; 64 is the current default • Protocol: higher-level protocol (TCP = 6, UDP =17, …) • Checksum: calculated for IP header considered as a sequence of 16-bit words • SourceAddr, DestinationAddr: IP defines its own global address space, independent of physical networks • Options, Pad: rarely use

  16. S B D M G r UDP packet is used ( low overheads & better performance compared to TCP in wireless environments) 0 7 8 15 16 23 24 31 UDP destination port: 434 type = 1 T x lifetime home address home agent COA identification extensions . . . UDP data: fields relevant for mobile IP registration requests Protocol Field = 17 MN IP Packet carrying the UDP packet Header Format FA or HA (depending on the location of the COA) Mobile IP registration request

  17. S B D M G r 0 7 8 15 16 23 24 31 type = 1 T x lifetime home address home agent COA identification S:MN wants HA to retain prior mobility bindings (simultaneous bindings) B: MN wants to receive the broadcast packets which have been received by HA in home network D: MN uses a co-located COA & takes care of de-capsulation at tunnel endpoint M: minimal encapsulation is used G: generic encapsulation routing is used r: =0, ignored T: reverse tunneling requested x: =0, ignored Lifetime: validity of the registration in seconds (zero indicates deregistration; all bits set indicates infinity) home address: the fixed IP address of MN home agent: the IP address of HA COA : tunnel endpoint identification: 64 bit generated by MN to identify a request and match it with registration replies used for protection against replay attacks of registrations extensions : contain at least parameters for authentication. extensions . . . Mobile IP registration request (cont.)

  18. 0 7 8 15 16 31 type = 3 code lifetime home address home agent identification extensions . . . Mobile IP registration reply lifetime: how many seconds the registration is valid if (successful) homeaddress: address of MN homeagent: addresses HA • Example codes: • registration successful • 0 registration accepted • 1 registration accepted, but simultaneous mobility bindings unsupported • registration denied by FA • 65 administratively prohibited • 66 insufficient resources • 67 mobile node failed authentication • 68 home agent failed authentication • 69 requested Lifetime too long • registration denied by HA • 129 administratively prohibited • 130 insufficient resources • 131 mobile node failed authentication • 132 foreign agent failed authentication • 133 registration Identification mismatch • 135 too many simultaneous mobility bindings identification: 64-bit, used to match registration requests with replies (value based on identification field from the registration and the authentication method) extensions: must at least contain parameters for authentication

  19. Overview COA foreign network router FA MN home network router HA Internet CN router foreign network 3. router FA MN home network router HA 2. 4. Internet 1. CN router

  20. Encapsulation original IP header original data new IP header new data outer header inner header original data foreign network 3. router FA MN home network router HA 2. 4. Internet 1. CN router

  21. IP Header • Datagram format (20 to 24 bytes) • Version • HLen: length of header in 32-bit words • TOS, Type of Service: allow packets to be treated differently based on application needs • Length: bytes of datagram (including header, max 65,535) • Indent, Offset , Flag: information used for fragmentation • TTL, time to live: discard looping packets; 64 is the current default • Protocol: higher-level protocol (TCP = 6, UDP =17, …) • Checksum: calculated for IP header considered as a sequence of 16-bit words • SourceAddr, DestinationAddr: IP defines its own global address space, independent of physical networks • Options, Pad: rarely use

  22. ver. IHL DS (TOS) length IP identification flags fragment offset TTL IP-in-IP IP checksum IP address of HA Care-of address COA ver. IHL DS (TOS) length IP identification flags fragment offset TTL lay. 4 prot. IP checksum IP address of CN IP address of MN TCP/UDP/ ... payload Encapsulation I • Encapsulation of one packet into another as payload • e.g. IPv6 in IPv4 (6Bone), Multicast in Unicast (Mbone) • here: e.g. IP-in-IP-encapsulation, minimal encapsulation or GRE (Generic Record Encapsulation) • IP-in-IP-encapsulation (mandatory, RFC 2003) • tunnel between HA and COA • outer header: ver.: 4 ; P-in-IP: 4 • DS(TOS):copied from inner header. • length: covers complete encapsulated packet • IP identification, flags, fragment offset: no special meaning for mobile IP and are set according to RFC 791 • inner header • Only TTL is changed (decremented by 1) • Packet is just one (logical) hop away for the MN

  23. IP-in-IP ver. IHL DS (TOS) length Minimal encapsulation IP identification flags fragment offset ver. IHL DS (TOS) length TTL IP-in-IP IP checksum IP identification flags fragment offset IP address of HA TTL min. encap. IP checksum Care-of address COA IP address of HA ver. IHL DS (TOS) length care-of address COA IP identification flags fragment offset lay. 4 protoc. S reserved IP checksum TTL lay. 4 prot. IP checksum IP address of MN IP address of CN original sender IP address (if S=1) IP address of MN TCP/UDP/ ... payload TCP/UDP/ ... payload Encapsulation II • Minimal encapsulation (optional) • avoids repetition of identical fields • e.g. TTL, IHL, version, DS (RFC 2474, old: TOS) • only applicable for unfragmented packets, no space left for fragment identification • min. encap. = 55

  24. original header original data may be copied from original IP header outer header GRE header originalheader original data 47 new header new data IP address of HA protocol checksum (optional) Generic Routing Encapsulation GRE: allows encapsulation of packets of one protocol into payload portion of a packet of another protocol (not only IP packets in IP packets) RFC 1701 ver. IHL DS (TOS) length C: checksum contains valid information (a valid IP checksum of GRE header and payload) R: offset and routing fields are present offset: offset in bytes for the first source routing entry routing: has a variable length and contains fields for source routing K : key field may be used for authentication S: sequence number field is present; also strict source routing is used rec.: a counter; number of allowed recursive encapsulations; When a packet arrives at an encapsulator If not zero, packet is encapsulated and field decremented by one rsv : 0; ignored ver : GRE version; 0 protocol : protocol of packet following GRE header; 0 x 800 for IP IP identification flags fragment offset TTL GRE IP checksum Care-of address COA C R K S s rec. rsv. ver. offset (optional) key (optional) sequence number (optional) routing (optional) ver. IHL DS (TOS) length IP identification flags fragment offset TTL lay. 4 prot. IP checksum IP address of CN IP address of MN TCP/UDP/ ... payload

  25. RFC 2784 C reserved0 ver. protocol checksum (optional) reserved1 (=0) Generic Routing Encapsulation (cont) • simplified header of GRE following RFC 2784 • more generalized version of GRE compared to RFC 1701 C: checksum & reserved1 are present next 5 bits: zero ver : 0 protocol: protocol of payload following RFC 3232

  26. Optimization of packet forwarding • Triangular Routing • sender sends all packets via HA to MN • higher latency and network load • “Solutions” • sender learns the current location of MN • direct tunneling to this location • HA informs a sender about the location of MN • big security problems! • Change of FA • packets on-the-fly during the change can be lost • new FA informs old FA to avoid packet loss, old FA now forwards remaining packets to new FA • this information also enables the old FA to release resources for the MN

  27. home network receiver Reverse tunneling (RFC 3024, was: 2344) HA 2 MN Internet 1 sender FA foreignnetwork 1. MN sends to FA 2. FA tunnels packets to HA by encapsulation 3. HA forwards the packet to the receiver (standard case) 3 CN Agent Advertisements can carry requests for reverse tunneling

  28. Why Reverse Tunneling? • MN sends packets through FA; assumes routing is independent of source address • Assumption is not always true • Example: Firewalls filter packets coming from outside containing a source address from computers of the internal network • MN cannot send a packet to a computer residing in its home network • Solution: a topologically correct reverse tunnel from COA to HA • a packet from the MN encapsulated by the FA is now topological correct

  29. Why Reverse Tunneling? II • Allow MN to participate in a multi-cast group • MN in a foreign network needs a a reverse tunnel to transmit multi-cast packets in a way that they emanate from its home network • Allow MN to use same TTL as when in Home network • TTL might be low so that no packet is transmitted outside a certain region • From a foreign network, this TTL might be too low for packets to reach same nodes as before • Mobile IP is no longer transparent if a user has to adjust TTL while MN moves • reverse tunnel represents only one hop, no matter how many hops are really needed from foreign to home network

  30. Mobile IP with reverse tunneling • The standard is backwards compatible • the extensions can be implemented easily and cooperate with current implementations without these extensions • Agent Advertisements can carry requests for reverse tunneling; See Agent Advertisement

  31. Mobile IP and IPv6 • Mobile IP was developed for IPv4, but IPv6 simplifies the protocols • security is integrated and not an add-on • authentication of registration is included • COA can be assigned via auto-configuration (DHCPv6 is one candidate), every node has address autoconfiguration • no need for a separate FA, all routers perform router advertisement which can be used instead of the special agent advertisement; addresses are always co-located • MN can signal a sender directly the COA, sending via HA not needed in this case (automatic path optimization) • “soft“ hand-over, i.e. without packet loss, between two subnets is supported • MN sends the new COA to its old router • the old router encapsulates all incoming packets for the MN and forwards them to the new COA • authentication is always granted

  32. Problems with mobile IP • Security • authentication with FA problematic, for the FA typically belongs to another organization • no protocol for key management and key distribution has been standardized in the Internet • patent and export restrictions • Firewalls • typically mobile IP cannot be used together with firewalls, special set-ups are needed (such as reverse tunneling) • QoS • tunneling makes it hard to give a flow of packets a special treatment needed for the QoS • Security, firewalls, QoS etc. are topics of current research and discussions!

  33. Need for IP Micro-mobility support • Large # of MNs changing networks quite frequently • High load on the HAs & networks (registration & binding updates) • IP micro-mobility protocols offer fast and seamless handover in limited geographical areas • HA knows only entry point to foreign network (not details) • Changes location within foreign network handled locally • Only inform HA about major changes (i.e., changes of a region) • Example approaches: • Cellular IP (section 8.1.10.1); HAWAII (section 8.1.10.2); Hierarchical Mobile IP (HMIP) (section 8.1.10.3)

More Related