Network mobility (NEMO)

NEtwork MObility (NEMO)
Houcheng Lee

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

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

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

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

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

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

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

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.

• 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 Router’s 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

• 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 MR’s
CoA and HA’s 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.

• 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 Agent’s 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.

MR acts as
Mobile Host
HA
Binding Update
Get CoA
create cache entry
MR’s Home Address
CoA

MR acts as
Mobile Router
HA
Binding Update with flag (R)
Get CoA
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

MR HA
Binding Acknowledgement set to 0 (Binding Update accepted)
with Mobile Router Flag (R)
once finishes, a bi-directional tunnel is established
MR’s CoA HA’s address

MR HA
src address
from Mobile Network
reverse-tunnels
using IP-in-IP encapsulation
CN
decapsulates and forward

MR HA
MNN
CN
tunnel MR CoA
decapsulates and check (for Security Considerations)
1. src address is HA’s address (NOT necessary if IPsec)
2. inner IPv6 header belongs to a prefix used in MN
DROP

MR HA
run an intra-domain routing protocol (e.g RIPng and OSPF)
through the bi-directional tunnel
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
Dynamic Routing Protocols

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”

• 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)

• 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 8n+4 is required.

Basic Support – MR Operation
• MN can act in 2 ways
– Mobile Host
• HA doesn’t maintain prefix information related to MH
• maintain a cache entry related to the MH’s 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

• Sending Binding Updates
– if MR is not running a routing protocol, 2 modes are used to tell HA which prefixes belong
to the MR
1. 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
2. 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

• 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 doesn’t 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

• 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 HA’s address are the two ends of the
bi-directional tunnel
– A MR uses the Tunnel Hop Limit normally assigned to
routers (RFC2473)

• 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

• 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

• 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

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

– 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

• 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

• 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

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

• 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 MR’s HA
• HA maintains a route to the MN Prefix with the outgoing
interfaces set to the bi-directional tunnel interfaces

• 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

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

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
1. Modified Dynamic Home Agent Discovery
Address Request
2. Modified Dynamic Home Agent Discovery
Address Request
3. Modified Home Agent Information option

Basic Support – Support for
• 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.

Basic Support – Support for
• 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.

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

1. MIPv6 Home Network
• the Home Network is with Mobile IP
2. 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

3. 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
3. Virtual Home Network
• No physical Home Link for the MRs to come
back home

5. 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

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

Applications - Personal Area
Networks (PANs)

Terminology
1. Access Router (AR)
2. Care-of Address (CoA)
3. Correspondent Node (CN)
4. Foreign Agent (FA)
5. Home Agent (HA)
6. Home Network (HN)
7. Mobility Agent (MA)
8. Mobility Network Node (MNN)
9. Mobile Node (MN)
10. Mobile Router (MR)
11. 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
12. 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

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

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

Network mobility (NEMO)

More Related Content

What's hot (20)

Similar to Network mobility (NEMO) (20)

Recently uploaded (20)

Network mobility (NEMO)

Editor's Notes