NEtwork MObility (NEMO)

1
NEtwork MObility (NEMO)

• Houcheng Lee

2
Main Idea

• NEMO works by moving the mobility functionality
  from Mobile IP mobile nodes to a mobile router.
  The router is able to change its attachment point
  to the Internet in a manner that is transparent
  to attached nodes

3
Goals RFC4886

• Migration Transparency
• Performance Transparency and Seamless Mobility
• Network Mobility Support Transparency
• Operational Transparency
• Arbitrary Configurations
• Local Mobility and Global Mobility
• Scalability
• Backward Compatibility
• Secure Signaling
• Location Privacy
• IPv4 and NAT Traversal
• Minimal Impact on Internet Routing

4
Requirements RFC 4886

1. The solution must be implemented at the IP layer
   level
2. The solution must set up a bi-directional tunnel
   between a MR and its HA (MRHA tunnel)
3. All traffic between MNN and CN msut transit
   through the bi-directional MRHA tunnel
4. MNNs must be reachable at a permanent IP address
   and name
5. The solutions must maintain continuous sessions

5
Requirements RFC 4886

1. The solution must not require modifications to
   any node other than MRs and Has
2. Support fixed nodes, mobile hosts, and mobile
   routers in the mobile network
3. Must allow MIPv6-enabled MNNs to use a mobile
   network link as either a home link or a foreign
   link
4. Must ensure backward compatibility
5. Solution will behave the same way if NEMO is
   nested.

6
Requirements RFC 4886

1. Arbitrary levels of recursive mobile networks
   must be supported
2. The solution must function for multihomed MRs and
   multihomed mobile networks as defined in RFC 4885
3. NEMO support signaling over the bi-directional
   must be minimized
4. Signaling messages between the HA and the MR must
   be secured
5. The solution must ensure transparent continuation
   of routing and management operations over the
   bi-directional tunnel
6. When one egress interface fails, the solution may
   preserve sessions established through another
   egress interface
7. The solution should have a minimal impact on the
   global Internet routing system

7
Basic Support RFC3963
8
Basic Support - Introduction

• An extension to Mobile IPv6 (MIPv6)
• compatible with Mobile IPv6
• e.g. a NEMO-compliant HA can operate as a Mobile
  IPv6 HA
• satisfies the goals and requirements identified
  in Network Mobility Support Goals and
  Requirements (RFC4886)
• NEMO ensures session continuity for all the nodes
  in the MN, even as the MR changes its point of
  attachment to the Internet
• NEMO provides connectivity and reachability for
  all nodes in the MN as it moves

9
Basic Support - Introduction

• Definition of a MR extends that of a Mobile IPv6
  Mobile Node, by adding routing capability routing
  between its point of attachment and a subnet that
  moves with the MR
• proposes a bi-directional tunnel between the MR
  and its HA.
• Tunnel is set up when the MR sends a Binding
  Update to its HA successfully
• All traffic between MNN and CN passes through the
  HA
• Basic support does not place any restriction on
  the number of levels for nested mobility, but
  significant overhead is expected

10
Basic Support - Overview

• A mobile Network is a network segment or subnet
  that can move and attach to arbitrary points in
  the routing infrastructure
• The Mobile Router is the default gateway for the
  Mobile Network
• A Mobile Network can comprise of nested subnets,
  but the overhead is heavy
• A Mobile Router has a unique registered Home
  Address with its Home Agent. The Home Address is
  configured from a prefix aggregated and
  advertised by its Home Agent.

11
Basic Support - Overview

• When Mobile Router acquires a Care-of Address
  from Foreign Agent, it sends a Binding Update to
  its Home Agent, and Home Agent creates a cache
  entry binding the Mobile Routers Home Address to
  its Care-of Address.
• If the Mobile Router Seeks to act as a Mobile
  Router and provide connectivity to nodes in the
  Mobile Network, it indicates this to the Home
  Agent by setting a flag (R) in the Binding Update
• Mobile Router MAY include information about one
  or multiple Mobile Network Prefix in the Binding
  Update

12
Basic Support - Overview

• The Home Agent acknowledges the Binding Update by
  sending a Binding Acknowledge to the Mobile
  Router. A positive acknowledgement with the
  Mobile Router Flag (R) set means that the Home
  Agent has set up forwarding for the Mobile
  Network.
• Once the binding process finishes, a
  bi-directional tunnel is established between the
  Home Agent and the Mobile Router, and the end
  points of the tunnel are the MRs CoA and HAs
  address.
• The packets sourced from MN are sent to HA
  through the reverse-tunnels which is done by
  using IP-in-IP encapsulation, and then HA
  decapsulates the packets and forward it to the CN.

13
Basic Support - Overview

• Before MR decapsulates the packets sent from HA
  via tunnel, MR has to check whether the Source
  address on the outer IPv6 header is the Home
  Agents address, but this check is not necessary
  if the packet is protected by IPsec in tunnel
  mode.
• The MR and HA can run a routing protocol through
  the bi-directional tunnel. In this case, the MR
  need not include prefix information in the
  Binding Update. Instead the HA uses the routing
  protocol updates to set up forwarding for the
  Mobile Network. The MR should be configured not
  to send any routing protocol messages on its
  egress interface when it is away from he home
  link and connected to a visited link.

14
Basic Support - Overview
Get CoA
Binding Update
MR acts as Mobile Host
HA
create cache entry
MRs Home Address CoA


15
Basic Support - Overview
Get CoA
Binding Update with flag (R)
MR acts as Mobile Router
HA
implicit mode No Network Prefix Option in the
Binding Update
explicit mode include one or more (multiple
prefix information options on) Mobile Network
Prefix Options
16
Basic Support - Overview
Binding Acknowledgement set to 0 (Binding Update
accepted)
MR
HA
with Mobile Router Flag (R)
once finishes, a bi-directional tunnel is
established
MRs CoA
HAs address
17
Basic Support - Overview
src address from Mobile Network
reverse-tunnels
MR
HA
using IP-in-IP encapsulation
decapsulates and forward
CN
18
Basic Support - Overview
MNN
decapsulates and check (for Security
Considerations) 1. src address is HAs address
(NOT necessary if IPsec) 2. inner IPv6 header
belongs to a prefix used in MN
DROP
MR
HA
tunnel MR CoA
CN
19
Basic Support - Overview
Dynamic Routing Protocols
run an intra-domain routing protocol (e.g RIPng
and OSPF) through the bi-directional tunnel
MR
HA
HA uses the routing protocol updates to set up
forwarding for the MN
MR should be configured NOT to send any routing
protocol messages on its egress interface
20
Basic Support Message Formats

• Binding Update
• A new flag (R) (Mobile Router Flag) is included
  in the Binding Update to indicate to the HA
  whether the Binding Update is coming from a MR
  not from a mobile node
• Other Mobility options are defined in RFC3775
  Mobility Support in IPv6

21
Basic Support Message Formats

• Binding Acknowledgement
• A new flag (R) is included in the Binding
  Acknowledgement to indicate that the Home Agent
  that processed the corresponding Binding Update
  supports MR
• New Binding Acknowledge status values
• 140 Mobile Router Operation not permitted
• 141 Invalid Prefix
• 142 Not Authorized for Prefix
• 143 Forwarding Setup failed (prefixes missing)

22
Basic Support Message Formats

• Mobile Network Prefix Option
• The Mobile Network Prefix Option is included in
  the Binding Update to indicate the prefix
  information for the MN to the HA. An alignment of
  8n4 is required.

23
Basic Support MR Operation

• MN can act in 2 ways
• Mobile Host
• HA doesnt maintain prefix information related
  to MH
• maintain a cache entry related to the MHs Home
  Address
• Mobile Router
• both prefix information and cache entry are
  maintained
• Mobile Router Flag (R) is used to represented
  these 2 modes
• MR maintains a Binding Update List. It is one
  entry per each destination to which MR sending
  Binding Updates

24
Basic Support MR Operation

• Sending Binding Updates
• if MR is not running a routing protocol, 2 modes
  are used to tell HA which prefixes belong to the
  MR
• Implicit
• MR does not include a Mobile Network Prefix
  Option in the Binding Update. HA uses other
  mechanism to determine the Mobile Network
  Prefix(es) owned by the MR
• Explicit
• MR includes one or more Mobile Network Prefix
  Options in the Binding Update
• if the Mobile Router Flag is set, the Home
  Registration Flag (H) must be set

25
Basic Support MR Operation

• Receiving Binding Acknowledgements
• 0 (Binging Update accepted) and the Mobile Router
  Flag (R) is set to 1
• If (R) not set, MR assumes that HA doesnt
  support Mobile Routers
• Then MR performs Dynamic Home Agent Address
  Discovery again to discover HA that supports
• MR MUST de-register with the HA before attempting
  registration with another
• Status of Binding Acknowledgement status is set
  to a value between 128 and 139

26
Basic Support MR Operation

• Establishment of Bi-directional Tunnel
• After a successful Binding Acknowledgement is
  received, the MR sets up its endpoint of the
  bi-directional tunnel
• The bi-directional tunnel is created by merging 2
  unidirectional tunnels as described in RFC2473
• CoA of MR and HAs address are the two ends of
  the bi-directional tunnel
• A MR uses the Tunnel Hop Limit normally assigned
  to routers (RFC2473)

27
Basic Support MR Operation

• Neighbor Discovery for Mobile Router
• When the MR is at home, it MAY be configured to
  send Router Advertisements and to reply Router
  Solicitations on the interface attached to the
  home link
• The value of the Router Lifetime field SHOULD be
  set to 0 to prevent other nodes from configuring
  the MR as the default router
• MR SHOULD NOT do any of the above when on the
  visited link
• MR MUST NOT ignore Router Advertisements received
  on the egress interface. The received Router
  Advertisements MAY be used for address
  configuration, default router selection, or
  movement detection

28
Basic Support MR Operation

• Multicast Groups for Mobile Router
• When at home, the MR joins the multicast group
  All Routers Address with scopes 1 interface-local
  (on the home-advertising interface), and 2
  link-local, on any of it egress interface.
• When in a visited network, MR MUST NOT join the
  above multicast groups

29
Basic Support MR Operation

• Returning Home
• When returning home, MR MUST de-register with its
  HA
• MR MUST implement and follow the returning-home
  procedures defined for a mobile node in RFC3775
• MR might start behaving as a router on its egress
  interface
• MR may send Router Advertisement but the lifetime
  should be set to 0 to prevent being picked as a
  default router
• MR may join the All Routers Address multicast
  group
• MR may send routing protocol messages on its
  egress interface if it is configured to run a
  dynamic routing protocol
• When the HA removes a binding cache entry, it
  deletes all associated Mobile Network Prefix
  routes

30
Basic Support HA Operation

• HA MUST satisfy all the requirement listed in
  section 8.4 of RFC 3775
• Data Structure
• Binding Cache
• HA maintains Binding Cache Entries for each MR
  currently registered with the HA
• might also need to store Mobile Network Prefixes
  associated with a MR in the corresponding Binding
  Cache Entry
• HA also stores the status of the Mobile Router
  Flag (R) in the Binding Cache entry

31
Basic Support HA Operation

• Prefix Table
• HA should prevent a MR from claiming Mobile
  Network Prefixes belonging to another MR
• HA maintains a Prefix Table and verifies the
  prefix information provided by the MR against
  Prefix Table entries
• Not required if running a dynamic routing
  protocol
• In explicit mode, Prefix Tables are used by Has
  when they process Binding Updates
• Each entry contains
• The Home Address of the Mobile Router
• The Mobile Network Prefix of the MR associated
  with HA

32
Basic Support HA Operation

• Mobile Network Prefix Registration
• The HA processes the Binding Updates as described
  in section 10.3.1 of RFC 3775
• The Home Registration (H) Flag MUST be set
• Relaxes RFC 3775 requires that the HA in the
  Binding Update be configured from a prefix
  advertised on the home link, but rejects the
  Binding Updates only if the HA does not belong to
  the prefix that the HA is configured to serve
• Check if there is a duplicated one in cache
  entry, otherwise send acknowledgement with code
  139

33
Basic Support HA Operation

• Advertising Mobile Network Reachability
• To receive packets meant for the Mobile Network,
  the HA advertises reachability to the Mobile
  Network
• If the Home link is configured with an aggregated
  prefix and the Mobile Network Prefix is
  aggregated under that prefix, then the routing
  changes related to the Mobile Network maybe
  restricted to the Home link
• If the HA receives routing updates through a
  dynamic routing protocol from the Mobile Router,
  HA can be configured to propagate those routes on
  the relevant interface

34
Basic Support HA Operation

• Establishment of Bi-directional Tunnel
• Must be capable of the following operations
• HA can tunnel packets meant for the Mobile
  Network prefix to the Mobile Routers current
  location, the CoA
• The HA can accept packets tunneled by the Mobile
  Router with the src address of the outer IPv6
  header set to the Mobile Routers CoA

35
Basic Support HA Operation

• Forwarding Packets
• when HA receives a data packets destined for the
  MN, it MUST forward the packet to the MR through
  the bi-directional tunnel
• Utilize the routing table, the Binding Cache or a
  combination to route packets to the Mobile
  Network
• Two examples
• HA maintains a route to the MN Prefix with the
  next hop set to the MRs HA
• HA maintains a route to the MN Prefix with the
  outgoing interfaces set to the bi-directional
  tunnel interfaces

36
Basic Support HA Operation

• Sending Binding Acknowledgements
• HA sets the status code in the Binding
  Acknowledgement to 0 (accepted)
• code 140 means HA is not configured to support
  Mobile Routers
• code 141 means one or more prefixes received in
  the Binding Update are invalid
• code 142 means not authorized to use this Home
  Address to forward packets
• code 143 means Forward Setup failed

37
Basic Support HA Operation

• Mobile Network Prefix De-registration
• HA deletes the Binding Cache Entry for the MRs
  Home Address and stops proxying the Home Address
• HA removes the bi-directional tunnel and stops
  forwarding packets to the Mobile Network.

38
Basic Support Modification to Dynamic Home
Agent Address Discovery

• Extends the Dynamic Home Agent Address Discovery
  (DHAAD) defined in RFC 3775, so that MR only
  attempts registration with HA that support them
• Modified Dynamic Home Agent Discovery Address
  Request
• Modified Dynamic Home Agent Discovery Address
  Request
• Modified Home Agent Information option

39
Basic Support Support for Dynamic Routing
Protocols

• An alternative way to set up the forward between
  HA and MR is run an intra-domain routing protocol
  such as RIPng and OSPF through the bi-directional
  tunnel.
• So the MR can continue running the same routing
  protocol that it ran when attached to the home
  link.

40
Basic Support Support for Dynamic Routing
Protocols

• This feature is useful. Routing changes can
  propagate to HA and MR quickly
• When the MR returns to the home link, it runs a
  routing protocol by sending routing updates
  through its egress interface, and stop sending
  routing updates when in a visited link.

41
Home Network - Introduction

• In NEMO, the Home Network can encompass much more
  than the Home Link
• Home Network can spans the Home Link and all the
  Links that the MRs carry with them
• Provided examples aim at illustrating the NEMO
  Basic Support
• Five different organizations of the Home Network

42
Home Network - Introduction

• MIPv6 Home Network
• the Home Network is with Mobile IP
• NEMO Extend Home Network
• the Home Network only subnet of a larger
  aggregation that encompasses the Mobile Networks.
• When at home, a Mobile Router performs normal
  routing between the Home Link and the Mobile
  Networks

43
Home Network - Introduction

• NEMO Aggregated Home Network
• the Home Network overlaps with the Mobile
  Networks
• When at home, a MR acts as a bridge between the
  Home Link and the MNs
• Virtual Home Network
• No physical Home Link for the MRs to come back
  home

44
Home Network - Introduction

• NEMO Mobile Home Network
• A global Home Network is advertised to the
  infrastructure by a head Home Agent (HA) and
  further subnetted into MNs
• Each subnet is owned by a MR that registers it in
  a NEMO fashion while acting as a Home Agent for
  that network.
• In all cases, the Home Agents collectively
  advertise only the aggregation of the MNs. The
  subnetting is kept within the Has and the MRs,
  not to advertised by means of routing protocols
  to other parties

45
Home Network General Expectations

• NEMO extends the concept of home so that it is
  not only a flat subnet composed of Home Addresses
  but an aggregation that is itself subnetted in
  Mobile and Home Networks

46
Route Optimization
47
Multihoming
48
Applications - Airplanes
49
Applications - Automobiles
50
Applications - Personal Area Networks (PANs)
51
Terminology

• Access Router (AR)
• Care-of Address (CoA)
• Correspondent Node (CN)
• Foreign Agent (FA)
• Home Agent (HA)
• Home Network (HN)
• Mobility Agent (MA)
• Mobility Network Node (MNN)
• Mobile Node (MN)
• Mobile Router (MR)
• Mobile Netowrk Prefix
• An IPv6 prefix delegated to a Mobile Router and
  advertised in the Mobile Network. More than one
  Mobile Network Prefix could be advertised in a
  Mobile Network
• Prefix Table
• A list of Mobile Network Prefixes indexed by the
  Home Address of a Mobile Router. The Home Agent
  manages and uses Prefix Table to determine which
  Mobile Network Prefixes belong to a particular
  Mobile Router

52
Reference

1. E.Perera, V.Sivaraman, and A.Seneviratne, Survey
   on Network Mobility Support, ACM SIGMOBILE
   Mobile Computer and Communications Review, Volume
   8, Number 2, 2004
2. Paul Moceri, Enabling Network Mobility A Survey
   of NEMO
3. Devarapalli, V.,R. Wakikawa, A. Petrescu P.
   Thubert. RFC 3963 Network Mobility (NEMO) Basic
   Support Protocol, IETF, NEMO Working Group,
   January, 2005
4. Leung, K.,G.Dommety, V.Narayana, A. Petrescu.
   IPv4 Network Mobility (NEMO) Basic Support
   Protocol, IETF, NEMO Working Group, February 24,
   2006
5. C. Perkins, Ed. RFC 3344 IP Mobility Support
   for IPv4, IETF Network Working Group, August,
   2002
6. Ernst, T. Network Mobility Support Goals and
   Requirements, NEMO Working Group,
   Internet-Draft, October 24, 2005
7. Ernst, T.,H-Y. Lach. Network Mobility Support
   Terminology, NEMO Working Group, March 6, 2006
8. Ng, C., F. Zhao, M. Watari, P. Thubert. Netowrk
   Mobility Route Optimization Solution Space
   Analysis, IETF, NEMO Working Group, Febraruy 10,
   2006
9. Ng. C.,F. Zhao, M. Watari, P. Thubert. Network
   Mobility Route Optimization Problem Statement,
   IETF, NEMO Working Group, December 28, 2005
10. Ng. C., E. Paik, T. Ernst, M. Bagnulo, Analysis
    of Multihoming in Network Mobility Support,
    IETF, NEMO Working Group, February 23, 2006
11. Nautilus6 Network Mobility Website, 2005.
    Nautilus6, WIDE, April, 2006
12. Nautilus6 NEPL Enhancement Website, November
    11, 2005. Nautilus6, WIDE, April 2006

53
Reference - RFC

1. RFC 3963 draft-ietf-nemo-basic-support
2. RFC 4887 draft-ietf-nemo-home-network-models
3. RFC 4980 draft-ietf-nemo-multihoming-issues
4. RFC 4886 draft-ietf-nemo-requirements
5. RFC 4888 draft-ietf-nemo-ro-problem-statement
6. RFC 4889 draft-ietf-nemo-ro-space-analysis
7. RFC 4885 draft-ietf-nemo-terminology
8. RFC 3775 Mobility Support in IPv6
9. RFC 3776 Using IPsec to Protect Mobile IPv6
   Signaling between Mobile Nodes and Home Agents

54
END

• Thanks